Lesson 18.118.1 Who is calling?

In everyday life. A hotel gives every guest a key card. The front desk checks your ID once, then programs a card for your room and your stay. The card holds only what the door needs: which room, and which nights. It opens one room, and it stops working when you check out. The front desk can cancel one guest's card without changing every lock in the building.

What you will learn. Why a connector must know who is calling, and what signing in gives it that one shared key cannot.

Why it matters. With one shared key, one company's people can read another company's invoices, and nobody can say who did it.

One request, start to finish. Cedar Ridge Supply has just signed up to use Brightline's connector. Suppose nothing changes from Chapter 17, so Cedar Ridge's AI app gets the same shared access key Brightline's app uses. Luis, at Cedar Ridge, asks his AI app: "Which invoices are due this week?"

1. His app sends the request with the shared key. The connector checks the key. It is right.
2. The connector cannot ask the next question: which company is this? The key says nothing about Luis or Cedar Ridge.
3. It answers with the only data it has, Brightline's. Luis now sees Brightline's invoices.

Nothing was broken into. The key did exactly what it was built to do: let in anyone who holds it.

What must a server know about every caller?

Every server that holds something private asks two questions:

• Who are you? Proving who you are is authentication.
• What may you do? Deciding what you may do, once the server knows who you are, is authorization.

Chapter 17's access key answers neither well. It proves only that the caller has the key. It cannot name a person or a company. It cannot be taken back from one person without changing it for everyone. And anyone holding it looks the same, so if it leaks, the server cannot tell the thief from Ana.

How does a website sign you in?

You have signed in to websites hundreds of times. Two things happen underneath:

• The site never keeps your password. When you set it, the site runs it through a one-way scramble that always gives the same result for the same password but can never be turned back into it. The site keeps only that password hash. When you sign in, it scrambles what you typed the same way and compares. A thief who copies the site's records gets hashes, not passwords.
• After you sign in, the browser holds a session. A session is a short-lived proof that you signed in, so you do not type your password on every page. The browser keeps it in a cookie, a small value it stores for that one website and sends back on each visit.

A connector cannot use a session cookie. AI apps are not browsers, and a cookie belongs to one website. So sign-in for a connector adds one step: after the person signs in, the AI app is handed a sign-in token made for the connector. It names the person, the company and what the app may do, and it runs out after a short time. The next five concepts build that step.

What changes for Brightline?

This chapter removes the shared access key completely: from both versions of the connector, from every AI app's settings, and from the secrets stored online (17.8). Keeping it as a second way in would be a back door, a hidden extra way in, and a back door that "only admins use" is still a back door. The handle key stays, because it seals page handles (17.4), and nobody outside the connector ever holds it.

At work. The builder lists what Brightline needs before any code: Ana and Luis each sign in as themselves. Each request names one company. Luis can never see Brightline's data, even if his app sends the wrong company. A person who leaves loses access within minutes. Every one of these is impossible with one shared key.

The operating rule: a connector that serves more than one person, or more than one company, must know who is calling and for which company on every request. A shared key cannot tell it, so replace the key, do not add to it.

Figure 18.4. A key proves you hold it. A token says who you are, for which company, and what you may do.