Logo

Ena OAuth 2.0 Interoperability Profile

Version: 1.0 - draft 01 - 2025-10-16

Abstract

The OAuth 2.0 framework defines mechanisms that allow users (resource owners) to delegate access rights to a protected resource for an application they are using. Additionally, OAuth 2.0 protocols are often used without user involvement in service-to-service scenarios.

Over the years, numerous extensions and features have been introduced, making “OAuth 2.0” an insufficient label to guarantee interoperability between parties. Therefore, this document defines a profile for OAuth 2.0 to enhance interoperability, strengthen security, and enable more efficient and cost-effective deployments. While the profile is primarily intended for Swedish public and private services and organizations, it is not limited to them.

Table of Contents

  1. Introduction

    1.1. Requirements Notation and Conventions

    1.2. Terminology

    1.3. Conformance

    1.4. Limitations and Exclusions

    1.5. The User and Resource Owner Distinction

  2. Client Profile

    2.1. Types of OAuth Clients

    2.2. Client Metadata and Registration

    2.2.1. Client Identifiers

    2.2.2. Client Registration Metadata

    2.3. Connections to Protected Resources

  3. Authorization Server Profile

    3.1. Metadata and Discovery

    3.1.1. Authorization Server Metadata

    3.1.2. Authorization Server Metadata Publishing

    3.2. Client Registration

    3.3. Authorization Server Endpoints

    3.3.1. Authorization Endpoint

    3.3.2. Token Endpoint

    3.4. Configuration of Protected Resources

  4. Protected Resource Profile

    4.1. Validation of Access Tokens

    4.2. Resource Server Error Responses

    4.3. Protected Resource Identity and Registration

    4.4. Protected Resource Access Requirements Modelling

  5. Grant Types

    5.1. Authorization Code Grant

    5.1.1. Authorization Requests

    5.1.2. Authorization Responses

    5.1.3. Access Token Requests and Responses

    5.2. Refresh Token Grant

    5.3. Client Credentials Grant

    5.4. Other Grant Types

    5.4.1. SAML Assertion Authorization Grants

    5.4.2. JWT Authorization Grants

    5.5. Prohibited Grant Types

  6. Tokens

    6.1. Access Tokens

    6.1.1. The Audience Claim

    6.1.2. The Subject Claim

    6.2. Refresh Tokens

  7. Optional Extensions

    7.1. The Resource Parameter

    7.2. JAR – JWT-Secured Authorization Requests

    7.3. PAR – OAuth 2.0 Pushed Authorization Requests

  8. Security Requirements and Considerations

    8.1. General Security Requirements

    8.2. Cryptographic Algorithms

    8.3. Client Authentication

    8.3.1. Signed JWT for Client Authentication

    8.3.2. Mutual TLS for Client Authentication

    8.4. OAuth 2.0 Security Mechanisms

    8.4.1. PKCE – Proof Key for Code Exchange

    8.4.2. DPoP – Demonstrating Proof of Possession

    8.4.3. Binding Access Tokens to Client Certificates using Mutual TLS

    8.5. Threats and Countermeasures

    8.5.1. Injection of Authorization Code

    8.5.2. Token Theft and Leakage

    8.5.3. Authorization Server Mix-Up Attacks

    8.5.4. Insufficient Validation of Redirect URIs

    8.5.5. Open Redirects

  9. Requirements for Interoperability

    9.1. Defining and Using Scopes

    9.2. Using OpenID Connect Identity Scopes

  10. References

    10.1. Normative References

    10.2. Informational References

1. Introduction

This document defines a profile for the OAuth 2.0 authorization framework, establishing a baseline for interoperability and security for Swedish services.

It does not specify any sector-specific extensions or profile existing OAuth 2.0 extensions, except where required by this profile. However, such extensions may be defined in separate profiles that reference this document.

1.1. Requirements Notation and Conventions

The keywords “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” are to be interpreted as described in [RFC2119].

These keywords are capitalized when used to unambiguously specify requirements over protocol features and behavior that affect the interoperability and security of implementations. When these words are not capitalized, they are meant in their natural-language sense.

1.2. Terminology

The OAuth 2.0 Authorization Framework, [RFC6749], defines the following roles:

The OAuth 2.0 Authorization Framework: Bearer Token Usage, [RFC6750], defines:

Clarification on the distinction between a Resource Server and a Protected Resource:

Some of the early OAuth 2.0 specifications used only the term Resource Server to denote the entity to which access is delegated. More recent specifications use the term Protected Resource, which is a more accurate and appropriate designation. This profile adopts the term Protected Resource when referring to the resource being protected and its access rules, and reserves the term Resource Server specifically for the server that hosts the Protected Resource, and is capable of accepting and processing access tokens.

1.3. Conformance

The profile document defines requirements for OAuth 2.0 protected resources, authorization servers, and clients.

When an entity compliant with this profile interacts with other entities that also conform to this profile, in any valid combination, all entities MUST fully adhere to the features and requirements of this specification. Interactions with non-compliant entities are outside the scope of this specification.

1.4. Limitations and Exclusions

1.5. The User and Resource Owner Distinction

OAuth 2.0 is a delegation protocol where a resource owner (the user) delegates their rights to an application (the client) to make a call to a protected resource on the user's behalf. However, this profile also supports other uses of OAuth 2.0 where an end-user is involved, but is not strictly the resource owner. Such cases may include scenarios such as:

In this profile, the term User refers to the authenticated end-user who interacts with the client and the authorization server. While OAuth 2.0 traditionally uses the term Resource Owner to denote the party granting access, in deployments realized using this profile, the user does not necessarily own the resources being accessed. Rather, the user acts as an authorized subject whose identity or role is evaluated as part of the access decision. Therefore, this profile favours the use of the term User over Resource Owner.

In cases where the user is not the actual resource owner, the consent dialogues at the authorization server are adapted to the specific use case.

2. Client Profile

2.1. Types of OAuth Clients

Within OAuth 2.0, there are two main types of clients: confidential clients and public clients. Confidential clients can securely store credentials registered with an authorization server, whereas public clients cannot store credentials securely. As pointed out in 1.4, Limitations and Exclusions, above, this profile applies only to confidential clients. An OAuth 2.0 public client is not compliant with this profile.

Note: This does not mean that mobile apps and JavaScript web applications are disqualified. However, to be regarded as confidential, such applications must securely store credentials, for example, in a backend component.

Since this profile only handles confidential clients, we also distinguish between different subtypes of confidential clients. There are two main subtypes:

These client subtypes correspond to the implementations of the Authorization Code Flow and Client Credentials Flow, respectively.

2.2. Client Metadata and Registration

This profile does not specify how an OAuth 2.0 client is registered with an authorization server or within a federation. This is out of scope for this profile.

However, for interoperability reasons, the requirements stated in the subsections below apply.

2.2.1. Client Identifiers

Every client compliant with this profile SHOULD be identified by a globally unique URL. This URL MUST use the HTTPS scheme and include a host component. It MUST NOT contain query or fragment components.

RFC6749 and RFC7591 specify that a client identifier is simply a unique string. However, since this profile also focuses on the use of OAuth 2.0 across security domains and within federations, the requirements for “Entity Identifiers” as defined in OpenID.Federation also apply.

A client operating in a federative context, where it is registered with multiple authorization servers, MUST use the same client identifier (client_id) for all registrations. Consequently, an authorization server compliant with this profile and operating within a federative context MUST support clients that use client identifiers issued by external parties.

A client identifier MUST NOT be assigned if its value could be mistaken for the identity of an end-user (see Section 4.15 of RFC9700). When client identifiers are represented as URLs, the risk of such confusion is low, but authorization servers MUST still ensure that the namespaces used for subject names (the sub claim and any other user identity claims) and client identifiers remain separate.

2.2.2. Client Registration Metadata

Section 2 of "OAuth 2.0 Dynamic Client Registration Protocol", [RFC7591], lists client metadata parameters, and entities compliant with this profile MUST adhere to the requirements in that section, with the extensions and clarifications stated in the subsections below.

Within a pure OAuth 2.0 context, there is no concept of a "client metadata document". The OAuth 2.0 specifications address how a client is registered with an authorization server, and if a client is registered with multiple authorization servers, the registration data may vary between them. Thus, the parameters in Section 2 of [RFC7591] should be regarded as client registration metadata for a particular registration, rather than as a client metadata document.

2.2.2.1. Redirect URIs

Metadata parameter: redirect_uris

The redirect_uris parameter is REQUIRED if the client is registered for the authorization_code grant type (or any other custom redirect-based flow). If set, at least one URI MUST be provided.

The redirect URIs provided MUST be absolute URIs, as defined in Section 4.3 of [RFC3986], to prevent mix-up attacks involving clients. See Section 4.1.1 of [RFC9700] for further details.

Redirect URIs MUST be one of the following:

If more than one redirect URI is provided, different domains SHOULD NOT be used.

See also Section 8.5.4, Insufficient Validation of Redirect URIs.

2.2.2.2. Token Endpoint Authentication Method

Metadata parameter: token_endpoint_auth_method

The token_endpoint_auth_method parameter is REQUIRED for the client metadata. It gives the client authentication method for accessing the authorization server token endpoint.

Section 8.3, Client Authentication, gives the requirements for how a client authenticates against the authorization server token endpoint. Thus, for clients compliant with this profile the token_endpoint_auth_method can be any of the following values:

A client operating in a federated context may use different methods for different authorization servers. This is out of scope for this profile and is addressed in [ENA.Federation].

2.2.2.3. Token Endpoint Grant Types

Metadata parameter: grant_types

The grant_types parameter is an array of grant type strings that the client can use at the token endpoint of an authorization server. The parameter is OPTIONAL, and if not present, the authorization_code grant type MUST be assumed.

The client metadata MUST NOT include the implicit and password grant types among the grant_types values. See Section 5.5, Prohibited Grant Types, below.

2.2.2.4. JSON Web Key Set

Metadata parameter: jwks or jwks_uri

The client's JSON Web Key Set [RFC7517] document, passed by value or reference (URI).

If the client has registered the private_key_jwt token endpoint authentication method, or if the client produces signatures in other circumstances, one, but not both, of the jwks and jwks_uri parameters is REQUIRED.

To facilitate a smooth key rollover, each JWK of the referenced document SHOULD include a kid parameter.

The JWKs provided in the key set MUST adhere to the requirements put in Section 8.2, Cryptographic Algorithms, below.

2.2.2.5. Scopes

Metadata parameter: scope

The scope parameter is a space-separated list of scope values that the client can use when requesting access tokens.

2.2.2.6. Human-readable Client Metadata

Client metadata values intended for human consumption, either directly or via reference (URIs), SHOULD be provided in both English and Swedish using language tags according to BCP 47, [RFC5646].

For maximum interoperability, it is RECOMMENDED to also include parameter values without language tags. This profile does not specify which language should be used as the default.

Examples:

{
  "client_name": "Example client",
  "client_name#sv": "Exampelklienten",
  "client_name#en": "Example client",
  ...
  "policy_uri": "https://www.example.com/policy",
  "policy_uri#sv": "https://www.example.com/policy/sv",
  "policy_uri#en": "https://www.example.com/policy",
  ...

For further requirements see Section 2.2 of [RFC7591].

2.2.2.7. Extensions

This section contains metadata parameters for optional OAuth 2.0 extensions that MAY be supported by a client.

Metadata parameter: dpop_bound_access_tokens

A client that always uses DPoP for token requests MUST register the dpop_bound_access_tokens parameter and set its value to true. See Section 8.4.2, DPoP - Demonstrating Proof of Possession and Section 5.2 of [RFC9449].

Metadata parameter: tls_client_certificate_bound_access_tokens

A client that will requests mutual TLS client certificate-bound access tokens MUST register the tls_client_certificate_bound_access_tokens parameter and set its value to true. See Section 3.4 of [RFC8705].

Metadata parameter: require_signed_request_object

Indicates where authorization request needs to be protected as Request Object and provided through either request or request_uri parameter. See Section 10.5 of [RFC9101] and Section 7.2, JAR – JWT-Secured Authorization Requests.

Metadata parameter: require_pushed_authorization_requests

Indicates whether the client is required to use PAR to initiate authorization requests. See Section 6 of [RFC9126].

2.3. Connections to Protected Resources

An OAuth 2.0 client accesses a protected resource by including an access token in its request to the resource server. This section outlines the requirements for how a client compliant with this profile should present an access token in requests to the resource server.

All authorized requests from a client to a resource server MUST be protected by TLS according to Section 8.1, General Security Requirements, below.

Clients adhering to this profile SHOULD send the access token in the Authorization header using the Bearer scheme according to Section 2.1 of [RFC6750].

Example:

GET /data HTTP/1.1
Host: api.example.com
Authorization: Bearer eyJhbGciOiJFUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3 \
ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWUsImlhdCI6MTUxNjIzOTAyMn0.tyhVfuz \
IxCyGYDlkBA7DfyjrqmSHu6pQ2hoZuFqUSLPNY2N0mpHb3nk5K17HWP_3cYHBw7AhHale5wky6-sVA

Clients MAY send the access token in an HTTP request by including it as a form-encoded content parameter named access_token, as defined by Section 2.2 of [RFC6750].

Clients MUST NOT include the access token as a URI query parameter (Section 2.3 of [RFC6750]). The reason is that the access token would be visible in the URL and could be stolen by attackers, for example, from the web browser history. Consequently, a resource server compliant with this profile MUST NOT accept an access token transmitted in a query parameter.

Clients MUST support and be able to process the WWW-Authenticate response header field as specified by Section 3 of [RFC6750].

3. Authorization Server Profile

All authorization servers compliant with this profile MUST adhere to the security requirements stated in Section 8, Security Requirements and Considerations.

3.1. Metadata and Discovery

This section contains requirements on an authorization server's metadata document and how this metadata document is published on a well-known location.

An authorization server that acts as an OpenID Provider MUST also adhere to Section 5.2, "Discovery Requirements for an OpenID Provider", of [OIDC.Sweden.Profile].

3.1.1. Authorization Server Metadata

An authorization server compliant with this profile MUST produce a metadata JSON document as specified in Section 2 of [RFC8414], with the extensions and clarifications stated in the subsections below.

An authorization server MAY provide signed metadata as specified in Section 2.1 of [RFC8414]. In such cases, the authorization server MUST sign the metadata using one of the mandatory signature algorithms listed in Section 8.2, Cryptographic Algorithms.

Note: Additional requirements for authorization server metadata may be supplied in other profiles.

3.1.1.1. Issuer - The Authorization Server Entity Identifier

Metadata parameter: issuer

The issuer parameter is REQUIRED and MUST be a globally unique URL. This URL MUST use the HTTPS scheme and include a host component. It MUST NOT contain query or fragment components.

The authorization server metadata is published at a location derived from its issuer identifier. See Section 3.1.2, Authorization Server Metadata Publishing, below. This means that if the authorization server is hosted under a path other than the root, the issuer value MUST reflect this. For example, https://as.example.com/service would be the correct issuer value if the authorization server is deployed under the /service path at the as.example.com host.

3.1.1.2. Authorization Server Endpoints

Metadata parameter: authorization_endpoint

The authorization_endpoint parameter contains the fully qualified URL of the authorization server’s authorization endpoint, as defined in [RFC6749]. This parameter is REQUIRED unless the authorization server does not support any grant types that make use of the authorization endpoint.

The authorization endpoint URL MUST NOT include a fragment component, but MAY include a query string.

Metadata parameter: token_endpoint

The token_endpoint parameter contains the fully qualified URL of the authorization server’s token endpoint, as defined in [RFC6749]. This parameter is REQUIRED.

The token endpoint URL MUST NOT include a fragment component, but MAY include a query string.

Metadata parameter: pushed_authorization_request_endpoint

URL of the authorization server's pushed authorization request endpoint. See Section 5 of [RFC9126]. The parameter is REQUIRED for authorization servers supporting Pushed Authorization Requests (PAR), see Section 7.3, PAR – OAuth 2.0 Pushed Authorization Requests.

The parameters registration_endpoint, revocation_endpoint and introspection_endpoint are OPTIONAL, and their presence depends on whether the authorization server supports the corresponding features.

3.1.1.3. JSON Web Key Set

Metadata parameter: jwks_uri

The jwks_uri parameter is REQUIRED, and contains an URL to the authorization server's JSON Web Key Set [RFC7517] document. This URL MUST use the HTTPS scheme.

The use parameter is REQUIRED for all keys in the referenced JWK Set to indicate each key's intended usage.

To facilitate a smooth key rollover, each JWK of the referenced document SHOULD include a kid parameter.

The JWKs provided in the key set MUST adhere to the requirements put in Section 8.2, Cryptographic Algorithms, below.

3.1.1.4. Supported Scopes

Metadata parameter: scopes_supported

The scopes_supported parameter is REQUIRED and it SHOULD list all scopes supported by the authorization server in a JSON array. Authorization servers MAY choose to omit certain scopes that are client-specific or otherwise not intended for general use.

3.1.1.5. Supported Grant Types

Metadata parameter: grant_types_supported

The requirements of this profile are the same as those specified in Section 2 of [RFC8414], with the following exception:

If the parameter is omitted, the default value SHALL be [ "authorization_code" ].

3.1.1.6. Supported Endpoint Authentication Methods

Metadata parameter: token_endpoint_auth_methods_supported

The token_endpoint_auth_methods_supported parameter is REQUIRED and MUST include private_key_jwt. It MAY also include tls_client_auth or self_signed_tls_client_auth, but MUST NOT include any other methods. See Section 8.3, Client Authentication, below.

Metadata parameter: revocation_endpoint_auth_methods_supported

The revocation_endpoint_auth_methods_supported parameter is REQUIRED if the authorization server supports token revocation (i.e., if the revocation_endpoint parameter is included). If present, the contents of this parameter MUST follow the same requirements as the token_endpoint_auth_methods_supported parameter (see above).

Metadata parameter: introspection_endpoint_auth_methods_supported

The introspection_endpoint_auth_methods_supported parameter is REQUIRED if the authorization server supports token introspection (i.e., if the introspection_endpoint parameter is included). If present, the contents of this parameter MUST follow the same requirements as the token_endpoint_auth_methods_supported parameter (see above).

3.1.1.7. Supported Authentication Signing Algorithms for Endpoints

Metadata parameter: token_endpoint_auth_signing_alg_values_supported

The token_endpoint_auth_signing_alg_values_supported parameter is REQUIRED, and its contents MUST conform to the signature requirements specified in Section 8.2, Cryptographic Algorithms.

Metadata parameter: revocation_endpoint_auth_methods_supported

The revocation_endpoint_auth_methods_supported parameter is REQUIRED if revocation_endpoint_auth_methods_supported is assigned. If present, the contents of this parameter MUST follow the same requirements as the token_endpoint_auth_signing_alg_values_supported parameter (see above).

Metadata parameter: introspection_endpoint_auth_methods_supported

The introspection_endpoint_auth_methods_supported parameter is REQUIRED if introspection_endpoint_auth_methods_supported is assigned. If present, the contents of this parameter MUST follow the same requirements as the token_endpoint_auth_signing_alg_values_supported parameter (see above).

3.1.1.8. Supported Code Challenge Methods

Metadata parameter: code_challenge_methods_supported

An authorization server compliant with this profile MUST support the PKCE extension (see Section 8.4.1, PKCE - Proof Key for Code Exchange. Therefore, the code_challenge_methods_supported parameter is REQUIRED and MUST include the S256 challenge method. The plain challenge method MUST NOT be supported.

3.1.1.9. Supported UI Locales

Metadata parameter: ui_locales_supported

The ui_locales_supported parameter SHOULD be present and include Swedish (sv) and English (en).

3.1.1.10. Extensions

This section contains metadata parameters for optional OAuth 2.0 extensions that MAY be supported by an authorization server.

Metadata parameter: protected_resources

The protected_resources metadata parameter, as defined in Section 4 of [RFC9728], contains a JSON array of resource identifiers for OAuth protected resources that can be used with this authorization server. Its use is RECOMMENDED for authorization servers compliant with this profile.

Metadata parameter: authorization_response_iss_parameter_supported

The authorization_response_iss_parameter_supported metadata parameter, as defined in [RFC9207], indicates whether the authorization server supports including the iss (issuer) parameter in authorization responses to protect against Authorization Server Mix-Up Attacks. An authorization server operating within a federation or serving clients that interact with multiple authorization servers SHOULD support the iss parameter and therefore set this metadata value to true.

Metadata parameter: dpop_signing_alg_values_supported

The dpop_signing_alg_values_supported parameter is assigned a JSON array listing the JWS algorithms supported by the authorization server for DPoP proof JWTs. The presence of this parameter signals that the authorization server supports the DPoP mechanism. See Section 8.4.2, DPoP - Demonstrating Proof of Possession and [RFC9449].

Metadata parameter: mtls_endpoint_aliases

Authorization servers that support both mutual TLS clients as specified in [RFC8705] and conventional clients MAY choose to use separate endpoints for mutual TLS. In such cases, the mtls_endpoint_aliases parameter SHOULD be included in the authorization server metadata. See Section 5 of [RFC8705].

Metadata parameter: tls_client_certificate_bound_access_tokens

The tls_client_certificate_bound_access_tokens parameter indicates authorization server support for mutual TLS client certificate-bound access tokens. See Section 3.3 of [RFC8705].

Metadata parameter: require_signed_request_object

Indicates where authorization request needs to be protected as Request Object and provided through either request or request_uri parameter. See Section 10.5 of [RFC9101] and Section 7.2, JAR – JWT-Secured Authorization Requests. MAY be assigned by authorization servers supporting JAR according to [RFC9101].

Metadata parameter: https://id.oidc.se/disco/authnProviderSupported

The parameter tells whether the request extension parameter https://id.oidc.se/param/authnProvider is supported by the authorization server. See [OIDC.Sweden.Parameters] and Section 5.1.1.1, Extension Parameter for Controlling User Authentication at the Authorization Server.

3.1.1.11. Authorization Server Metadata Example

Below is an example of the metadata document for an authorization server:

{
  "issuer": "https://as.example.com/",
  "authorization_endpoint": "https://as.example.com/authorize",
  "token_endpoint": "https://as.example.com/token",
  "jwks_uri": "https://as.example.com/jwk",
  "scopes_supported": [
    "https://server1.example.com/api/read",
    "https://server1.example.com/api/write",
    "https://server2.example.com/read",
    "https://server2.example.com/write"
  ],
  "response_types_supported": [ "code", "token" ],
  "grant_types_supported": [ "authorization_code", "refresh_token", "client_credentials" ],  
  "token_endpoint_auth_methods_supported": [ "private_key_jwt" ],
  "token_endpoint_auth_signing_alg_values_supported": [
    "RS256", "RS384", "RS512", "ES256", "ES384", "ES512"
  ],
  "service_documentation": "https://as.example.com/docs/register",
  "ui_locales_supported": [ "sv", "en" ], 
  "op_policy_uri": "https://as.example.com/docs/policy",
  "code_challenge_methods_supported": [ "S256" ]  
}

Note: If the authorization server also acts as an OpenID Provider, additional metadata parameters will appear in the metadata document.

3.1.2. Authorization Server Metadata Publishing

Section 3 of [RFC8414] states the following:

"Authorization servers supporting metadata MUST make a JSON document containing metadata as specified in Section 2 available at a path formed by inserting a well-known URI string into the authorization server's issuer identifier between the host component and the path component, if any. By default, the well-known URI string used is /.well-known/oauth-authorization-server.".

For an authorization server whose issuer identifier has no path component, for example, https://as.example.com, the resulting discovery URL is:

https://as.example.com/.well-known/oauth-authorization-server

However, if the authorization server is not deployed at the root but instead under a path such as /service, its issuer identifier becomes https://as.example.com/service. In this case, according to [RFC8414], the discovery URL must be:

https://as.example.com/.well-known/oauth-authorization-server/service

This construction may lead to practical deployment challenges, as it requires control over the root path of the host.

Section 4.1 of [OpenID.Discovery] specifies a more pragmatic approach for constructing the discovery URL: the well-known URI suffix is appended to the issuer identifier. Using this method, an authorization server with the issuer https://as.example.com/service would publish its metadata at:

https://as.example.com/service/.well-known/oauth-authorization-server

This approach is more practical but does not fully comply with the requirements in Section 3 of [RFC8414]. Therefore, this profile defines the following requirements:

3.2. Client Registration

This profile does not specify how a client is registered with the authorization server. Registration may be performed statically, via an out-of-band procedure, through dynamic registration as specified in [RFC7591], or by resolving client metadata using OpenID Federation.

An authorization server compliant with this profile MUST ensure that the metadata of a client being registered complies with the requirements stated in Section 2.2.2, Client Registration Metadata, and MUST NOT complete the registration if the metadata does not comply.

If a client identifier is assigned by the authorization server at registration time, the identifier MUST comply with the requirements stated in Section 2.2.1, Client Identifiers.

An authorization server compliant with this profile MUST support the registration of a client that already has an assigned client identifier.

3.3. Authorization Server Endpoints

This section outlines the general requirements for the HTTP endpoints exposed by an authorization server compliant with this profile. Specific requirements regarding the messages received on these endpoints are detailed in Section 5, Grant Types.

3.3.1. Authorization Endpoint

Authorization servers compliant with this profile MUST adhere to the requirements from Section 3.1, "Authorization Endpoint", of [RFC6749], with the following extensions:

The authorization endpoint MUST be protected by TLS according to Section 8.1, General Security Requirements.

The authorization server MUST NOT support CORS (Cross-Origin Resource Sharing) at the authorization endpoint since the client does not access this endpoint directly.

An authorization server that redirects a request MUST NOT use the 307 HTTP status code. If an HTTP redirection is used (as opposed to JavaScript-based redirection), the authorization server SHOULD use the 303 HTTP status code.

This requirement exists because, at the authorization endpoint, the authorization server may prompt the user to enter credentials into a form, which is then submitted via a POST request. After verifying the credentials, the authorization server redirects the user agent to the client’s redirect URI. If a 307 status code were used for redirection, the user agent would incorrectly reuse the POST method, potentially sending the user’s credentials directly to the client. See Section 15.4.8 of [RFC9110].

See Section 5.1.1, Authorization Requests for requirements specific to the authorization code grant.

3.3.2. Token Endpoint

Authorization servers compliant with this profile MUST adhere to the requirements from Section 3.2, "Token Endpoint" of [RFC6749], with the extension that clients MUST authenticate using one of the methods listed in Section 8.3, Client Authentication when making requests to the token endpoint.

The token endpoint is used by different grant types, and specific requirements for each profiled grant type are listed in Section 5, Grant Types. The subsections below list the general requirements for token requests and responses.

3.3.2.1. Token Requests

The following request parameters are REQUIRED for the client to pass to the authorization server’s token endpoint, regardless of the grant type being used:

Additional request parameters that are specific to each grant type apply and are specified for the respective grant type. See Section 5, Grant Types.

The client making the token request MUST authenticate using either the private_key_jwt method or, if supported by the authorization server and permitted by policy, Mutual TLS. See Section 8.3.1, Signed JWT for Client Authentication and Section 8.3.2, Mutual TLS for Client Authentication for further requirements. The authorization server MUST reject any token request that lacks client authentication or uses a method not permitted by this profile.

If private_key_jwt client authentication is used, the authorization server MUST verify that the sub and iss claims of the client assertion JWT (see Section 8.3.1) are equal to the client_id request parameter of the token request. Otherwise, the request MUST be rejected.

The authorization server MUST authenticate the client request before proceeding.

Here is an example of an access token request using an authorization code, where private_key_jwt is used for client authentication:

POST /token HTTP/1.1
Host: as.example.com
Content-Type: application/x-www-form-urlencoded

grant_type=authorization_code
&code=z9X8v7W6u5Ts4Rq3P2oNmL
&redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcallback
&code_verifier=a7b6c5d4e3f2g1h0i9j8k7l6m5n4o3p2q1r0s9t8u7v6w5x4y3z2a1b0c9d8e7f6
&client_id=https%3A%2F%2Fclient.example.com
&client_assertion_type=urn%3Aietf%3Aparams%3Aoauth%3Aclient-assertion-type%3Ajwt-bearer
&client_assertion=eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJodHRwczovL2NsaWVudC5leGFtcGxlL \
mNvbSIsInN1YiI6Imh0dHBzOi8vY2xpZW50LmV4YW1wbGUuY29tIiwiYXVkIjoiaHR0cHM6Ly9hcy5leGFtcGxlLmNvbSIsI \
mV4cCI6MTY4MDAwMDAwMCwiaWF0IjoxNjgwMDAwMDAwLCJqdGkiOiJxa2x3ZWZka2pmcWx1cm1jdHZuZXZ5bXhwIn0.RGViX \
2V4YW1wbGVTaWduYXR1cmVIZXJl

3.3.2.2. Token Responses

After the authorization server has successfully processed an access token request, issued an access token, and optionally a refresh token, it creates an HTTP response with status 200 and uses the application/json media type.

Entities compliant with this profile MUST adhere to Section 5.1, “Successful Response,” of [RFC6749] with the extensions and clarifications listed below.

The following parameter requirements apply for authorization servers compliant with this profile:

Example of a token response message holding an access token (in the form of a signed JWT) along with a refresh token:

HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: no-store

{
  "access_token": "eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJ1c2VyMTIzIiwiYXVkIjoiY2xpZW50LmV4YW \ 
                   1wbGUuY29tIiwiaWF0IjoxNjgwMDAwMDAwLCJleHAiOjE2ODAwMDM2MDB9.XYZ123abc456DEF789ghiJKL \
                   012mno345PQR678stu",
  "token_type": "Bearer",
  "expires_in": 600,
  "refresh_token": "d8p4QwF3a1Lb6Xt9WcG0Zv",
  "scope": "read write"
}

3.3.2.3. Error Responses

Authorization servers compliant with this profile MUST adhere to Section 5.2, “Error Response,” of [RFC6749], with the following additions:

It is RECOMMENDED that the error_description parameter be included in the error response to provide additional information about the error. The text provided MUST NOT reveal sensitive information, violate user privacy, or expose details that could be useful to an attacker.

Example:

HTTP/1.1 400 Bad Request
Content-Type: application/json;charset=UTF-8
Cache-Control: no-store
Pragma: no-cache

{
  "error": "invalid_client",
  "error_description": "The client authentication method is not supported"
}

3.4. Configuration of Protected Resources

An authorization server issues access tokens for accessing one or more protected resources. Each protected resource, along with its access requirements, must be configured at the authorization server. This configuration may include:

Some of the above settings may be available from the protected resource metadata, if the resource supports "OAuth 2.0 Protected Resource Metadata" [RFC9728].

As a general rule of thumb, an authorization server's configuration for a protected resource SHOULD cover all aspects of the resource's access requirements, except for fine-grained validation such as asserting that the identity of the user who has delegated access rights to the client corresponds to the call being made.

This allows the protected resource to only check the scope and, if necessary, assert the expected resource owner/user identity before allowing access based on an access token (see Section 4.4, Protected Resource Access Requirements Modelling).

4. Protected Resource Profile

An OAuth 2.0 resource server hosting a protected resource grants access to clients if they present a valid access token with the appropriate scope. The resource server trusts an authorization server to authenticate users and, optionally, obtain their consent before issuing an access token to a client. This section outlines the interoperability and security requirements for OAuth 2.0 protected resources and resource servers.

A resource server compliant with this profile MUST accept access tokens passed in the Authorization header as a bearer token, as specified in Section 2.1 of [RFC6750], and access tokens passed as form-encoded content parameters, as specified in Section 2.2 of [RFC6750].

Resource servers MUST NOT accept access tokens passed in a URI query parameter (Section 2.3 of [RFC6750]).

Depending on how a resource server services a request, it MAY also act as an OAuth 2.0 client when it needs to invoke underlying protected resources as part of its processing. This pattern may involve features such as "token exchange", which is not covered in this profile.

4.1. Validation of Access Tokens

This profile specifies access tokens only in the form of JWT bearer tokens. This section outlines the requirements for resource servers to validate such access tokens.

Note: This section does not specify any requirements regarding "Token introspection", [RFC7662], as it is out of scope for this profile.

Resource servers compliant with this profile MUST validate JWT access tokens as specified in Section 4 of [RFC9068] and Section 3 of [RFC8725], with the following modifications and clarifications:

4.2. Resource Server Error Responses

If a request to the resource server fails or is rejected, the resource server MUST inform the client of the error as specified in Section 3 of [RFC6750].

A typical example might look like this:

HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer realm="example",
                  error="invalid_token",
                  error_description="The access token has expired"

To ensure interoperability, a resource server compliant with this profile SHOULD NOT use any error codes other than those specified in Section 3.1 of [RFC6750].

If an access token is rejected due to insufficient scope(s), it is RECOMMENDED to include the scope attribute in the WWW-Authenticate header of the error response. This attribute MUST specify the required scope(s) for accessing the protected resource.

Example:

HTTP/1.1 403 Forbidden
WWW-Authenticate: Bearer realm="example",
                  scope="read write"
                  error="insufficient_scope",
                  error_description="Scopes 'read' or 'write' are required"

4.3. Protected Resource Identity and Registration

A protected resource compliant with this profile MUST have a Resource Identifier assigned. This identifier MUST be a URL using the HTTPS schema and including a host component. It SHOULD NOT include a query component, and MUST NOT include a fragment component.

If the protected resource is functioning in a multi-domain, or federative, context, its identifier MUST be globally unique.

A protected resource MAY support publication of its metadata according to "OAuth 2.0 Protected Resource Metadata", [RFC9728].

Whenever feasible, the resource identifier SHOULD correspond to the network-addressable location of the protected resource, that is, the URL at which it exposes its service.

Furthermore, if a resource server hosts multiple resources that do not share the same access rules, it is RECOMMENDED that these resources be treated as separate protected resources, and thus be represented with their own resource identifiers.

Example:

Assume there are two different servers, server1 and server2, as shown in the illustration below.

Resource Servers

The endpoints on server1 do not share the same access rules and should therefore be treated as two separate protected resources: https://server1.example.com/api and https://server1.example.com/admin. In contrast, the endpoints exposed by server2 have the same access rules and can therefore be represented by a single protected resource: https://server2.example.com.

Note: In the example below, access rules are illustrated solely through scope requirements. In a real-world scenario, additional rules—such as requiring a specific level of end-user authentication—may also apply.

4.4. Protected Resource Access Requirements Modelling

This section lists requirements and recommendations for a protected resource modelling its access requirements.

After validating an access token according to Section 4.1, a protected resource generally asserts that the scope(s) in the access token meet the requirements for the specific endpoint being invoked, and possibly that the identity of the resource owner (the sub claim or possibly another identity claim) who has delegated access to the client corresponds to the call being made*, before granting access to the endpoint.

A protected resource SHOULD NOT model its access control rules to include checks such as requirements for specific user authentication methods or requirements for specific clients. These types of assertions SHOULD be performed by the authorization server based on its configuration for the given resource (see Section 3.4, Configuration of Protected Resources).

[*]: Suppose that the endpoint being invoked is /api/user123, where the end of the path indicates the user whose data is being accessed. In such cases, the protected resource will likely want to assert that the sub claim, or possibly another identity claim, from the access token corresponds to user123, that is, to verify that the resource owner who has delegated access rights to the client matches the expected user based on the call.

5. Grant Types

This section outlines the requirements for the grant types covered by this profile.

It is RECOMMENDED that authorization servers support the resource parameter, as defined in [RFC8707], for all grant types. Entities compliant with this profile and supporting the resource parameter MUST adhere to the requirements specified in Section 7.1, The Resource Parameter.

5.1. Authorization Code Grant

Entities compliant with this profile that support or use the authorization code grant MUST adhere to the requirements in Section 4.1 (and its subsections) of [RFC6749], along with the additions and clarifications provided below.

5.1.1. Authorization Requests

A client compliant with this profile MUST construct the authorization request URI according to the parameter requirements specified below.

Additional parameters MAY be included.

Note: If the request is made according to "JWT-Secured Authorization Request (JAR)", [RFC9101], or "OAuth 2.0 Pushed Authorization Requests", [RFC9126], the requirements for the format of the request differ from what is stated above. See Section 7.2, JAR - JWT-Secured Authorization Requests and Section 7.3, PAR - OAuth 2.0 Pushed Authorization Requests.

An example of an HTTP GET request representing an OAuth 2.0 authorization request (with extra line breaks for display purposes):

GET /authorize?
  response_type=code&
  client_id=https%3A%2F%2Fclient.example.com&
  redirect_uri=https%3A%2F%2Fclient.example.com%2Fcallback&
  code_challenge=0x7Yt0nFnvGp4Af3GtrR7H8yWVD3ysKvl9P8z9vbYhME&
  code_challenge_method=S256&
  state=Z3k8MvB9QJzEr7a6X2Wa&
  scope=https%3A%2F%2Fservice.example.com%2Fread%20https%3A%2F%2Fservice.example.com%2Fwrite
HTTP/1.1
Host: as.example.com

The client, https://client.example.com, requests the scopes https://service.example.com/read and https://service.example.com/write by redirecting the user agent to the authorization server's authorize endpoint.

An authorization server compliant with this profile MUST validate all authorization request messages to ensure that the required parameters, as listed in this section, are present and valid.

The authorization server MUST reject the request if no redirect_uri is provided and the client has multiple redirect URIs registered.

If the redirect_uri parameter is present in the request, the authorization server MUST ensure that it matches one of the URIs registered by the client (see Section 2.2.2.1, Redirect URIs). The URI comparison to determine equality MUST be performed according to Section 6.2.1 of [RFC3986].

The authorization server MUST NOT accept any request that omits the code_challenge parameter.

If the request includes the resource parameter, and the authorization server supports this parameter, it MUST process this parameter as specified in Section 7.1, The Resource Parameter.

5.1.1.1. Extension Parameter for Controlling User Authentication at the Authorization Server

A common scenario when using OAuth 2.0 is that an application (the client) has already logged in the user before directing them to the authorization server as part of an authorization request. Since the user also needs to be authenticated at the authorization server, this can result in a suboptimal user experience, where the user is prompted to authenticate multiple times.

If both the application (client) and the authorization server use the same external authentication service, such as a SAML Identity Provider or an OpenID Connect Provider, this issue can be addressed using single sign-on (SSO). If the user already has an active session with the authentication service, the authorization server can take advantage of that session when requesting user authentication from the same service.

This feature can significantly improve the user experience at the authorization server. However, if both the application and the authorization server support multiple authentication methods (or services), there must be a mechanism for the OAuth 2.0 client to indicate which authentication method (or service) should be used when (re-)authenticating the user.

However, there is no standard OAuth 2.0 parameter for this purpose, and different solutions and products use proprietary extensions to address the problem described above. Section 2.2 of the Authentication Request Parameter Extensions for the Swedish OpenID Connect Profile specification, [OIDC.Sweden.Parameters], defines the request parameter https://id.oidc.se/param/authnProvider to handle this issue.

For authorization servers that support multiple user authentication methods, it is RECOMMENDED to support this parameter. Authorization servers that do support the parameter MUST indicate this in their metadata using the metadata parameter https://id.oidc.se/disco/authnProviderSupported. See Section 3.1.1.10.

5.1.2. Authorization Responses

Entities compliant with this profile MUST adhere to Section 4.1.2 of [RFC6749], with the following additions and clarifications:

Example of an authorization response message (line breaks added for readability):

HTTP/1.1 302 Found
Location: https://client.example.com/callback?
  code=SplxlOBeZQQYbYS6WxSbIA&
  state=Z3k8MvB9QJzEr7a6X2Wa&
  iss=https%3A%2F%2Fas.example.com

An example of an error response:

HTTP/1.1 302 Found
Location: https://client.example.com/callback?
  error=access_denied&
  error_description=User%20did%20not%20consent&
  state=Z3k8MvB9QJzEr7a6X2Wa&
  iss=https%3A%2F%2Fas.example.com

5.1.3. Access Token Requests and Responses

For requesting and providing an access token using the authorization code grant, entities compliant with this profile MUST adhere to Section 4.1.3 of [RFC6749] with the following additions and clarifications:

Example of an access token request message (line breaks added for readability):

POST /token HTTP/1.1
Host: as.example.com
Content-Type: application/x-www-form-urlencoded

grant_type=authorization_code&
code=SplxlOBeZQQYbYS6WxSbIA&
redirect_uri=https%3A%2F%2Fclient.example.com%2Fcallback&
client_id=https%3A%2F%2Fclient.example.com&
client_assertion_type=urn%3Aietf%3Aparams%3Aoauth%3Aclient-assertion-type%3Ajwt-bearer&
client_assertion=eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJodHRwczovL2NsaWVudC5leGFtcGxlL \
  mNvbSIsInN1YiI6Imh0dHBzOi8vY2xpZW50LmV4YW1wbGUuY29tIiwiYXVkIjoiaHR0cHM6Ly9hcy5leGFtcGxlLmNvbSIsI \
  mV4cCI6MTY4MDAwMDAwMCwiaWF0IjoxNjgwMDAwMDAwLCJqdGkiOiJxa2x3ZWZka2pmcWx1cm1jdHZuZXZ5bXhwIn0.RGViX \
  2V4YW1wbGVTaWduYXR1cmVIZXJl&
code_verifier=bj3nhdD9fX1JVuTWBEtPZsG5dNxMCuKzLFFbItgQafM

If the access token request is valid and authorized, the authorization server issues an access token, possibly also a refresh token, and sends a response message as specified in Section 3.3.2.2, Token Responses. Requirements for access tokens and refresh tokens are given in Section 6.1, Access Tokens and Section 6.2, Refresh Tokens, respectively.

If the access token request is rejected or invalid, the authorization server MUST send an error response as specified in Section 3.3.2.3, Error Responses.

5.2. Refresh Token Grant

Entities compliant with this profile MUST adhere to Section 6 of [RFC6749] with the following additions and clarifications:

The response message for a token request using the refresh_token grant type MUST adhere to the requirements stated in Section 3.3.2.2, Token Responses with the following additions:

If the token request is rejected or invalid, the authorization server MUST send an error response as specified in Section 3.3.2.3, Error Responses.

Note: See additional requirements for refresh tokens in Section 6.2.

5.3. Client Credentials Grant

The client_credentials grant MAY be supported by authorization servers compliant with this profile.

To request and issue an access token using the client_credentials grant, entities compliant with this profile MUST adhere to Section 4.4 of [RFC6749] with the following additions and clarifications:

Example of an access token request message using the client_credentials grant (line breaks added for readability):

POST /token HTTP/1.1
Host: as.example.com
Content-Type: application/x-www-form-urlencoded

grant_type=client_credentials&
client_id=https%3A%2F%2Fclient.example.com&
scope=https%3A%2F%2Fservice.example.com%2Fread&
resource=https%3A%2F%2Fservice.example.com&
client_assertion_type=urn%3Aietf%3Aparams%3Aoauth%3Aclient-assertion-type%3Ajwt-bearer&
client_assertion=eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJodHRwczovL2NsaWVudC5le \
  GFtcGxlLmNvbSIsInN1YiI6Imh0dHBzOi8vY2xpZW50LmV4YW1wbGUuY29tIiwiYXVkIjoiaHR0cHM6Ly9hcy \
  5leGFtcGxlLmNvbS90b2tlbiIsImV4cCI6MTcxNjA4ODAwMCwianRpIjoiYTkzODdlZTgtMzQ0Zi00YjM1LTg \
  zNTUtMzI0NzdkNjFiNmM4In0.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

The response message for a token request using the client_credentials grant type MUST adhere to the requirements stated in Section 3.3.2.2, Token Responses, with the following addition:

If the token request is rejected or invalid, the authorization server MUST send an error response as specified in Section 3.3.2.3, Error Responses.

5.4. Other Grant Types

Entities compliant with this profile MAY use extension grants not profiled in this document. However, when doing so, the requirements of this profile MUST still be fulfilled.

The subsections below provide profiling for some extension grants that MAY be used by entities compliant with this profile.

5.4.1. SAML Assertion Authorization Grants

Using SAML assertions as authorization grants, as specified in [RFC7522], MAY be used by entities compliant with this profile. However, if possible, it is RECOMMENDED to use the more standardized authorization code grant — possibly using the extension parameter as specified in Section 5.1.1.1.

If the urn:ietf:params:oauth:grant-type:saml2-bearer grant is used, the requirements specified in [RFC7522], along with the additions and clarifications below, MUST be fulfilled.

Example of an access token request message using the urn:ietf:params:oauth:grant-type:saml2-bearer grant (line breaks added for readability):

POST /token  
Host: as.example.com  
Content-Type: application/x-www-form-urlencoded

grant_type=urn:ietf:params:oauth:grant-type:saml2-bearer&
scope=https%3A%2F%2Fservice.example.com%2Fread&
assertion=PHNhbWxwOl...[Base64-encoded SAML2 Assertion]...ZT4%3D&
client_id=https%3A%2F%2Fclient.example.com&
client_assertion_type=urn:ietf:params:oauth:client-assertion-type:jwt-bearer&
client_assertion=eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJodHRwczovL2NsaWVu \
  dC5leGFtcGxlLmNvbSIsInN1YiI6Imh0dHBzOi8vY2xpZW50LmV4YW1wbGUuY29tIiwiYXVkIjoiaHR0 \
  cHM6Ly9hcy5leGFtcGxlLmNvbS90b2tlbiIsImV4cCI6MTcwMDAwMDAwMCwiaWF0IjoxNzAwMDAwMDAw \
  LCJqdGkiOiJ1bmlxdWUtaWQtMTIzIn0.MEUCIQDf3ddNZW7U9bMo6vHzgHtU0LR3EnuC2UOqGVoYZ7Br \
  pgIgHYo9ZehyPKkhyRUL7zUvQeap3id9mM7zvBaGXjaeXkY

5.4.2. JWT Authorization Grants

Entities compliant with this profile MAY use JWT authorization grants, as specified in [RFC7523], for specific use cases such as cross-domain scenarios where a JWT can be used as an authorization grant to obtain an access token from a different authorization server, see [OAuth.ID-Chaining].

This profile does not define specific requirements for the various use cases in which JWT authorization grants may be used, but the base requirements stated below MUST be adhered to by entities compliant with this profile.

The requirements from Section 2.1 and 3.1 of [RFC7523] MUST be fulfilled, with the following additions and clarifications:

The response message for a token request using the urn:ietf:params:oauth:grant-type:jwt-bearer grant type MUST adhere to the requirements stated in Section 3.3.2.2, Token Responses.

If the request is rejected or invalid, the authorization server MUST send an error response as specified in Section 3.3.2.3, Error Responses.

5.5. Prohibited Grant Types

This following grant types MUST NOT be used or supported by entities compliant with this profile:

6. Tokens

6.1. Access Tokens

This section specifies requirements for JWT access tokens that MUST be adhered to by entities compliant with this profile.

An authorization server compliant with this profile MUST issue JWT access tokens according to the requirements specified in Sections 2.1 and 2.2 of [RFC9068] with the following additions and clarifications:

Also see Section 4.1 for requirements regarding validation of JWT access tokens.

Example JWT access token:

Header:

{
  "alg": "RS256",
  "kid": "key-1",
  "typ": "at+jwt"
}

Payload:

{
  "iss": "https://as.example.com",
  "sub": "user123",
  "aud": "https://api.example.com",
  "exp": 1759158000,
  "iat": 1759154400,
  "scope": "read write",
  "client_id": "https://client.example.com",
  "jti": "a1b2c3d4e5f6"
}

Compact JWT representation:

eyJhbGciOiJSUzI1NiIsImtpZCI6ImtleS0xIiwidHlwIjoiYXQrand0In0.eyJpc3MiOiJodHRwczovL2FzLm \
V4YW1wbGUuY29tIiwic3ViIjoidXNlcjEyMyIsImF1ZCI6Imh0dHBzOi8vYXBpLmV4YW1wbGUuY29tIiwiZXhw \
IjoxNzU5MTU4MDAwLCJpYXQiOjE3NTkxNTQ0MDAsInNjb3BlIjoicmVhZCB3cml0ZSIsImNsaWVudF9pZCI6Im \
h0dHBzOi8vY2xpZW50LmV4YW1wbGUuY29tIiwianRpIjoiYTFiMmMzZDRlNWY2In0.qce3-7_VNXBongen4_ge \
5xsFSDCuJBY0VQoxlr3WXopKxhjx7RFIaBJkO5QuK5fUAO_C6bpaIByvEp099JAMERhVqan8ej4DIwp4W2VxRG \
R4aXHtqr7YS0AjGDKyMwlM7KAmXe4sppv4Rv3EOnoKGvmmfugNPk2Mv8gL8rBGrTjgo5DjOfVo8vdg4rGMm15F \
6JDXb1tVzSyMZuY-sHMIwoUvfsQ-8JjhFm2w_97sT4ZX6P5E9rrFfVW0y29ysLljJGsczqWDbctecP5NQl2tuJ \
_z5EsOGpKG1I9LEksRch0bxCKXbOUUOFREBuxX9NUjqBenUeP91J2TDMDEQ6EHxQ

Extended example of the payload where the authorization server includes authentication information (the authentication context class and user authentication time), and a Swedish personal identity number for the subject (user):

{
  "iss": "https://as.example.com",
  "sub": "user123",
  "aud": "https://api.example.com",
  "exp": 1759158000,
  "iat": 1759154400,
  "scope": "read write",
  "client_id": "https://client.example.com",
  "jti": "a1b2c3d4e5f6"
  "auth_time": "1759154340",
  "acr": "http://id.elegnamnden.se/loa/1.0/loa3",
  "https://id.oidc.se/claim/personalIdentityNumber": "198509276112" 
}

6.1.1. The Audience Claim

The aud (audience) claim is essential for limiting an access token's use to one, or possibly a set of, protected resource(s).

In order to avoid leaking potentially sensible information an authorization server MUST restrict the number of audiences for an access token to a minimum.

For each protected resource for which the access token is intended, the authorization server MUST include the resource identifier for this resource among the audience values, see Section 4.3, Protected Resource Identity and Registration.

In order to support legacy deployments, an authorization server MAY include alternative representations of a protected resource as audience values.

If several audience values are given in the aud claim, all protected resources indicated MUST share the same access configuration at the authorization server, meaning they have the same requirements for access based on scopes and possibly other claims included in the access token.

6.1.2. The Subject Claim

In cases where an access token is obtained through a grant where no user is involved, such as the Client Credentials Grant, the sub claim SHOULD be assigned the same value as the client_id. This requirement MAY be overridden if the protected resource has a different way to identify a client application than its registered identity.

An access token obtained through a grant where no user is involved MUST NOT assign the sub claim to the identity of a physical individual. However, if a resource owner (user) has authorized an application in advance, the access token MAY include identity claims for that user. How this is accomplished is out of scope for this profile.

In cases where access tokens are obtained through grants involving a resource owner/user, such as the Authorization Code Grant, the sub claim MUST be assigned an identifier that represents the resource owner/user.

An authorization server MUST ensure that the protected resource(s) receiving the access token are authorized to receive the identity information contained in the sub claim. For example, if a protected resource is not authorized to receive a user's Swedish personal identity number, that identity MUST NOT be used as the sub claim.

For user integrity reasons, it is RECOMMENDED that authorization servers choose a persistent identifier that does not reveal any personal identity information about the user as the sub value, and extend the access token with authorized identity claims for the user (if needed).

6.2. Refresh Tokens

An authorization server MUST NOT issue a refresh token if no end user is involved (for example, when using the client_credentials grant).

If the user does not have a direct relationship with the authorization server (for example, when using the urn:ietf:params:oauth:grant-type:saml2-bearer grant type), the authorization server MAY issue refresh tokens, provided that there is an established relationship between the client and the authorization server concerning user authentication policies. How this relationship is managed is out of scope for this profile.

If refresh tokens are represented as JWTs, these JWTs MUST always be signed by the authorization server.

It is RECOMMENDED that the authorization server encrypt refresh token JWTs using its own public key. This is to prevent exposing internal authorization server handling.

An authorization server SHOULD invalidate the previous refresh token when issuing a new one to the client. Allowing multiple active refresh tokens for the same client and session increases the risk of attacks using the refresh_token grant.

If the end user's session is no longer valid at the authorization server, i.e., the session has timed out or the user has logged out, all refresh tokens for that user MUST be revoked (invalidated).

All refresh tokens MUST have an expiration time that makes them invalid if the client has not been active, i.e., has not used the refresh token, within that time. The expiration time is determined by local policy but SHOULD be kept as short as feasible.

7. Optional Extensions

This section provides profiles of OAuth 2.0 extensions that may be used by entities compliant with this profile.

7.1. The Resource Parameter

“Resource Indicators for OAuth 2.0”, [RFC8707], defines the OAuth 2.0 resource parameter. Its purpose is to allow an OAuth 2.0 client to indicate the protected resource, or resources, it intends to access. This becomes particularly important when an authorization server protects multiple resources.

Section 9.1, Defining and Using Scopes recommends that scopes be defined in a non-generic manner, bound to a single protected resource or to a function shared across multiple resources with a common access model. However, this approach may not always be feasible. Moreover, even when non-generic scopes are used, it may still be necessary to specify which resource the client intends to access.

Therefore, for authorization servers and clients compliant with this profile, it is RECOMMENDED to support and use the resource parameter.

Entities compliant with this profile that support the resource parameter MUST adhere to the requirements stated in [RFC8707], with the following additions and clarifications:

[*]: By "access token request", we refer to a token request using the authorization_code or refresh_token grant type.

7.2. JAR – JWT-Secured Authorization Requests

[RFC9101] defines a method for securing OAuth 2.0 authorization requests by encapsulating them in a JSON Web Token (JWT). This approach is known as the JWT-Secured Authorization Request (JAR).

In the traditional OAuth 2.0 authorization request, parameters such as client_id, redirect_uri, scope, and state are passed as query parameters in the URL. This can expose sensitive information, make requests tamperable, and limit request size. JAR addresses these issues by allowing the authorization request to be passed as a signed and optionally encrypted JWT.

The request and request_uri parameters were defined in [OpenID.Core], and [RFC9101] generalizes this concept for OAuth 2.0. It defines how any OAuth client can use a JWT to encapsulate authorization request parameters, using the same request and request_uri parameters introduced by OpenID Connect.

Support for [RFC9101] by an authorization server compliant with this profile is OPTIONAL. However, an authorization server that also functions as an OpenID Provider SHOULD support the use of at least the request parameter for OAuth 2.0 authorization requests.

It is RECOMMENDED that high-security deployments with requirements for request integrity and authenticity make use of [RFC9101], or Pushed Authorization Requests as described in the section below.

7.3. PAR – OAuth 2.0 Pushed Authorization Requests

Pushed Authorization Requests (PAR), defined in [RFC9126], introduce a mechanism for OAuth 2.0 clients to push the authorization request parameters directly to the authorization server via a secure, direct HTTPS request. Instead of including all parameters in the front-channel (i.e., via the browser redirect), the client sends them to the server's PAR endpoint and receives a request_uri. This URI is then used in the subsequent authorization request.

This decouples the transmission of sensitive request parameters from the browser, reducing exposure and improving integrity and confidentiality. Some of the benefits are:

It is RECOMMENDED that high-security deployments with requirements for request integrity and authenticity make use of Pushed Authorization Requests (PAR), or JAR ([RFC9101]) as described in the previous section.

8. Security Requirements and Considerations

8.1. General Security Requirements

All transactions MUST be protected in transit by TLS as described in [NIST.800-52.Rev2].

A party acting as a client in a TLS handshake MUST successfully validate the TLS certificate chain up to a trusted root before proceeding with the transaction.

All parties compliant with this profile MUST conform to applicable recommendations in Section 16, "Security Considerations" of [RFC6749] and those found in "Best Current Practice for OAuth 2.0 Security", [RFC9700].

8.2. Cryptographic Algorithms

This section lists the requirements for cryptographic algorithm support for being compliant with
this profile.

All entities compliant with this profile MUST follow the guidelines in [NIST.800-131A.Rev2] regarding use of algorithms and key lengths. Specifically, for signature and encryption keys the following requirements apply:

Entities conforming to this profile MUST support algorithms according to "JSON Web Algorithms (JWA)",
[RFC7518], with the following additions:

Furthermore, it is RECOMMENDED that an authorization server compliant with this profile supports the following algorithms that are listed as optional in [RFC7518]:

The sender of a secure message MUST NOT use an algorithm that is not set as REQUIRED in [RFC7518] or in the listing above, unless it is explicitly declared by the peer in its metadata or registration data.

Note: [NIST.800-131A.Rev2] contains a listing of algorithms that must not be used. However, there is a need to explicitly point out that the commonly used algorithm SHA-1 for digests is considered broken and MUST NOT be used or accepted.

8.3. Client Authentication

Authorization servers compliant with this profile MUST support the private_key_jwt client authentication mechanism, as specified in Section 8.3.1 below, and MAY support mutual TLS client authentication, as specified in Section 8.3.2. Other client authentication mechanisms MUST NOT be accepted.

8.3.1. Signed JWT for Client Authentication

The private_key_jwt mechanism is defined in Sections 2 and 3 of [RFC7523]. Entities compliant with this profile MUST adhere to these sections, with the following additions and clarifications:

Example of a signed JWT used by https://client.example.com to authenticate to the authorization server https://as.example.com:

Header:

{
  "alg": "RS256",
  "typ": "client-authentication+jwt",
  "kid": "key-12345"
}

Payload:

{
  "iss": "https://client.example.com",
  "sub": "https://client.example.com",
  "aud": "https://as.example.com",
  "exp": 1759654860,
  "nbf": 1759654800,
  "iat": 1759654800,
  "jti": "e3d1f2b4-6ac0-4d84-b9f2-7e8e028b1234"
}

See Section 3.3.2.1, Token Requests for an example where private_key_jwt is used to authenticate a client's request to the authorization server's token endpoint.

8.3.2. Mutual TLS for Client Authentication

[RFC8705] defines the tls_client_auth and self_signed_tls_client_auth client authentication methods. Entities compliant with this profile MAY support these methods according to [RFC8705], along with the clarifications and additions stated below:

Authorization servers supporting the tls_client_auth method SHOULD limit the accepted PKI trust to a single root CA certificate, i.e., only accept client certificates from one PKI. The reason for this is that if the authorization server accepts a large number of certificate issuers, an attacker's chances of obtaining a perfectly legitimate certificate that has the same subject DN (or any other certificate subject name) for an already registered client increases. See Section 2.1.2 of [RFC8705].

Since an authorization server compliant with this profile MUST support the private_key_jwt client authentication method (see Section 8.3.1 above), the use of mTLS endpoint aliases as specified in Section 5 of [RFC8705] is RECOMMENDED. This facilitates a more robust endpoint configuration at the authorization server and avoids having to configure web servers with complex TLS rules where mTLS is optional, since private_key_jwt does not require mTLS.

Example of authorization server metadata:

{
  "issuer": "https://as.example.com",
  "authorization_endpoint": "https://as.example.com/authz",
  "token_endpoint": "https://as.example.com/token",
  ...
  "token_endpoint_auth_methods_supported": ["private_key_jwt", "tls_client_auth"],
  "mtls_endpoint_aliases": {
    "token_endpoint": "https://as-mtls.example.com/token"
  }
}

This illustrates that the authorization server has two token endpoints: one used for private_key_jwt authentication, and one configured for mutual TLS, used for the tls_client_auth method.

Note: Since an OAuth 2.0 client can only register one client authentication method (see Section 2.2.2.2, Token Endpoint Authentication Method), an authorization server MAY, instead of using mTLS endpoint aliases, supply different metadata documents to clients based on their registered authentication methods. How this could be implemented and realized is out of scope for this profile.

8.4. OAuth 2.0 Security Mechanisms

8.4.1. PKCE – Proof Key for Code Exchange

Proof Key for Code Exchange (PKCE) is defined in [RFC7636]. It was originally designed to protect native applications from authorization code exfiltration attacks, but it is also used as a countermeasure against "Authorization Code Injection" attacks (see Section 8.5.1, below) and Cross-Site Request Forgery (CSRF) (see Section 4.7 of [RFC9700]).

The use of PKCE with the authorization code grant is REQUIRED by this profile.

A client constructing an authorization request MUST include the code_challenge and code_challenge_method parameters. The code_challenge_method MUST be one of the methods listed in the authorization server’s metadata document; see Section 3.1.1.8, Supported Code Challenge Methods. The use of the plain method MUST NOT be permitted.

The code_verifier MUST be generated by the client according to Section 4.1 of [RFC7636], and the code_challenge MUST be derived from this value. If the S256 method is used, the transformation MUST follow Section 4.2 of [RFC7636].

The client MUST securely store the code_verifier. It MUST NOT be stored in a cookie or in any manner accessible from the user agent.

An authorization server receiving an authorization request that does not include a code_challenge parameter MUST reject the request.

An authorization server that successfully processes an authorization request and issues an authorization code MUST associate the corresponding code_challenge and code_challenge_method with the issued code for later verification; see Section 4.4 of [RFC7636]. These values MUST be stored securely.

When constructing the access token request, the client MUST include the code_verifier parameter containing the previously generated value.

An authorization server receiving a token request where grant_type is authorization_code MUST require the presence of the code_verifier parameter. If it is missing, the request MUST be rejected.

Finally, an authorization server receiving an access token request MUST verify the supplied code_verifier according to Section 4.6 of [RFC7636].

8.4.2. DPoP – Demonstrating Proof of Possession

For deployments that make use of the DPoP (Demonstrating Proof of Possession) mechanism as specified in [RFC9449], this profile introduces the following clarifications and additions:

An authorization server SHOULD maintain configuration for each protected resource it serves, containing the following information:

An authorization server receiving a token request for an access token—where the audience of the token is a resource that requires DPoP—MUST ensure that the request includes a valid DPoP proof. If not, the request MUST be rejected.

For protected resources that support [RFC9728], the parameters dpop_bound_access_tokens_required and dpop_signing_alg_values_supported MUST be used accordingly.

How a client determines whether a protected resource that does not expose its metadata according to [RFC9728] supports DPoP-bound access tokens is out of scope for this profile.

An authorization server that supports the DPoP mechanism MUST include the dpop_signing_alg_values_supported parameter in its metadata document. See Section 5.1 of [RFC9449].

A client that always uses DPoP for token requests MUST register or announce the dpop_bound_access_tokens parameter and set its value to true. See Section 5.2 of [RFC9449].

There is no metadata parameter that indicates a client supports DPoP (without necessarily using it for all requests). Therefore, an authorization server that supports DPoP MUST be prepared to receive DPoP headers from any of its registered clients.

A protected resource that allows reuse of an access token for several calls MUST still require a new DPoP proof for every request. See Sections 7.3 and 11.1 of [RFC9449].

8.4.3. Binding Access Tokens to Client Certificates using Mutual TLS

For deployments that make use of the "Mutual-TLS Client Certificate-Bound Access Token" mechanism as specified in Section 3 of [RFC8705], this profile introduces the following clarifications and additions:

If the authorization server supports mutual TLS client certificate-bound access tokens, it MUST include the tls_client_certificate_bound_access_tokens parameter in its metadata document with the value set to true. See Section 3.3 of [RFC8705].

An authorization server SHOULD maintain a configuration for each protected resource it serves, indicating whether mutual TLS client certificate-bound tokens are required, optional, or not supported by that resource.

An authorization server receiving a token request for an access token—where the audience of the token is a resource that requires mutual TLS—MUST ensure that the request is made over a mutual TLS connection. Otherwise, the request MUST be rejected.

A client that requests mutual TLS certificate-bound access tokens MUST indicate this by setting the tls_client_certificate_bound_access_tokens client metadata parameter to true, or by supplying equivalent information during client registration with the authorization server. See Section 3.4 of [RFC8705].

If a client that has indicated the intention to use mutual TLS client certificate-bound tokens makes a request to the token endpoint over a non-mutual TLS connection, the authorization server MUST treat this as a valid request and issue an unbound token (assuming the request is otherwise correct). This requirement exists because a client may interact with multiple protected resources, some of which require mutual TLS while others do not.

For protected resources that support mutual TLS client certificate-bound tokens and also support [RFC9728], the tls_client_certificate_bound_access_tokens parameter MUST be included and set to true. This does not imply that mutual TLS is required in all cases. How such a requirement is advertised is out of scope for this profile.

How a client determines whether a protected resource that does not expose its metadata according to [RFC9728] supports mutual TLS client certificate-bound tokens is also out of scope for this profile.

8.5. Threats and Countermeasures

Entities compliant with this profile MUST be aware of and implement countermeasures against relevant threats described in "OAuth 2.0 Security Best Current Practice" [RFC9700]. This section highlights a selection of those threats that warrant particular attention due to the security requirements defined in this profile.

Furthermore, this section does not explicitly discuss threats and vulnerabilities for OAuth 2.0 entities that arise from poor or uninformed implementations and deployments. [RFC9700] provides a few examples, such as the use of the 307 HTTP status code (instead of 303) for redirects, or a poorly configured reverse proxy that allows an attacker to supply header values that are normally created by the proxy.

It is expected that implementors and deployment engineers wishing to adhere to this profile not only study and follow [RFC9700], but also read, understand, and follow:

8.5.1. Injection of Authorization Code

Section 4.5 of [RFC9700] describes the Authorization Code Injection attack, in which an attacker attempts to inject a stolen authorization code into their own session at the client. The goal is to link the attacker’s session with the legitimate user’s (i.e., the victim’s) resources or identity, thereby gaining unauthorized access to the victim’s data.

The countermeasure against this attack is to always require PKCE. See Section 8.4.1, PKCE - Proof Key for Code Exchange. This involves using the code_challenge parameter in authorization requests and the corresponding code_verifier parameter in token requests.

Note: This threat and its countermeasure apply only when the authorization code grant is used.

8.5.2. Token Theft and Leakage

Access tokens can be stolen in several ways. Some of these attacks are described in [RFC9700], including in Sections 4.1, 4.2, 4.3, 4.4, and 4.9. Access tokens may also be leaked at the resource server (see Section 4.9).

To mitigate these types of attacks, this profile specifies the following requirements:

Note: This profile is intended for general-purpose use and therefore does not mandate sender-constrained access tokens. However, profiles targeting high-security deployments that build upon this profile may choose to require sender-constrained tokens as a mandatory feature.

8.5.3. Authorization Server Mix-Up Attacks

If an OAuth 2.0 client is configured to use more than one authorization server, the client may be at risk if any of the authorization servers it interacts with has been compromised by an attacker.

Section 4.4.1 of [RFC9700] describes this attack in detail, but in short, the attacker exploits a situation where a client interacts with multiple authorization servers and does not properly verify which authorization server issued a given authorization response. The attack may proceed as follows:

To defend against these types of attacks, a client compliant with this profile MUST, for each authorization request, store the identifier of the authorization server to which the request was sent, and bind this information to the user agent. Using the authorization server metadata, the client can then determine which authorization endpoint and token endpoint are to be used in the flow.

Also, an authorization server compliant with this profile SHOULD include the iss parameter, as defined by [RFC9207], in authorization responses, and the client SHOULD process it according to [RFC9207], see Section 5.1.2, Authorization Responses.

8.5.4. Insufficient Validation of Redirect URIs

Section 4.1 of [RFC9700] describes attacks concerning the misuse of a client's redirect URIs. To mitigate any of the threats described therein, an authorization server MUST NOT allow a client to register redirect URI patterns (i.e., use wildcards in the URI).

See also Section 2.2.2.1, Redirect URIs.

8.5.5. Open Redirects

An open redirector is a web application vulnerability where a URL parameter is used to redirect users to another website, but the destination is not properly validated. This allows attackers to craft URLs that appear to lead to a trusted site but actually redirect users to malicious sites. Open redirectors are often used in phishing attacks to trick users into revealing credentials or downloading malware, leveraging the credibility of the original domain to bypass suspicion.

OAuth 2.0-related open redirector attacks are described in Section 4.11 of [RFC9700]. To prevent an authorization server from being used as an open redirector, authorization servers compliant with this profile MUST adhere to the countermeasures given in Section 4.11.2 of [RFC9700].

Client implementations are expected to follow the countermeasures against open redirects as described in [OWASP.Redirect].

9. Requirements for Interoperability

9.1. Defining and Using Scopes

An OAuth 2.0 scope is a mechanism for defining and limiting access to protected resources. It tells the authorization server what level of access the client is requesting, and tells the resource server what access the client has been granted.

In the early days of OAuth 2.0, a typical deployment involved a single authorization server configured to protect a single protected resource. In such cases, when a client requested an access token for a given scope, it was clear to the authorization server which protected resource was being referred to and how to apply its processing logic. Scopes such as read and write were commonly used and worked well in this context. Their meaning was unambiguous, since the authorization server was configured to protect only one resource.

However, when an authorization server protects multiple resources, how can it determine which resource is being requested based solely on a requested scope?

If generic scopes such as read and write are used, the authorization server cannot deduce which protected resource the client is requesting access to. To address this limitation, there are two possible solutions:

It may be tempting to choose the first solution and require that all authorization requests include the resource parameter, but there are several issues with this approach that make it less desirable:

Therefore, this profile specifies the following recommendations and requirements:

An authorization server that either protects multiple protected resources or publishes its metadata in a federation (as defined in [OpenID.Federation]) SHOULD use scopes that are unique for a given purpose.

If the authorization server operates within a federation, a defined scope values MUST be unique within that federation.

A scope value MAY be defined to map to a set of protected resources, provided they support the same function and access policy. In such cases, the authorization server MAY accept a resource parameter to uniquely identify a specific protected resource, or it may issue an access token with multiple audiences (i.e., valid for all protected resources associated with that scope).

It is RECOMMENDED that scope values follow the format: a URL prefix followed by the access right.

It is RECOMMENDED that scope values unique to a single protected resource be constructed using the resource’s identifier followed by the specific access right.

Example:

Suppose the protected resource identified by https://server.example.com/api supports two distinct access rights: read and write.

The scopes https://server.example.com/api/read and https://server.example.com/api/write would then uniquely identify the read and write permissions for that protected resource.

An authorization server MAY choose to map a unique scope to a different scope value when including scopes in an access token. This can be useful, for example, when the protected resource is a legacy system with hardcoded scope definitions. Referring to the example above, if a client requests the https://server.example.com/api/read scope, the resulting JWT access token could instead contain the scope read.

However, if the protected resource implements “OAuth 2.0 Protected Resource Metadata”, [RFC9728], scope mapping in the authorization server SHOULD NOT be performed. In such cases, the scopes_supported parameter in the protected resource metadata would not align with the actual scopes used by clients, leading to inconsistency and potential interoperability issues.

9.2. Using OpenID Connect Identity Scopes

Scopes are used somewhat differently in OAuth 2.0 and OpenID Connect. In the OAuth world, a scope represents a "right", whereas in OpenID Connect, many scopes determine which information about an authenticated user is released.

In OAuth 2.0 deployments, access tokens obtained from an authorization server and passed to a protected resource may contain a set of identity claims about the resource owner/user. The inclusion of such claims may be required by the protected resource in order to perform its access decision. Which identity claims to include in an access token for a particular resource is generally determined by configuration at the authorization server.

By using OpenID Connect identity scopes, a client can dynamically request that a specific set of identity claims be included in the access token. For example, assume that a client wishes to obtain an access token to call a protected resource that requires a Swedish personal identity number to be included in the token. The client could then include the scope https://id.oidc.se/scope/naturalPersonNumber, as defined by [OIDC.Sweden.Claims], in the authorization request.

GET /authorize?
  response_type=code&
  client_id=https%3A%2F%2Fclient.example.com&
  redirect_uri=https%3A%2F%2Fclient.example.com%2Fcallback&
  code_challenge=0x7Yt0nFnvGp4Af3GtrR7H8yWVD3ysKvl9P8z9vbYhME&
  code_challenge_method=S256&
  state=Z3k8MvB9QJzEr7a6X2Wa&
  scope=read%20https%3A%2F%2id.oidc.se%2Fscope%2FnaturalPersonNumber
HTTP/1.1
Host: as.example.com

The read scope is requested along with the special-purpose https://id.oidc.se/scope/naturalPersonNumber scope.

The resulting JWT access token may then look something like this:

{
  "iss": "https://as.example.com",
  "sub": "user123",
  "aud": "https://api.example.com",
  "exp": 1759158000,
  "iat": 1759154400,
  "scope": "read https://id.oidc.se/scope/naturalPersonNumber",
  "client_id": "https://client.example.com",
  "jti": "a1b2c3d4e5f6"
  "https://id.oidc.se/claim/personalIdentityNumber": "198509276112" 
}

The https://id.oidc.se/claim/personalIdentityNumber claim is included in the access token since the client requested the https://id.oidc.se/scope/naturalPersonNumber. See Section 3.2 of [OIDC.Sweden.Claims] for a definition of this scope.

Note that the requirement stated in Section 6.1, Access Tokens, that a protected resource must be authorized to receive a specific identity claim, still applies.

The feature of supporting OpenID Connect scope values in OAuth 2.0 authorization requests is OPTIONAL to support. However, for authorization servers that also function as OpenID Providers and support the Swedish OpenID Connect Profile [OIDC.Sweden.Profile], support is RECOMMENDED.

10. References

10.1. Normative References


[RFC2119]

Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", March 1997.


[RFC3986]

Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005.


[RFC5646]

Phillips, A., Ed. and M. Davis, Ed., "Tags for Identifying Languages", BCP 47, RFC 5646, DOI 10.17487/RFC5646, September 2009.


[RFC6749]

Hardt, D., "The OAuth 2.0 Authorization Framework", RFC 6749, DOI 10.17487/RFC6749, October 2012.


[RFC6750]

Jones, M. and D. Hardt, "The OAuth 2.0 Authorization Framework: Bearer Token Usage", RFC 6750, DOI 10.17487/RFC6750, October 2012.


[RFC7518]

Jones, M., "JSON Web Algorithms (JWA)", May 2015.


[RFC7591]

Richer, J., Ed., Jones, M., Bradley, J., Machulak, M., and P. Hunt, "OAuth 2.0 Dynamic Client Registration Protocol", RFC 7591, DOI 10.17487/RFC7591, July 2015.


[RFC7516]

Jones, M., "JSON Web Encryption (JWE)", RFC 7516, DOI 10.17487/RFC7516, May 2015.


[RFC7517]

Jones, M., "JSON Web Key (JWK)", RFC 7517, DOI 10.17487/RFC7517, May 2015.


[RFC7519]

Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015.


[RFC7522]

Campbell, B., Mortimore, C., and M. Jones, "Security Assertion Markup Language (SAML) 2.0 Profile for OAuth 2.0 Client Authentication and Authorization Grants", RFC 7522, DOI 10.17487/RFC7522, May 2015.


[RFC7523]

Jones, M., Campbell, B., and C. Mortimore, "JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and Authorization Grants", RFC 7523, DOI 10.17487/RFC7523, May 2015.


[RFC7636]

Sakimura, N., Ed., Bradley, J., and N. Agarwal, "Proof Key for Code Exchange by OAuth Public Clients", RFC 7636, DOI 10.17487/RFC7636, September 2015.


[RFC8414]

Jones, M., Sakimura, N., and J. Bradley, "OAuth 2.0 Authorization Server Metadata", RFC 8414, DOI 10.17487/RFC8414, June 2018.


[RFC8615]

Nottingham, M., "Well-Known Uniform Resource Identifiers (URIs)", RFC 8615, May 2019.


[RFC8693]

Jones, M., Campbell, B., and D. Waite, "OAuth 2.0 Token Exchange", RFC 8693, DOI 10.17487/RFC8693, January 2020.


[RFC8705]

Campbell, B., Bradley, J., Sakimura, N., and T. Lodderstedt, "OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens", RFC 8705, DOI 10.17487/RFC8705, February 2020.


[RFC8707]

Campbell, B., Bradley, J., and H. Tschofenig, "Resource Indicators for OAuth 2.0", RFC 8707, DOI 10.17487/RFC8707, February 2020.


[RFC8725]

Sheffer, Y., Hardt, D., and M. Jones, "JSON Web Token Best Current Practices", RFC 8725, DOI 10.17487/RFC8725, June 2020.


[RFC9068]

Bertocci, V., "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens", RFC 9068, October 2021.


[RFC9101]

Sakimura, N., Bradley, J., Jones, M., "The OAuth 2.0 Authorization Framework: JWT-Secured Authorization Request (JAR)", RFC9101, August 2021.


[RFC9110]

Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., "HTTP Semantics", STD 97, RFC 9110, DOI 10.17487/RFC9110, June 2022.


[RFC9126]

Lodderstedt, T., Campbell, B., Sakimura, N., Tonge, D., and F. Skokan, "OAuth 2.0 Pushed Authorization Requests", RFC 9126, DOI 10.17487/RFC9126, September 2021.


[RFC9207]

Meyer zu Selhausen, K. and D. Fett, "OAuth 2.0 Authorization Server Issuer Identification", RFC 9207, DOI 10.17487/RFC9207, March 2022.


[RFC9449]

Fett, D., Campbell, B., Bradley, J., Lodderstedt, T., Jones, M., and D. Waite, "OAuth 2.0 Demonstrating Proof of Possession (DPoP)", RFC 9449, DOI 10.17487/RFC9449, September 2023.


[RFC9700]

Lodderstedt, T., Bradley, J., Labunets, A., Fett, D., "Best Current Practice for OAuth 2.0 Security", RFC 9700, January 2025.


[RFC9728]

Jones, M.B., Hunt, P., Parecki. A., "OAuth 2.0 Protected Resource Metadata", RFC 9728, April 2025.


[NIST.800-52.Rev2]

NIST Special Publication 800-52, Revision 2, "Guidelines for the Selection, Configuration, and Use of Transport Layer Security (TLS) Implementations".


[NIST.800-131A.Rev2]

NIST Special Publication 800-131A Revision 2, "Transitioning the Use of Cryptographic Algorithms and Key Lengths"


[OIDC.Sweden.Profile]

The Swedish OpenID Connect Profile - Version 1.0.


[OIDC.Sweden.Parameters]

Authentication Request Parameter Extensions for the Swedish OpenID Connect Profile - Version 1.1.


[OIDC.Sweden.Claims]

Claims and Scopes Specification for the Swedish OpenID Connect Profile - Version 1.0.


[OpenID.Discovery]

Sakimura, N., Bradley, J., Jones, M., and E. Jay, "OpenID Connect Discovery 1.0 incorporating errata set 2", December 2023.


[IANA.Pars]

IANA - OAuth Parameters.

10.2. Informational References


[OAuth-2.1]

Hardt, D., Parecki, A., Lodderstedt, T., "The OAuth 2.1 Authorization Framework", Draft 12, November 2024


[OAuth.ID-Chaining]

Schwenkschuster, A., Kasselmann, P., Burgin, K., Jenkins, M., Campbell, B., "OAuth Identity and Authorization Chaining Across Domains", Draft 4, February 2025.


[OpenID.Core]

Sakimura, N., Bradley, J., Jones, M., de Medeiros, B. and C. Mortimore, "OpenID Connect Core 1.0", August 2015.


[OpenID.Discovery]

Sakimura, N., Bradley, J., Jones, M., and E. Jay, "OpenID Connect Discovery 1.0 incorporating errata set 2", December 2023.


[OpenID.Federation]

Hedberg, R., Jones, M.B., Solberg, A.Å., Bradley, J., De Marco, G., Dzhuvinov, V., "OpenID Federation 1.0", March 2025.


[ENA.Federation]

Ena OAuth 2.0 Federation Interoperability Profile.


[Audience.Injection]

Hosseyni, P., Küsters, R., and T. Würtele, "Audience Injection Attacks: A New Class of Attacks on Web-Based Authorization and Authentication Standards", Cryptology ePrint Archive Paper 2025/629, April 2025.


[OWASP.Top10]

OWASP, "OWASP Top 10 - 2021: The Ten Most Critical Web Application Security Risks", OWASP Foundation.


[OWASP.OAuth2]

OWASP, "OAuth 2.0 Security Cheat Sheet", OWASP Cheat Sheet Series.


[OWASP.Authorization]

OWASP, "Authorization Cheat Sheet", OWASP Cheat Sheet Series.


[OWASP.Redirect]

OWASP Foundation, "Unvalidated Redirects and Forwards Cheat Sheet", OWASP Cheat Sheet Series.