Cybersecurity glossary
What is an OAuth Authorization Server?
Learn what an OAuth authorization server is, which endpoints it exposes, how it authenticates users and clients, issues tokens, and which security controls keep an AS safe.
Definition
An OAuth authorization server (AS) is the OAuth role that authenticates resource owners and clients, obtains authorization, and issues access tokens (and related artifacts such as refresh tokens or authorization codes) according to configured grants and policies.
Why the authorization server is OAuth’s control plane
Clients and APIs come and go. The OAuth authorization server is where identity proof, consent, and token minting converge. Compromise or misconfiguration here radiates into every relying API.
Treat the AS like Tier-0 identity infrastructure.
Core AS responsibilities
Authenticate people
Passwords, MFA, passkeys, or federated upstream IdPs.
Authenticate clients
Secrets, private-key JWT, or mTLS for confidential clients.
Run grants
Authorization code, client credentials, device code, and more.
Issue tokens
Access, refresh, and—when OIDC—ID tokens with correct claims.
Enforce policy
Scopes, audiences, consent, risk, and token lifetimes.
Support lifecycle
Revocation, introspection, key rotation, and metadata.
Typical authorize + token path
Client redirects to /authorize
Includes client_id, redirect_uri, scopes, state, PKCE challenge.
AS authenticates and consents
User proves identity; policy records approved scopes.
Authorization code returned
Front-channel delivers a short-lived code to the redirect URI.
Client calls /token
Redeems code with verifier and client authentication.
Tokens minted
AS issues access/refresh/(ID) tokens for resource servers and clients.
Trust relationships to harden
| Edge | If weak | Control |
|---|---|---|
| User → AS | Account takeover | Phishing-resistant MFA |
| Client → AS | Impersonated clients | Strong client auth + PKCE |
| AS → RS trust | Forged access | JWKS, aud, iss validation |
| AS admins | Silent token abuse | PAM + audit logging |
Hardening checklist
- Publish accurate authorization server metadata and rotate signing keys safely.
- Require PKCE for authorization code flows; exact redirect URI matching.
- Issue short-lived access tokens; rotate refresh tokens with reuse detection.
- Authenticate confidential clients strongly (prefer cryptographic methods).
- Scope and audience-restrict tokens; avoid omnibus APIs under one token.
- Expose revocation/introspection and wire them into logout and offboarding.
- Monitor anomalous grants, consent grants, and admin configuration changes.
- Segment break-glass AS admin access with phishing-resistant MFA.
The practical takeaway
An OAuth authorization server authenticates parties and issues the tokens the rest of the ecosystem trusts. It is the policy brain of OAuth.
Harden authentication into the AS, constrain what it will mint, and make revocation real—because every resource server inherits its decisions.
Related security terms
OAuth Resource Server
API that accepts access tokens issued by the authorization server.
OAuth Client
Application that requests tokens from the authorization server.
OAuth 2.0
Framework that defines the authorization server role.
Identity Provider (IdP)
Often co-located with or acting as the AS in OIDC deployments.
Token Revocation
AS capability to invalidate issued tokens.
Frequently asked questions
What is an OAuth authorization server in simple terms?
It is the login and token service. It checks who you are, asks what an app may access, and issues the access tokens APIs later check.
Is an authorization server the same as an IdP?
Often the same product. Strictly, AS is the OAuth token issuer role; an IdP emphasizes authenticating users and asserting identity (as with OIDC).
What endpoints does an AS expose?
Commonly authorization, token, JWKS, discovery/metadata, and optionally revocation, introspection, device authorization, and PAR endpoints.
What does the AS decide?
Which grants are allowed, which clients exist, which scopes can be granted, token lifetimes, MFA requirements, and consent policy.
How do resource servers trust an AS?
By validating issuer, signatures via JWKS, audiences, and introspection responses from that AS—not from arbitrary issuers.
What are high-impact AS misconfigurations?
Open redirect URIs, missing PKCE, weak client authentication, overly broad scopes, long-lived bearer tokens, and disabled issuer checks downstream.
Should every microservice be its own AS?
Usually no. Centralize issuance; let many resource servers trust one hardened authorization server (or a small set of issuers).
References
Explore authoritative guidance and frameworks related to oauth authorization server.
Explore every security definition
Return to the glossary to search by term, alias, starting letter, or security category.