OpenID Connect specifies three core endpoints that must be provided to meet its core specification and three other optional endpoints that aid with automation, discovery and session management.
Core
Authorization Endpoint
Carried across from OAuth, this endpoint authorises access a protected resource. This resource could be the resource owners identity or an API.
This endpoint will require the resource owner to first authenticate (log in) and then give their consent to for you to access their protected resources. Assume that this endpoint will always require interaction with the resource owner.
Token Endpoint
Again carried over from OAuth, this endpoint allows the requester to directly retrieve tokens. If the authorization endpoint is human interaction, this endpoint is machine to machine interaction.
This endpoint doesn't ever need to see the resource owner or be accessed via a front-channel.
User Info Endpoint
New to OpenID Connect, this endpoint allows you to make a request using an appropriate access token to receive identity information (claims) about the authenticated end-user (the resource owner).
This identity data could be included in the identity token, however if we bloat the token with larger claims such as address and various profile urls, we'll soon start to hit request size limits if we try and send the token via the query string or fragment.
Token Types Accessible By Endpoint
| Identity | Access | Refresh | Authorization Code | |
|---|---|---|---|---|
| Authorization | ||||
| Token |
Optional
Discovery
The discovery endpoint gives us access to the OpenID Connect Discovery Document (aka the disco doc).
This document provides us with metadata about the OpenID Connect provider, allowing applications to automatically configure themselves to integrate with the provider. This includes data such as the location of the core endpoints, allowed scopes & claims, and public keys using for token signing.
Session Management
This includes multiple endpoints for session management and log off processes, facilitating single sign off (or single log out) across client applications.
Log off is something that OAuth never had. Why? Because, as I may have stressed already, OAuth is not an authentication protocol!
Client Registration
These endpoints allow a client application (or a relying party) to dynamically register with an OpenID provider. Typically a client application would be known to the OpenID Provider before hand, however in scenarios where you want to facilitate dynamic registration, then this endpoint is for you.
Usage
How you interact with these endpoints is dictated by what flow your client application is using which, conveniently, I have another article for.
Want to get started? Then check out the OpenID Connect framework IdentityServer.