Authorization Server Template — Architecture¶
Responsibilities¶
| Concern | Authorization Server |
|---|---|
| OAuth 2.0 / OIDC endpoints | /connect/*, discovery, JWKS |
| Clients | Public / confidential registrations, secrets, redirect URIs |
| Tokens | Access, refresh, ID tokens; signing and validation parameters |
| Consent | Where enabled for interactive flows |
| User store integration | Delegates to Identity persistence—does not replace user domain |
Stack¶
OpenIddict provides the protocol implementation; ASP.NET Core hosts the server. Database schemas hold OpenIddict entities plus any scaffolded integration tables—follow repo migrations guidance.
Dependency injection¶
AuthServerMicroserviceRegistration composes OpenIddict core, server, validation (as applicable), token lifetimes, certificate or development signing configuration, and endpoint customizations on top of MicroserviceRegistrationBase.
Boundary with Identity¶
| Topic | Identity Backend | Authorization Server |
|---|---|---|
| User CRUD | Yes | Consumes |
| Password verification | Often yes | May delegate |
| Token signing keys | No | Yes |
| Client credentials | No | Yes |
Keep signing key rotation, client secrets, and issuer URL configuration in one documented place—typically the Authorization Server host and deployment vault.
Trust from resources¶
Microservices and gateways validate JWTs using:
- Issuer (
iss) and audience (aud) - Signing keys from JWKS or metadata
- Clock skew and revocation strategy (reference tokens vs JWT-only)
Document your chosen token profile (reference vs JWT, introspection needs) in product runbooks.
Failure and operations¶
- This host is critical path for login—use HA deployment, secrets rotation playbooks, and Resiliency patterns for dependencies (DB, cache).