An authorization server authenticates users and clients, then issues tokens that let clients access protected operations on a resource server. In OpenID Connect, it may also provide identity-provider functions. section 13.1 section 13.6
A working authorization server coordinates:
- User authentication through credentials and user-details management. section 13.3.1 section 14.1
- Client authentication and registration, including client credentials, redirect URIs, scopes, and permitted grant types. section 13.3.3 section 14.1
- Token issuance through grant types such as authorization code and client credentials, with refresh tokens and PKCE available for specific flows. section 13.3 section 13.6
- Token validation support, either through non-opaque token details or authorization-server introspection for opaque tokens. section 13.2.1 section 13.6
Authorization code flow
A web or mobile client redirects Mary to the authorization server because she is not signed in. After she authenticates, the server redirects her back with an authorization code. The client exchanges that code for an access token and uses the token when calling the resource server. section 13.3.1
Spring Security implementation
A minimal Spring authorization server applies protocol-endpoint defaults, configures a separate application security filter, registers clients, manages users, exposes signing keys, and sets general authorization-server settings. Default configuration issues non-opaque tokens; opaque tokens require introspection support. section 14.0 section 14.1
Figure 14.1 Actors in the OAuth 2 scene. The authorization server protects the user and client details and issues tokens the client can use to get authorized when calling the resource server endpoints.
Use the actor diagram to follow how the authorization server protects user and client details, issues tokens, and supports access to resource-server endpoints. section 14.0
