Authentication errors
All domains and values in these examples are fictional.
Not every sign-in ends with an ID token. You might decide at the photo service that you would rather not share your email address with the printer. The photo service might be unable to sign you in without showing a page, after the printer asked it not to show one. Or the exchange might fail partway, leaving the printer with an access token and nothing else.
OAuth errors work as they did in Errors and denied access. OpenID Connect adds a few error codes of its own, and one rule that matters more than any of them: the printer signs no one in unless a validated ID token says who they are.
Errors from the provider
When the request reaches the photo service but cannot succeed, and the return address is valid, the photo service sends your browser back with an error instead of a code:
https://printer.example/signin/callback
?error=access_denied
&state=demo-signin-3
&iss=https%3A%2F%2Fauth.photos.exampleThe printer handles this like a successful response up to the point where a code would be used. It finds the pending attempt by state, checks the browser session and the issuer, and marks the attempt finished so it cannot be resumed. An error that matches no pending attempt in this session is treated like any other unexpected request to the callback.
Alongside OAuth error codes such as access_denied, invalid_request, invalid_scope, server_error, and temporarily_unavailable, OpenID Connect defines codes that explain why the provider could not finish a sign-in:
| Error | What it means |
|---|---|
login_required | The provider needs you to authenticate, but the request asked it not to show any pages. |
consent_required | You have not agreed to share what was requested, and the provider was asked not to show a consent page. |
account_selection_required | You are signed in to more than one account at the provider and need to choose one, but the provider was asked not to show the choice. |
interaction_required | Some other interaction is needed, and the provider was asked not to show it. |
OpenID Connect also defines errors for advanced request formats, such as request_not_supported from a provider that does not accept a request packaged as a signed object. The printer's simple request will not meet those.
Any error may arrive with an error_description. That text is written by the provider for developers, so the printer does not show it to you as if it were the printer's own message, and never inserts it into a page as markup.
When no one can be asked
Most of the OpenID Connect error codes share a condition: the provider was asked not to show a page. That request is prompt=none, which asks the provider to complete the sign-in silently or not at all. A relying party might use it to find out whether you are still signed in at the provider without interrupting what you are doing.
In that situation, login_required is not a failure. It answers the question the printer asked: no, the photo service cannot sign this person in without their involvement. The printer then decides whether to show its sign-in page, start an interactive request, or carry on without a signed-in customer. Prompt and account selection, in Controlling authentication, covers silent requests and their limits in today's browsers.
The same error in answer to an ordinary interactive request would be surprising, because the provider should have shown its sign-in page instead. That is worth recording and investigating.
Failing closed
Errors are not limited to the redirect. The token request can be rejected with invalid_grant, invalid_client, or another OAuth error, or it can time out with no confirmed result. The printer handles those as Errors and denied access described, and offers a fresh attempt rather than replaying the code.
One outcome is new. Suppose the token response succeeds but contains no id_token, or one that fails validation. The printer has an access token in hand. It could call the UserInfo endpoint and find out whose account the token belongs to.
It must not. UserInfo answers questions about an account for whoever holds a suitable access token. It does not say that this sign-in was the one the printer started, when you authenticated, or that the provider meant its answer for the printer. Those are the things the ID token establishes, and a response without a valid one has not established them. A fallback like this would also turn every broken response into a successful sign-in, which is the opposite of what a failure should do. The same holds for every check in Validating an ID token: none of them has a fallback that signs you in anyway.
For you, the result should be a clear message and a way forward, such as: "We couldn't sign you in with your photo account. Try again, or sign in another way." A denial you chose deserves a calmer message than an unexpected failure, but neither should leave you looking signed in when you are not.
For the developers, the printer records the stage that failed, the error code or failed check, the expected issuer, and a correlation ID. It never records the code, the tokens, or the full callback URL.
An ID token that does arrive is still only a claim until it has been checked. Validation and trust takes those checks in order.