OpenID Connect specifies three core endpoints that must be provided to meet its specifications and three other optional sets of endpoints that aid with automation and session management.
- Authorize endpoint: Found in the OAuth framework, this endpoint performs authentication and authorisation. Think of it as interacting with humans, it performs the login, consent, renders a UI, etc.
- Token endpoint: Again from OAuth, this endpoint allows the requester to get an access token, an ID token and optionally a refresh token. If the authorize endpoint is human interaction, this endpoint is machine to machine interaction (it is a web API).
- UserInfo endpoint: New to OpenID Connect, this endpoint allows you to make a request using your access token to receive claims about the authenticated end-user. This user information could be included in the identity token, however this can cause bloat especially if we include things like profile pictures.
- Session Management: This includes multiple endpoints for log in and log off processes. Log off is something that OAuth never had. Why? Because, as I may have stressed already, it is not an authentication protocol!
- Discovery: These endpoints provide metadata about the OpenID Connect provider, allowing applications to automatically configure for that provider. This includes data such as the location of the core endpoints, allowed scopes and public keys.
- Client Registration: These endpoints allow a relaying party to register with the OpenID provider, providing it with the necessary profile information (claims) to register and obtaining the information needed to use the provider (e.g. automatically signing up to a new website using your existing Google account).
How you interact with these endpoints is dictated by what flow your client application is using which, conveniently, is the topic of my next blog post.Sources