Category: OAuth & OIDC
Delegated Authorization
Also known as: delegated access
Simply put
Delegated authorization is a pattern that lets an application, integration, or agent perform actions on behalf of a user after the user has given explicit consent. Instead of sharing their password, the user grants the application a limited set of permissions to access their resources. This keeps the user in control of what the application is allowed to do.
Formal definition
Delegated authorization is an authorization pattern, most commonly implemented with the OAuth 2.0 framework, in which a resource owner grants a client a scoped subset of privileges to access protected resources on the owner's behalf, without the client obtaining the owner's credentials. In typical OAuth 2.0 deployments, the client obtains an access token representing the delegated privileges following user consent, and Microsoft's delegated access model applies this when a signed-in user works with their own resources or resources they can access. Note that OAuth 2.0 is a delegated authorization framework, not an authentication protocol; establishing user identity requires an authentication layer such as OpenID Connect. Some emerging work, such as the IETF Internet-Draft draft-li-oauth-delegated-authorization, describes further delegating a subset of granted privileges to a subordinate access token, though that draft is an unendorsed Internet-Draft with no formal standing and its details may change.
Why it matters
Before delegated authorization patterns became widespread, applications that needed to act on a user's behalf often resorted to collecting and storing the user's actual credentials, the so-called password anti-pattern. That approach gave third-party applications unlimited standing access to a user's account, made credential rotation painful, and offered no way to scope or revoke access short of changing the password. Delegated authorization addresses this by letting the resource owner grant a client a scoped subset of privileges after explicit consent, without ever handing over their credentials.
Who it's relevant to
Security Architects
Architects designing integration and API access strategies rely on delegated authorization to avoid the password anti-pattern and to enforce scoped, revocable access. They must ensure that OAuth 2.0 flows are used strictly for authorization and that user identity, when needed, is established through an appropriate authentication layer such as OpenID Connect rather than inferred from an access token.
IAM Engineers
Engineers implementing delegated access configure scopes, consent flows, and access token issuance so that clients receive only the privileges the resource owner has granted. In Microsoft Entra deployments, this maps to the delegated access model used when a signed-in user works with their own resources or resources they can access.
Developers Building Integrations and Agents
Application, integration, and increasingly agent developers use delegated authorization to perform actions on behalf of users after explicit consent, without handling user credentials. They should scope requested permissions to what is actually needed and avoid using OAuth 2.0 access tokens as a stand-in for proof of who the user is.
Compliance and Governance Leads
Governance stakeholders care that delegated access keeps users in control of what an application may do and that consent is explicit and scoped. This supports least-privilege objectives, though the ability to review and revoke delegated grants depends on the specific vendor and deployment configuration.
Inside Delegated Authorization
Resource Owner
The principal (typically an end user) who owns the protected resource and grants permission for a third party to access it on their behalf. The resource owner authorizes access without sharing their own credentials with the client.
Client
The application requesting access to protected resources on behalf of the resource owner. In OAuth 2.0 terms, clients are typically classified as confidential or public depending on their ability to securely maintain credentials.
Authorization Server
The component that authenticates the resource owner (in most flows via a redirect), obtains their consent, and issues access tokens to the client. Note that the authentication of the resource owner is a separate step from the delegated authorization decision itself.
Resource Server
The server hosting the protected resources that accepts and validates access tokens, then serves requests according to the scope granted. Token validation here is a runtime enforcement concern distinct from how the token was issued.
Access Token
The credential the client presents to the resource server to access resources within the granted scope. Access tokens may be opaque or self-contained (for example a JWT); a signed token proves integrity and origin but is not necessarily encrypted or confidential.
Scope
A mechanism for expressing and limiting the extent of access being delegated, allowing the resource owner to consent to a bounded set of permissions rather than full account access.
Grant / Authorization Grant
The credential or flow representing the resource owner's authorization, which the client exchanges for an access token. OAuth 2.0 defines several grant types suited to different client and deployment contexts.
Common questions
Answers to the questions practitioners most commonly ask about Delegated Authorization.
Does delegated authorization authenticate the user for the client application?
No. Delegated authorization, as framed by OAuth 2.0, is about granting a client limited access to resources on a resource owner's behalf; it does not authenticate the end user to the client. OAuth 2.0 by itself conveys no verified assertion of user identity. If the client needs to authenticate the user, it should use OpenID Connect (OIDC Core), the authentication layer built on top of OAuth 2.0, which introduces an ID token for that purpose. Treating a raw OAuth 2.0 access token as proof of who the user is conflates authorization with authentication.
Is the access token issued through delegated authorization proof of the user's identity that the client can inspect?
Generally no. An access token is intended for the resource server, not the client, and its format and audience are typically determined by the authorization server and resource server. Depending on configuration it may be opaque or self-contained (for example a JWT), but even when it is a JWT the client should not treat its contents as an authentication result. Identity information about the user is conveyed by the ID token in OpenID Connect, not by the access token used for delegated resource access.
Which OAuth 2.0 grant type is appropriate for delegated authorization on behalf of a user?
For a user delegating access to a client, the authorization code grant is the commonly recommended flow, typically combined with PKCE for public clients such as single-page and mobile applications. The choice depends on client type and deployment context, and some legacy flows are discouraged in current guidance. Because grant selection varies by profile and evolving best practice, confirm the recommended flow against your authorization server's supported grants and current OAuth security guidance rather than assuming a single default.
How should scopes be defined to limit what a delegated client can access?
Scopes express the subset of access the resource owner delegates to the client, and they are most effective when defined narrowly enough to reflect least privilege for specific resource operations. In most deployments the resource server ultimately enforces what a token permits, so scopes coordinate intent between authorization server and resource server rather than serving as complete access control on their own. Scope granularity, naming, and enforcement semantics vary by API and vendor, so align them with your resource server's authorization model.
How does a resource server validate a token received through delegated authorization?
Validation depends on token type. For opaque tokens, resource servers typically call the authorization server's introspection endpoint to check validity, audience, scope, and expiry. For self-contained tokens such as JWTs, the resource server can validate the signature against the authorization server's published keys and check claims like issuer, audience, and expiration locally. Note that a signed token is verified for integrity and origin but is not necessarily encrypted, so it should not carry data that must remain confidential from parties who can read it.
How should refresh tokens be handled in a delegated authorization deployment?
Refresh tokens let a client obtain new access tokens without re-involving the resource owner, so they are typically longer-lived and higher-value than access tokens and warrant stronger protection. Common practices, depending on configuration, include restricting them to confidential clients or applying refresh token rotation and reuse detection for public clients, along with binding, revocation support, and secure storage. Because handling differs across authorization servers and profiles, verify the supported protections against your specific implementation rather than assuming defaults.
Common misconceptions
Delegated authorization via OAuth 2.0 authenticates the user for the client.
OAuth 2.0 is a delegated authorization framework, not an authentication protocol. It conveys what a client may do, not a verified assertion of who the user is. To obtain authenticated user identity, an authentication layer such as OpenID Connect (built on top of OAuth 2.0) is used, which returns an ID token distinct from an access token.
An access token being signed means its contents are protected from being read.
Signing provides integrity and origin verification, not confidentiality. A self-contained token such as a JWT is typically only encoded and signed, so its claims can be read unless the token is additionally encrypted. Do not treat a signed token as an encrypted one.
Delegated authorization means the client receives the resource owner's credentials.
The purpose of delegated authorization is precisely to avoid sharing the resource owner's credentials with the client. The client instead receives a scoped access token issued by the authorization server, limiting exposure and enabling revocation independent of the user's primary credentials.
Best practices
Select the OAuth 2.0 grant type appropriate to the client type and deployment context, and prefer flows that avoid exposing credentials to public clients.
Request the minimum scopes necessary for the client's function so the delegated access is bounded to what the resource owner actually consented to.
Validate access tokens at the resource server on every request, checking signature (or introspecting opaque tokens), issuer, audience, expiry, and scope before serving protected resources.
Keep the resource owner authentication step and the consent/authorization step distinct, and use OpenID Connect rather than OAuth 2.0 alone when the client needs verified user identity.
Treat access tokens as bearer credentials that require confidentiality in transit and at rest; do not rely on signing to protect claim contents, and apply encryption where claim confidentiality is required.
Support token revocation and short-lived access tokens with refresh tokens where appropriate, so delegated access can be withdrawn without changing the resource owner's primary credentials.
