OAuth and single sign-on in plain words

The interviewer says: "Staff log in once and reach ten apps. How?" A weak answer is "we use a standard login tool". A strong answer says who talks to whom, and why a thief who copies the browser address gets nothing.

A valet key starts the car but does not open the boot. The owner gives it to the parking helper and keeps the master key. "Log in with Google" on an app works the same way.

OAuth 2.0 is a standard that lets an app get limited access to your data on another service, without your password. It has four roles. The resource owner is you. The client is the app that wants access. The authorization server logs you in and issues tokens. The resource server is the API that holds your data.

The key is an access token (lesson 99). It carries scopes, a list of what it allows, such as "read my email". OAuth says what the client may do, not who you are.

OpenID Connect adds login. The client asks for the scope openid and also gets an ID token. This is a JWT (lesson 99) with claims: iss is who issued it, sub is the user ID, aud is the client it is for, and exp is the end time. The client checks the signature, iss, aud and exp.

The common flow is the authorization code flow with PKCE (Proof Key for Code Exchange):

1. The client makes a random code verifier. The hash of it (lesson 99) is the code challenge.
2. The client sends the browser to the authorization server. It adds its client ID (its name there), scopes, challenge, a random state that comes back unchanged, and a redirect URI: the address to send the browser back to. The server accepts only an address registered before.
3. You log in and agree at the authorization server. The client never sees your password.
4. The server sends the browser back to the redirect URI with a one-use code and the same state.
5. The client checks the state. This makes sure that the reply answers its own request.
6. The client sends the code and the verifier over HTTPS (lesson 7) to the token endpoint, where the server swaps a code for tokens. If the hash of the verifier matches the challenge, the server sends tokens.

The code passes through the browser, where others may copy it. It is useless without the verifier, which never passes through the browser. A phone app cannot keep a secret in its code. PKCE needs no secret, and RFC 9700 advises it for every client.

The client credentials flow is for one service calling another: it sends its own ID and secret and gets a token, with no user. Avoid the old implicit flow, which sends tokens through the browser, and never use the password flow, which gives your password to the client.

Single sign-on (SSO) means one login opens many apps. A company runs one identity provider (the authorization server above) and each app sends you to it. You log in once, and the provider keeps a session cookie. The next app gets a code with no password. SAML is an older standard for the same job.

A company has 2,000 staff and 5 internal apps. Assumptions (made up): each person opens each app once a day.

1. The staff app makes a random verifier of 32 bytes, which is 32 x 8 = 256 bits. It sends the hash as the challenge.
2. Asha logs in. The browser returns to https://staff.example.com/callback?code=abc&state=Xk3. The app checks Xk3, sends abc and the verifier, and gets an access token and an ID token.
3. A thief with only abc calls the token endpoint. The server hashes what the thief sends, and it does not match the challenge. The request fails. This answers the predict box.
4. Asha opens a second app. The provider sees its cookie and returns a code.

Logins in a day. Without SSO: 2,000 x 5 = 10,000. With SSO: 2,000. That is 10,000 / 2,000 = 5 times fewer.

OpenID Connect solves sharing passwords with apps, and gives one login. It costs extra redirects and a provider that must stay up. I would change to my own login (lesson 99) when there is only one app.

"OAuth is a login protocol." It gives access. OpenID Connect adds the ID token.

"Logging out of one app logs me out of all apps." Each app has its own session, and the provider has one more.

1. Name the four roles in OAuth. What does OpenID Connect add?
2. There are 3,000 staff and 6 apps. Without SSO each person logs in to each app once a day. With SSO, once a day in total. How many logins for each? How many fewer?
3. A phone app keeps a client secret inside the app. What is wrong, and what do you use?