The Door That Holds No Secret

The probe came back with an error:

400  INVALID_IDP_RESPONSE: unable to parse the identity token

That was the result we wanted. The request had come from a runtime account with no identity-platform role at all. If the platform had needed a key or a role from us, it would have refused with forbidden. It did not. It let the request in and complained only about the body, which we had made junk on purpose.

So the key we had been planning to store was doing nothing. That was the first thing our sign-in door stopped holding.

Everything in the drawer

A sign-in door is the front desk of an application. You arrive, the desk sends you to someone who can vouch for you (an identity provider), you come back with their word, and the desk gives you a session.

Picture what the desk keeps in its drawer. Whatever is in there is what a thief gets if the desk is ever taken over. The first design was a perfectly standard one, and its drawer held three things:

• a key for the cloud identity service it talks to;
• a secret for each identity provider, so it could trade the provider’s one-time code for the user’s tokens;
• and the job of doing that trade itself, then checking the token that came back.

Every tutorial builds it this way. Every item is also something a compromised door hands over.

Out goes the key

The design had already noted, during review, that the key only names the project. What makes a call authorised is a credential issued to the caller. If the key names and the credential authorises, the key is not needed.

The probe tested exactly that. A runtime account with a log-writer role, a metric-writer role and access to one secret called the sign-in endpoint with nothing but its own credential. The answer was the 400 above. A 403 would have meant the account needed more, and the key would have stayed. It did not, so the key went, recorded as a dated reversal: no key on the server.

Out go the secrets

With the key gone, the drawer still held one secret per provider, because the door was doing the code trade itself. The question that removed them was simple: why is the door doing that at all? The cloud identity service can do it.

So now the door asks the service where to send the browser, sends it there, and when the browser comes back with a code, hands the code straight to the service. The service makes the trade with its own stored secret. The drawer now holds one thing: the secret that seals the door’s own cookies.

A probe confirmed it. A bogus code produced an error from the provider, which meant the service, not the door, was the one talking to it. A wrong session and a wrong state were each refused for their own reason.

What an empty drawer costs

Holding less was not free, and the costs are written down beside the decisions.

The small one: every address the door runs on has to be registered with each provider once, because the provider now sends users back to the door directly. There is a runbook for it.

The real one: the door can no longer check the identity token itself. It receives the result over an encrypted channel from a platform it trusts, and it does not re-check the provider’s signature. Back at the front desk: the desk no longer looks at your ID. Security does, and the desk takes their word.

That changes what the door may truthfully say. Its trace of a sign-in now labels every step by who did the checking: verified when the door checked it itself, attested when the platform states it and the door cannot check it, and handed off when it is the next system’s job. Only verified is ever green, and only verified steps are counted. A desk that says “verified” when it means “security told me so” is overclaiming, however good security is.

Each reversal is a dated entry in the design’s decision ledger, with its reason and its cost, because putting the key or the secrets back would look, to the next person, like an obvious simplification.

The door is built and running. What it holds, and what it does not, is shown by the probe record rather than by the design’s description of itself.

The line that stays

A door that holds less has less to leak, and it can also check less. The second fact has to be as visible as the first.

The less the door can check, the more precisely it has to say so.