The authentication request
All domains, identifiers, and values in these examples are fictional.
OpenID Connect calls the printer's first message an authentication request. Underneath, it is an OAuth authorization request with a few additions, sent through your browser to the same authorization endpoint. Reading it closely shows how little has to change to turn a request for access into a request for sign-in.
Reading the request
Here is the request from Following a complete sign-in again:
https://auth.photos.example/authorize
?response_type=code
&client_id=photo-printer
&redirect_uri=https%3A%2F%2Fprinter.example%2Fsignin%2Fcallback
&scope=openid%20profile%20email
&state=demo-signin-3
&nonce=demo-nonce-3
&code_challenge=VJLVyms6-H5HoRQD_d-b-XThm8LNqfrMav0hDI23zpU
&code_challenge_method=S256Most of these parameters do what they did when the printer connected your photo account. response_type=code asks for an authorization code, so the ID token will arrive later in the direct token response rather than in your browser's address bar. client_id names the printer's registration. redirect_uri is the sign-in return address, which must exactly match a registered value. state and the PKCE challenge protect the exchange as before. The challenge belongs to a new verifier, created for this attempt only.
Two things are new. The scope begins with openid, and the request carries a nonce. The nonce gets its own lesson next. The scope is what makes this an OpenID Connect request at all.
The openid scope
The openid scope value tells the photo service that the printer is acting as a relying party and expects an ID token. Without it, the request is not an OpenID Connect request, and the specification leaves what happens next unspecified. A provider will usually treat it as an ordinary OAuth request: it might still authenticate you and issue a code, but the printer cannot count on an ID token in the response, and whatever it did with the result would not be an OpenID Connect sign-in.
The other two values, profile and email, ask for information about you rather than for sign-in itself: your name and picture, and your email address and whether the photo service has verified it. They carry that meaning only alongside openid. Scopes and the claims parameter explains what each one requests and where the information arrives.
A request can combine sign-in with access. To sign you in and read your photos in one step, the printer could ask for:
scope=openid%20profile%20email%20photos.readThe response would then carry an ID token for the sign-in and an access token that the photo API would accept for reading photos. It is often better not to combine them. Someone signing in to order a calendar may not want to grant photo access yet, and a sign-in page that asks for more than sign-in can lose people at the first step. The printer can sign you in with openid profile email and ask for photos.read later, when you start choosing photos for the calendar.
Other request parameters
OpenID Connect defines further parameters that let the relying party shape the sign-in. The printer's request uses none of them, but you will meet them in provider documentation and in later lessons:
| Parameter | What it asks for | Covered in |
|---|---|---|
prompt | Whether the provider should show its sign-in, consent, or account selection pages, or show nothing at all. | Prompt and account selection |
max_age | Fresh authentication if your last sign-in at the provider was more than this many seconds ago. | Session age and reauthentication |
login_hint | A suggestion of which account to sign in, such as an email address. | Login hints |
id_token_hint | An ID token issued earlier, identifying the person the relying party expects. | Login hints |
acr_values | Preferred authentication contexts, such as a level of assurance the provider and relying party have agreed on. | Authentication context and methods |
claims | Specific pieces of information about you, and where to return them. | Scopes and the claims parameter |
request, request_uri | The whole request packaged as a signed object, or a reference to one. | JWT-Secured Authorization Requests, in Advanced OAuth |
ui_locales, display | Preferred languages for the provider's pages, and the kind of window they appear in. | Below |
The last two only affect the provider's pages. ui_locales=fr-CA asks the photo service to show its pages in Canadian French if it can, and display=popup tells it the printer opened a popup window rather than a full page. The provider may ignore either one.
Being ignored is not limited to the interface. Every parameter in the authentication request is a request, not a result. If the printer sends max_age=300 because it wants a sign-in from the last five minutes, the provider is expected to honor it, but the printer still checks the auth_time in the ID token it receives. If it asks for a particular authentication context, it checks the context reported back. The authorization endpoint receives the request, and the relying party verifies what was actually done.