Skip to main content
Identity Authority
Category: OAuth & OIDC

Authorization Server

Also known as: AS, OAuth Authorization Server
Simply put

An authorization server is the component in an identity system that issues security tokens after checking who is making a request and what they are allowed to access. In an OAuth-based setup, it is the system that hands out access tokens so an application can reach protected resources on a user's behalf. It typically works alongside, but is distinct from, the resource that actually holds the data.

Formal definition

In the OAuth 2.0 / OAuth 2.1 framework, an authorization server is the endpoint that issues access tokens (and, when OpenID Connect is layered on top, ID tokens) to a client after the relevant grant is completed. Its OAuth-defined role is delegated authorization: producing tokens that represent granted access to protected resources within a security domain for a principal user or client application. Although some vendor and implementation descriptions state that the authorization server also authenticates the user, in the standard architecture end-user authentication is conceptually a separate step from the token-issuance function; the specific authentication behavior depends on deployment, profile, and whether an OIDC layer is present. Implementations such as Spring Authorization Server provide these capabilities per the OAuth 2.1 and OpenID Connect 1.0 specifications. This entry addresses the authorization server's token-issuance and access-control role; runtime token validation and enforcement performed by resource servers are out of scope here.

Why it matters

The authorization server sits at the center of delegated access in OAuth-based systems: it is the component that decides whether to issue an access token and, by extension, whether an application can reach protected resources on a user's behalf. Because tokens issued here become the currency that downstream resource servers trust, the authorization server is a high-value control point. A misconfiguration in its grant handling, token lifetimes, scope enforcement, or client registration can propagate broadly, since every resource that accepts its tokens inherits the consequences of its decisions.

It is also where a common conceptual confusion needs to be handled carefully. Some vendor and implementation descriptions frame the authorization server as the thing that authenticates the user, while the OAuth 2.0 framework itself is a delegated authorization framework, not an authentication protocol. When authentication is required as part of the flow, it is typically provided by an OpenID Connect layer built on top of OAuth, or by the deployment's own login mechanism. Treating token issuance and user authentication as the same function can lead architects to make incorrect trust assumptions about what a given access token actually proves.

For teams building or integrating these systems, the practical stakes are high: the choice of grant types, whether an OIDC layer is present, and how the server is profiled all shape the security properties of everything that consumes its tokens. Understanding the authorization server's precise role, issuing tokens that represent granted access within a security domain, helps separate what the server guarantees from what still must be enforced elsewhere.

Who it's relevant to

Security Architects
Architects designing OAuth and OpenID Connect flows need to place the authorization server correctly in the trust model, distinguishing its token-issuance role from the resource server's enforcement role and deciding whether an OIDC layer is required for authentication in a given flow.
IAM Engineers
Engineers implementing or integrating authorization servers, for example using frameworks like Spring Authorization Server that follow the OAuth 2.1 and OpenID Connect 1.0 specifications, configure grant types, client registration, scopes, and token behavior, and must account for how authentication is handled in their specific deployment and profile.
System Administrators
Administrators operating the authorization server manage its availability and configuration as a dedicated IAM component that controls access to protected resources within a security domain, since its behavior directly affects every application and resource that relies on its tokens.
Compliance Officers
Compliance leads reviewing delegated access need to understand what an issued token actually represents, granted access to protected resources for a principal, and to recognize that token issuance is distinct from user authentication when assessing what an access token can be relied upon to prove.

Inside AS

Token Endpoint
The endpoint where the authorization server issues tokens (typically access tokens, and refresh tokens where configured) in exchange for a valid grant, such as an authorization code. Defined within the OAuth 2.0 framework.
Authorization Endpoint
The endpoint that interacts with the resource owner to obtain authorization, typically returning an authorization code or other grant artifact depending on the flow in use.
Grant Handling
Logic for processing the various OAuth 2.0 grant types (for example, authorization code, client credentials) supported by the deployment. The specific grants available depend on configuration and the authorization server implementation.
Client Registration and Authentication
Mechanisms for registering client applications and authenticating them when they request tokens. Client credentials and registration metadata are managed here.
Token Issuance and Signing Keys
For self-contained tokens such as JWTs, the authorization server holds the signing keys used to sign issued tokens. A signed token proves integrity and origin but is not the same as an encrypted token; signing alone does not provide confidentiality.
OIDC Layer (when applicable)
When OpenID Connect is deployed on top of OAuth 2.0, the authorization server also acts as the OpenID Provider, issuing ID tokens for authentication in addition to access tokens for delegated authorization. This capability depends on whether OIDC is configured.
Scope and Consent Management
Handling of requested scopes and, in most deployments, obtaining resource owner consent for the access being delegated to the client.

Common questions

Answers to the questions practitioners most commonly ask about AS.

Does the authorization server authenticate the user?
Not directly in the OAuth 2.0 model. In OAuth 2.0, the authorization server issues access tokens after obtaining the resource owner's authorization, but OAuth 2.0 itself is a delegated authorization framework and does not define how the user is authenticated. Authentication of the end user typically happens at an associated login step or, more formally, through OpenID Connect (OIDC Core), which layers an authentication mechanism on top of OAuth 2.0 and adds the ID token. In many deployments the same server plays both the OAuth 2.0 authorization server and the OIDC OpenID Provider roles, which is why the two functions are often conflated. Keep them separate: the authorization server's defined job is authorization and token issuance, while user authentication is an adjacent concern handled by the OIDC layer or an upstream identity provider depending on configuration.
Is the authorization server the same thing as the resource server?
No. They are distinct roles in the OAuth 2.0 model, even when a single product bundles them. The authorization server issues tokens after authorizing the request; the resource server hosts the protected resources and accepts tokens to grant or deny access. In practice the authorization server is concerned with token issuance, while the resource server performs token validation and enforces access at request time. Conflating them obscures the trust boundary: the resource server must independently validate the tokens it receives rather than assume they are valid because they came from a trusted issuer. Depending on deployment, these roles may run as separate services or be co-located, but the responsibilities remain logically separate.
How does a resource server validate a token issued by the authorization server?
It depends on the token format. For self-contained tokens such as signed JWTs, the resource server can typically validate the signature using the authorization server's published keys (commonly retrieved from a JWKS endpoint), then check claims such as issuer, audience, expiration, and scope. For opaque tokens, the resource server generally cannot inspect the token locally and instead calls the authorization server's introspection endpoint to determine whether the token is active and what it grants. Note that a signed token proves integrity and origin but is not encrypted, so its contents may be readable unless additional encryption is applied. The exact validation steps vary by profile and configuration.
What is the difference between an access token and an ID token issued by the server?
They serve different purposes. An access token, defined in OAuth 2.0, represents delegated authorization and is presented to a resource server to access protected resources; the client is generally not meant to interpret its contents. An ID token, defined by OpenID Connect, is intended for the client and conveys authentication information about the end user through its claims. Using an ID token as an access token, or a raw access token as proof of authentication, is a common misuse. A refresh token, where issued and permitted by configuration, is a separate credential used to obtain new access tokens without repeating the full authorization flow.
Which grant type should a client use with the authorization server?
This depends on the client type and the deployment context, so there is no single answer. In current guidance for public clients such as browser-based and mobile apps, the authorization code flow with PKCE is typically recommended. Confidential clients, such as server-side applications that can protect a secret, may use the authorization code flow with client authentication. Service-to-service scenarios with no end user often use the client credentials grant. Some older grants have fallen out of favor in many profiles. Because supported grants and their constraints vary by authorization server implementation and profile, confirm against your server's documentation and the applicable security best current practice.
How does the authorization server relate to a policy decision point (PDP)?
They address different layers and should not be blurred. The authorization server operates in the OAuth 2.0/OIDC token issuance context, granting scopes and issuing tokens. A PDP, in a policy-based or attribute-based access control architecture, evaluates access requests against policy at runtime, often supported by a PIP for attributes and enforced by a PEP. In some deployments the authorization server incorporates policy evaluation when deciding what to include in a token, and the resource server may still consult a PDP for fine-grained enforcement. Whether these are combined or separated depends on the architecture and configuration; treat token issuance and runtime policy decisioning as distinct responsibilities.

Common misconceptions

The authorization server authenticates users, so OAuth 2.0 alone is an authentication protocol.
OAuth 2.0 is a delegated authorization framework, not an authentication protocol. An authorization server authenticates users for the purpose of authentication only when OpenID Connect (which layers on top of OAuth 2.0) is in use and it issues ID tokens. Access tokens issued under OAuth 2.0 alone convey delegated authorization, not verified user identity to the client.
Tokens issued by the authorization server are encrypted because they are signed.
Signing and encryption are distinct. Self-contained tokens such as JWTs are typically signed to guarantee integrity and origin, but a signed token's contents remain readable unless the token is also encrypted. Encryption is a separate, optional configuration.
The authorization server enforces access decisions at resource endpoints.
The authorization server issues tokens; it is not the component that enforces access at the protected resource. Runtime enforcement (validating the token and applying policy) occurs at the resource server or an enforcement point, which are separate concerns from token issuance.

Best practices

Deploy OpenID Connect on top of OAuth 2.0 when the requirement is authenticating users, and rely on ID tokens for identity rather than treating access tokens as proof of who the user is.
Distinguish token types explicitly in configuration and downstream handling: use access tokens for delegated authorization, ID tokens for authentication where OIDC is present, and refresh tokens only where long-lived access is intended.
Protect and rotate the signing keys used for self-contained tokens, and apply token encryption separately where confidentiality of token contents is required, since signing does not provide it.
Authenticate clients at the token endpoint and grant only the scopes actually needed, applying resource owner consent in most deployments to keep delegated authorization narrowly bounded.
Restrict enabled grant types to those the deployment actually requires, avoiding grants that are unnecessary or weaker for the given client type.
Keep token issuance (the authorization server's role) separate from runtime enforcement at resource servers, and document which component validates tokens and applies policy so responsibilities are not blurred.
Promotional banner graphic asking if you are ready for PCI DSS 4.0 with a call-to-action to get the guide