asvs/v10-oauth-oidc

40 notes, read out of this brain and free to use. Each one was extracted from a source and is re-checked against its exam.

V10.1.1 Token distribution to only necessary components

Requirement 10.1.1 (Level 2) requires that tokens are only sent to components that strictly need them. For example, when using a backend-for-frontend pattern for browser-based JavaScript applications, access and refresh tokens shall only be accessible for the backend.

V10.1.2 Client must validate authorization flow values

Requirement 10.1.2 (Level 2) requires that the client only accepts values from the authorization server (such as the authorization code or ID Token) if these values result from an authorization flow that was initiated by the same user agent session and transaction. This requires that client-generated secrets, such as PKCE 'code_verifier', 'state' or OIDC 'nonce', are not guessable, are specific to the transaction, and are securely bound to both the client and the user agent session in which the transaction was started.

V10.2.1 OAuth client CSRF protection

Requirement 10.2.1 (Level 2) requires that if the code flow is used, the OAuth client has protection against cross-site request forgery (CSRF) attacks which trigger token requests, either by using PKCE functionality or checking the 'state' parameter that was sent in the authorization request.

V10.2.2 OAuth client defense against mix-up attacks

Requirement 10.2.2 (Level 2) requires that if the OAuth client can interact with more than one authorization server, it has a defense against mix-up attacks. For example, it could require that the authorization server return the 'iss' parameter value and validate it in the authorization response and the token response.

V10.2.3 OAuth client minimal scope requests

Requirement 10.2.3 (Level 3) requires that the OAuth client only requests the required scopes (or other authorization parameters) in requests to the authorization server.

V10.3.1 Resource server audience validation

Requirement 10.3.1 (Level 2) requires that the resource server only accepts access tokens that are intended for use with that service (audience). The audience may be included in a structured access token (such as the 'aud' claim in JWT), or it can be checked using the token introspection endpoint.

V10.3.2 Resource server authorization claims enforcement

Requirement 10.3.2 (Level 2) requires that the resource server enforces authorization decisions based on claims from the access token that define delegated authorization. If claims such as 'sub', 'scope', and 'authorization_details' are present, they must be part of the decision.

V10.3.3 Resource server unique user identification from access token

Requirement 10.3.3 (Level 2) requires that if an access control decision requires identifying a unique user from an access token (JWT or related token introspection response), the resource server identifies the user from claims that cannot be reassigned to other users. Typically, it means using a combination of 'iss' and 'sub' claims.

V10.3.4 Resource server authentication strength validation

Requirement 10.3.4 (Level 2) requires that if the resource server requires specific authentication strength, methods, or recentness, it verifies that the presented access token satisfies these constraints. For example, if present, using the OIDC 'acr', 'amr' and 'auth_time' claims respectively.

V10.3.5 Resource server prevention of stolen or replayed access tokens

Requirement 10.3.5 (Level 3) requires that the resource server prevents the use of stolen access tokens or replay of access tokens (from unauthorized parties) by requiring sender-constrained access tokens, either Mutual TLS for OAuth 2 or OAuth 2 Demonstration of Proof of Possession (DPoP).

V10.4.1 Authorization server redirect URI validation

Requirement 10.4.1 (Level 1) requires that the authorization server validates redirect URIs based on a client-specific allowlist of pre-registered URIs using exact string comparison.

V10.4.2 Authorization code single-use requirement

Requirement 10.4.2 (Level 1) requires that if the authorization server returns the authorization code in the authorization response, it can be used only once for a token request. For the second valid request with an authorization code that has already been used to issue an access token, the authorization server must reject a token request and revoke any issued tokens related to the authorization code.

V10.4.3 Authorization code lifetime limit

Requirement 10.4.3 (Level 1) requires that the authorization code is short-lived. The maximum lifetime can be up to 10 minutes for L1 and L2 applications and up to 1 minute for L3 applications.

V10.4.4 Authorization server restricted grant types per client

Requirement 10.4.4 (Level 1) requires that for a given client, the authorization server only allows the usage of grants that this client needs to use. Note that the grants 'token' (Implicit flow) and 'password' (Resource Owner Password Credentials flow) must no longer be used.

V10.4.5 Refresh token replay attack mitigation

Requirement 10.4.5 (Level 1) requires that the authorization server mitigates refresh token replay attacks for public clients, preferably using sender-constrained refresh tokens, i.e., Demonstrating Proof of Possession (DPoP) or Certificate-Bound Access Tokens using mutual TLS (mTLS). For L1 and L2 applications, refresh token rotation may be used. If refresh token rotation is used, the authorization server must invalidate the refresh token after usage, and revoke all refresh tokens for that authorization if an already used and invalidated refresh token is provided.

V10.4.6 Authorization code interception mitigation via PKCE

Requirement 10.4.6 (Level 2) requires that if the code grant is used, the authorization server mitigates authorization code interception attacks by requiring proof key for code exchange (PKCE). For authorization requests, the authorization server must require a valid 'code_challenge' value and must not accept a 'code_challenge_method' value of 'plain'. For a token request, it must require validation of the 'code_verifier' parameter.

V10.4.7 Unauthenticated dynamic client registration security measures

Requirement 10.4.7 (Level 2) requires that if the authorization server supports unauthenticated dynamic client registration, it mitigates the risk of malicious client applications. It must validate client metadata such as any registered URIs, ensure the user's consent, and warn the user before processing an authorization request with an untrusted client application.

V10.4.8 Refresh token absolute expiration

Requirement 10.4.8 (Level 2) requires that refresh tokens have an absolute expiration, including if sliding refresh token expiration is applied.

V10.4.9 Refresh token and reference access token revocation

Requirement 10.4.9 (Level 2) requires that refresh tokens and reference access tokens can be revoked by an authorized user using the authorization server user interface, to mitigate the risk of malicious clients or stolen tokens.

V10.4.10 Confidential client authentication for backchannel requests

Requirement 10.4.10 (Level 2) requires that confidential client is authenticated for client-to-authorized server backchannel requests such as token requests, pushed authorization requests (PAR), and token revocation requests.

V10.4.11 Authorization server minimal scope assignment

Requirement 10.4.11 (Level 2) requires that the authorization server configuration only assigns the required scopes to the OAuth client.

V10.4.12 Authorization server response_mode validation per client

Requirement 10.4.12 (Level 3) requires that for a given client, the authorization server only allows the 'response_mode' value that this client needs to use. For example, by having the authorization server validate this value against the expected values or by using pushed authorization request (PAR) or JWT-secured Authorization Request (JAR).

V10.4.13 Code grant type requires pushed authorization requests

Requirement 10.4.13 (Level 3) requires that grant type 'code' is always used together with pushed authorization requests (PAR).

V10.4.14 Sender-constrained access tokens requirement

Requirement 10.4.14 (Level 3) requires that the authorization server issues only sender-constrained (Proof-of-Possession) access tokens, either with certificate-bound access tokens using mutual TLS (mTLS) or DPoP-bound access tokens (Demonstration of Proof of Possession).

V10.4.15 Authorization details parameter integrity for server-side clients

Requirement 10.4.15 (Level 3) requires that for a server-side client (which is not executed on the end-user device), the authorization server ensures that the 'authorization_details' parameter value is from the client backend and that the user has not tampered with it. For example, by requiring the usage of pushed authorization request (PAR) or JWT-secured Authorization Request (JAR).

V10.4.16 Strong client authentication methods requirement

Requirement 10.4.16 (Level 3) requires that the client is confidential and the authorization server requires the use of strong client authentication methods (based on public-key cryptography and resistant to replay attacks), such as mutual TLS ('tls_client_auth', 'self_signed_tls_client_auth') or private key JWT ('private_key_jwt').

V10.5.1 OIDC ID Token replay attack mitigation

Requirement 10.5.1 (Level 2) requires that the client (as the relying party) mitigates ID Token replay attacks. For example, by ensuring that the 'nonce' claim in the ID Token matches the 'nonce' value sent in the authentication request to the OpenID Provider (in OAuth2 referred to as the authorization request sent to the authorization server).

V10.5.2 OIDC unique user identification from ID Token

Requirement 10.5.2 (Level 2) requires that the client uniquely identifies the user from ID Token claims, usually the 'sub' claim, which cannot be reassigned to other users (for the scope of an identity provider).

V10.5.3 OIDC authorization server metadata impersonation prevention

Requirement 10.5.3 (Level 2) requires that the client rejects attempts by a malicious authorization server to impersonate another authorization server through authorization server metadata. The client must reject authorization server metadata if the issuer URL in the authorization server metadata does not exactly match the pre-configured issuer URL expected by the client.

V10.5.4 OIDC ID Token audience validation

Requirement 10.5.4 (Level 2) requires that the client validates that the ID Token is intended to be used for that client (audience) by checking that the 'aud' claim from the token is equal to the 'client_id' value for the client.

V10.5.5 OIDC back-channel logout denial of service mitigation

Requirement 10.5.5 (Level 2) requires that when using OIDC back-channel logout, the relying party mitigates denial of service through forced logout and cross-JWT confusion in the logout flow. The client must verify that the logout token is correctly typed with a value of 'logout+jwt', contains the 'event' claim with the correct member name, and does not contain a 'nonce' claim. Note that it is also recommended to have a short expiration (e.g., 2 minutes).

V10.6.1 OpenID Provider response mode restriction

Requirement 10.6.1 (Level 2) requires that the OpenID Provider only allows values 'code', 'ciba', 'id_token', or 'id_token code' for response mode. Note that 'code' is preferred over 'id_token code' (the OIDC Hybrid flow), and 'token' (any Implicit flow) must not be used.

V10.6.2 OpenID Provider forced logout denial of service mitigation

Requirement 10.6.2 (Level 2) requires that the OpenID Provider mitigates denial of service through forced logout. By obtaining explicit confirmation from the end-user or, if present, validating parameters in the logout request (initiated by the relying party), such as the 'id_token_hint'.

V10.7.1 Authorization server user consent verification

Requirement 10.7.1 (Level 2) requires that the authorization server ensures that the user consents to each authorization request. If the identity of the client cannot be assured, the authorization server must always explicitly prompt the user for consent.

V10.7.2 Authorization server consent prompt information clarity

Requirement 10.7.2 (Level 2) requires that when the authorization server prompts for user consent, it presents sufficient and clear information about what is being consented to. When applicable, this should include the nature of the requested authorizations (typically based on scope, resource server, Rich Authorization Requests (RAR) authorization details), the identity of the authorized application, and the lifetime of these authorizations.

V10.7.3 User consent review, modification, and revocation

Requirement 10.7.3 (Level 2) requires that the user can review, modify, and revoke consents which the user has granted through the authorization server.

ASVS 5.0 Chapter V10 OAuth and OIDC control objective

Chapter V10 addresses requirements for OAuth 2.0 and OpenID Connect (OIDC) implementations. OAuth is an industry-standard framework for delegated authorization. OIDC extends OAuth by adding a user identity layer on top of OAuth, providing support for standardized user information, Single Sign-On (SSO), and session management. The chapter addresses best current practices aligned with specifications at oauth.net and openid.net/developers/specs/. ASVS 5.0 focuses on web applications and APIs and incorporates requirements from RFCs including RFC6749, RFC6750, RFC7636, RFC8628, RFC9068, RFC9126, RFC9207, RFC9396, RFC9449, RFC9700, and draft OAuth 2.0 for Browser-Based Applications.

OAuth and OIDC roles definitions

OAuth defines the following roles: OAuth client (application that obtains access to server resources using issued access tokens), confidential client (capable of maintaining credential confidentiality), public client (not capable of maintaining credential confidentiality), OAuth resource server (server API exposing resources), OAuth authorization server (server issuing access tokens), and resource owner (end-user authorizing clients). OIDC defines relying party (client requesting end-user authentication through OpenID Provider) and OpenID Provider (OAuth AS capable of authenticating end-user and providing OIDC claims).

OAuth and OIDC token types definition

In the context of ASVS Chapter V10, the term 'token' refers to: access tokens (consumed only by resource server, can be reference tokens validated using introspection or self-contained tokens validated using key material), refresh tokens (consumed only by authorization server that issued them), and OIDC ID Tokens (consumed only by client that triggered authorization flow).

V10.4 client authentication allowed methods

Authorization server client authentication allows 'self_signed_tls_client_auth' method with prerequisites required by section 2.2 of RFC 8705.

Give your agent this brain