Is that log line true?
Only if the downstream’s single sign-on is federated to your identity provider. Without federation, the user signed in twice to two unrelated accounts, and the log can name the wrong person.
Okay, so what does federation do here? The second login doesn’t use a downstream password. The downstream sends the user back to your identity provider, which already knows it’s Alice, and Alice’s account at the downstream is the one that gets the token. Your Conditional Access and MFA policies apply to that sign-in too, as long as they target the downstream app or all resources. The identity you verified is the identity that acts.
Now take federation away. The second login is a separate login, and the user types whatever credentials they like into the downstream’s own sign-in page. Maybe they’re Alice’s. Maybe Alice is signed in to the downstream in that browser as the shared support account, or as her personal account, or as Bob, because Bob was using the laptop yesterday. Both tokens are real. Nothing in the flow connects them. You verified one person in step one and got a token for some account in step two.
A token proves that some account authorized the agent to act. It doesn’t say which human was at the keyboard, and it says nothing at all about any other token. Federation is what links the two.
The reason federation is missing is often mundane. The downstream account is on a plan that doesn’t offer SSO, so there’s nothing to federate.
Now, you might say, “So the log is a little loose. Alice was still the one who signed in.” Let’s run the usual check. Who is the attacker? Anyone who completes the downstream login with an account other than Alice’s, which includes Bob from yesterday and doesn’t require any malice. Who is the victim? Alice, whose name is on the refund, and whoever reads the log later. What did the attacker gain? No new access, since they already held those downstream credentials. They gained a log that credits their actions to someone else.
The audit log exists to answer one question, usually under pressure: who did this? This one looks complete and well-formed, and it points at the wrong person. That’s worse than having no log, because people will believe this one.
So don’t write “the downstream is federated to your identity provider” in a design doc until you’ve seen the SSO configuration on the downstream side. Check that the customer’s plan supports SSO at all, because many plans don’t. Check that SSO is required, not just available: Slack, for example, lets an admin make it required, partially required or optional, and lets workspace owners bypass it with an email and password. Then it’s one of these cases.
userinfo endpoint or equivalent, and record that. The identity
in the log is then the identity that acted. Don’t make the user sign in twice
to establish a connection you can’t establish.Exercise: You check the userinfo response from the downstream after the
second login, and its email field matches the email your identity provider
returned: both say alice@example.com. Doesn’t that prove the two logins were
the same person?
No. It proves that two accounts in two separate systems have the same email string.
Without federation, each system decided on its own who alice@example.com is. The downstream might let users set their own email, or not verify it. The account might be a shared one that someone registered with Alice’s address years ago. Nobody proved to both systems that it was the same person.
Email matching is fine as a hint to show a human (“these look like the same person, confirm?”). It doesn’t belong in an audit log as fact. The comparison that holds up is a stable identifier that one system vouches for to the other, which is what federation provides: the downstream account is linked to the identity provider’s subject, and the downstream sent the user to your identity provider to sign in.
They followed the spec. So what went wrong?
Well, the spec describes what an authorization server may do, and it offers a lot of options. Every provider picks its own subset. The demo tested the subset one provider picked for one account. Let’s look at three places where the picks tend to differ.
Start with PKCE. It’s the right default, and the 2.1 draft wants it everywhere.
Now, you might say, “The token request carries a code_verifier, so it proves
who I am. I don’t need the secret.” For a public client, like a desktop app
that can’t keep a secret, that usually holds.
Aha, but if the provider registered your app as a confidential client, PKCE
goes on top of the client secret. It doesn’t replace it. The token endpoint
expects client_id and client_secret, and a request that brings only a
code_verifier gets back invalid_client. Some older providers go further and
don’t recognize the PKCE parameters at all.
So before your server promises “Authorization Code with PKCE” for a downstream
API, find out which kind of client the provider thinks you are. Then read the
token endpoint’s documentation to see whether it accepts a code_verifier,
requires one, or ignores it. (Keep PKCE on the leg where your users sign in to
your own identity provider regardless. This is about the downstream leg.)
Okay, next question: does any localhost port count as a match? A desktop MCP server usually catches the OAuth callback on a loopback address, and it’s convenient to grab whatever port is free and put it in the redirect URI.
Some providers accept that. Microsoft Entra, for example, ignores the port when
it matches a http://localhost redirect URI, so an ephemeral port works. Other
providers, or other client types at the same provider, compare the redirect URI
to the registered one exactly. Google does this for a web application client
(its desktop client takes any loopback port), and an unregistered port fails
with redirect_uri_mismatch.
For the exact-match providers, don’t float the port. Pick a fixed loopback port
and make it configurable. Then register http://localhost:<port>/callback
exactly as your server will send it. Which rule your provider uses decides
whether the port is allowed to move, so find out before you write the listener.
The last one starts from a reasonable belief: “The documentation lists the endpoint, so the account can call it.”
Not necessarily. Providers gate features by plan, including AI endpoints, admin APIs, SSO and SAML configuration. A free developer account often has no admin console at all and can’t configure SSO. Your integration works against your account and fails against the customer’s, because the customer is on a tier that doesn’t include the endpoint you built on. Or it goes the other way. You tested on a trial that had everything turned on, and the trial ended.
Check the endpoints you depend on against the plan the customer actually has, and tell them about the limits you find. “This works on the free plan, but the AI endpoint is rate-capped there, and SSO needs the Business plan” is a much better sentence to say before deployment than after.
Postscript: The spec does have an opinion on the port question. RFC 8252,
the Best Current Practice for OAuth in native apps, says an authorization server
MUST allow any port on a loopback IP redirect URI, because a native app can’t
count on a particular port being free. It also recommends the literal
127.0.0.1 over the name localhost, partly because localhost is a name that
something else has to resolve, and resolution can be misconfigured. Providers
that require an exact port aren’t following that advice, and you have to work
with them anyway.
Exercise: Your server uses a fixed callback port, 8765, registered with an exact-match provider. A user reports that the sign-in page opens, they approve access, and then the browser shows “connection refused.” The provider’s logs show that the authorization succeeded. What happened?
The provider did its part. It redirected the browser to http://localhost:8765/callback?code=…, and nobody was listening on 8765 to receive it.
My guess is that the port was taken. Another program, or a second copy of your own server, was already bound to 8765, so your listener failed to start and the code went nowhere. With an exact-match provider you can’t just move to another port, because the redirect URI would no longer match the registration.
That’s the cost of a fixed port. Check that the listener actually bound before you open the browser. If it didn’t, say “port 8765 is in use” rather than leaving the user on a dead page. (There’s a second possibility. The redirect went to localhost, which resolved to ::1, while the listener was bound only to 127.0.0.1. RFC 8252 prefers the literal address partly to avoid that kind of resolution surprise.)