Registering a relying party

What OIDC adds to a registration

OpenID Connect Dynamic Client Registration gives these settings standard names. A provider's console may label them differently or leave some out, but the names are the ones a client uses when it registers through an API, which Registering a client dynamically, in Advanced OAuth, covers. With the OAuth settings shortened, the printer's registration now reads:

{
  "client_id": "photo-printer",
  "redirect_uris": [
    "https://printer.example/oauth/callback",
    "https://printer.example/signin/callback"
  ],
  "token_endpoint_auth_method": "client_secret_basic",
  "scope": "openid profile email photos.read",
  "application_type": "web",
  "id_token_signed_response_alg": "RS256",
  "subject_type": "public",
  "require_auth_time": true,
  "post_logout_redirect_uris": ["https://printer.example/signed-out"]
}

Two lines put familiar settings to new use. The sign-in address sits in redirect_uris and is matched exactly, like the other one. openid joins the scopes the printer may request, with profile and email. A provider that limits scopes by registration would otherwise refuse openid or drop it, and the printer would receive no ID token.

application_type says what kind of application the client is: web, the default, or native for an installed app. Providers use it to apply return-address rules that suit each kind. Under the OpenID Connect registration rules, a native client may register only custom-scheme addresses and loopback addresses such as http://127.0.0.1, and a provider may add rules of its own for installed apps. The printer's website is a web client. Its phone app has a registration of its own, and because the app returns to a claimed HTTPS address, as Redirect URIs and client metadata described, that registration uses web under these rules, even though the app is installed on your phone.

The remaining settings fall into two groups. Some shape the tokens and claims the printer receives. Others set defaults for how you are asked to sign in and tell the provider where the printer can be reached when a session ends.

Settings for tokens and claims

id_token_signed_response_alg names the one algorithm the provider will use to sign ID tokens for this client. It defaults to RS256, which every OpenID Provider supports, and the printer states it anyway so that nobody has to remember the default. This setting and the printer's own allowlist describe the same decision from two sides. If someone changed the registration to ES256 without changing the printer, every sign-in would fail with the configuration mismatch described in When validation fails, and the fix would be to make the two agree again, not to accept both.

The specification lets a client register none, meaning unsigned ID tokens, only if it never receives an ID token from the authorization endpoint, which is the case Receiving the ID token discussed. The printer validates every signature, so it never registers none.

Two related settings ask for more protection. id_token_encrypted_response_alg and id_token_encrypted_response_enc ask the provider to sign each ID token and then encrypt it to a key the client publishes. userinfo_signed_response_alg asks for UserInfo responses as signed JWTs instead of the plain JSON a client receives without it. The UserInfo endpoint works with plain JSON, and Signed and encrypted messages, in Advanced OIDC, covers both kinds of protection.

subject_type chooses which kind of sub the printer receives, from the types the provider lists in subject_types_supported. With public, the photo service gives the printer the same identifier, user-2048, that it gives every other application you sign in to. With pairwise, each client receives a different identifier for you, so applications cannot compare notes about you by matching it. A client whose return addresses span several hosts can add a sector_identifier_uri, the address of a list of those return addresses, so that all of them receive the same pairwise identifiers. Public and pairwise subject identifiers explains both.

This is the setting to decide before launch. The printer links each customer's account to the issuer and sub it receives, so switching from public to pairwise later would give every existing customer a different sub, and none of them would match their account.

Settings for sign-in and logout

Three settings concern the authentication behind each sign-in:

• require_auth_time, when true, makes auth_time mandatory in every ID token for this client. The printer sets it, so every ID token it receives says when you last authenticated, like the one in ID tokens and access tokens.
• default_max_age is a number of seconds. If your last authentication at the provider is older than that, the provider must ask you to authenticate again. A max_age parameter in a particular request overrides it.
• default_acr_values lists, in order of preference, the authentication context classes the client would like the provider to satisfy. An acr_values parameter in a particular request overrides it.

The printer sets only the first. Each of these is a standing request, applied to every sign-in for this client, and none of them excuses the printer from checking the result. A provider that ignored default_max_age would still produce a validly signed token. The printer compares auth_time and acr with what it needs, as Session age and reauthentication and Authentication context and methods describe. Defaults suit rules that apply to every sign-in. A rule for one action, such as signing in again before changing a delivery address, belongs in the request for that action.

The remaining settings are addresses at the printer that the provider or another service may use later. Each is registered in advance, like a return address:

The printer registers https://printer.example/signed-out as the place to return after signing out, and leaves the two logout notification addresses empty for now. Once the logout lessons register them, the printer will also make use of a session identifier, sid, which the photo service includes in its ID tokens because it supports session-aware logout. Later logout messages use it to name the session they end. The printer has no use for initiate_login_uri either, since its customers start every sign-in at the printer.

Every one of these choices belongs to one registration at one provider. When the printer adds a second provider, it makes them all again, separately.