OIDC discovery is a standard configuration document published by an OpenID provider. It gives an application the provider’s supported claims, authorization and token endpoints, UserInfo endpoint, and signing-key location. Providers publish it at /.well-known/openid-configuration. section 7.6 section 8.4
Using discovery avoids hard-coding provider-specific integration details. An application reads authorization_endpoint to begin login, uses the token endpoint to obtain access tokens, and finds JWKS information to validate token signatures. section 8.4 section 8.7
Building a login redirect
A Google configuration is available at https://accounts.google.com/.well-known/openid-configuration. An Auth0 tenant commonly uses its tenant URI followed by /.well-known/openid-configuration. A FastAPI login route reads the authorization endpoint and redirects the user with response_type=code, client_id, redirect_uri, and audience. After authentication, the provider returns an authorization code that the server exchanges for an access token. section 8.4 section 8.4.1
Use discovery as an integration and verification checklist:
- Read authorization_endpoint instead of assuming the provider’s login URL. section 8.4.1
- Check response_types_supported before choosing an authorization response such as code. section 8.4.1
- Locate the provider’s JWKS endpoint and select the validation key using the token header’s kid value. section 8.7
- Validate access tokens on every request and constrain accepted signing algorithms. section 8.7
Figure 7.14 OIDC allows applications to use OPs to manage their user identities securely. In this case, the application redirects the user to the OIDC server to log in and give consent, and it obtains an ID token and an access token in return.
Shows the surrounding OIDC flow: redirecting a user to the provider, obtaining consent, and receiving an ID token and access token. section 7.6
