OAuth 2.0

Client (system in scope - ID: CLIENT)

An application requesting access from the RESOURCE_OWNER (TODO: refine this description)

Confidential Client (system in scope - ID: CONFIDENTIAL_CLIENT)

Clients capable of maintaining the confidentiality of their credentials (e.g., client implemented on a secure server with restricted access to the client credentials), or capable of secure client authentication using other means.

Specifies, inherit analysis and attribute from:

Client (CLIENT)

Confidential Client (system in scope - ID: PUBLIC_CLIENT)

Clients incapable of maintaining the confidentiality of their credentials (e.g., clients executing on the device used by the resource owner, such as an installed native application or a web browser-based application), and incapable of secure client authentication via any other means.

Specifies, inherit analysis and attribute from:

Client (CLIENT)

Authorization Grant (credential in scope - ID: AUTHORIZATION_GRANT)

An authorization grant is a credential representing the resource owner's authorization (to access its protected resources) used by the client to obtain an access token. This specification defines four grant types -- authorization code, implicit, resource owner password credentials, and client credentials -- as well as an extensibility mechanism for defining additional types.

Access Token (credential in scope - ID: ACCESS_TOKEN)

Access tokens are credentials used to access protected resources. An access token is a string representing an authorization issued to the client. The string is usually opaque to the client. Tokens represent specific scopes and durations of access, granted by the resource owner, and enforced by the resource server and authorization server.

The token may denote an identifier used to retrieve the authorization information or may self-contain the authorization information in a verifiable manner (i.e., a token string consisting of some data and a signature). Additional authentication credentials, which are beyond the scope of this specification, may be required in order for the client to use a token.

The access token provides an abstraction layer, replacing different authorization constructs (e.g., username and password) with a single token understood by the resource server. This abstraction enables issuing access tokens more restrictive than the authorization grant used to obtain them, as well as removing the resource server's need to understand a wide range of authentication methods.

Access tokens can have different formats, structures, and methods of utilization (e.g., cryptographic properties) based on the resource server security requirements. Access token attributes and the methods used to access protected resources are beyond the scope of this specification and are defined by companion specifications such as [RFC6750].

Client secret for authentication with AUTH_SERVER (credential in scope - ID: CLIENT_SECRETS)

Secrets held by CLIENT to authentication to the Authorization Server

Authorization server (system in scope - ID: AUTH_SERVER)

The server issuing access tokens to the client after successfully authenticating the resource owner and obtaining authorization.

Auth User Agent Redirection (dataflow in scope - ID: DF_AUTH_REDIRECT)

User Agent Redirection for Client authorization request. this is part of DF_AUTH_REQUEST

Auth server sending the access token to the client (dataflow in scope - ID: DF_ACCESS_TOKEN_CL)

Auth server sending the access token to the client after resource owner approval

Client requesting Authorization Server for the Access Token (dataflow in scope - ID: DF_AUTH_GRANT_AS)

Client requesting Authorization Server for the Access Token after resource owner approval

Public Client (system in scope - ID: CONFIDENTIAL_CLIENT)

Clients capable of maintaining the confidentiality of their credentials (e.g., client implemented on a secure server with restricted access to the client credentials), or capable of secure client authentication using other means. For example a web application. A web application is a confidential client running on a web server. Resource owners access the client via an HTML user interface rendered in a user-agent on the device used by the resource owner. The client credentials as well as any access token issued to the client are stored on the web server and are not exposed to or accessible by the resource owner.

Public Client (system in scope - ID: PUBLIC_CLIENT)

Clients incapable of maintaining the confidentiality of their credentials (e.g., clients executing on the device used by the resource owner, such as an installed native application or a web browser-based application), and incapable of secure client authentication via any other means. For example a user-agent-based application or a native applications.

Client Identifier (data in scope - ID: CLIENT_ID)

The authorization server issues the registered client a client identifier -- a unique string representing the registration information provided by the client. The client identifier is not a secret; it is exposed to the resource owner and MUST NOT be used alone for client authentication. The client identifier is unique to the authorization server.

The client identifier string size is left undefined by this specification. The client should avoid making assumptions about the identifier size. The authorization server SHOULD document the size of any identifier it issues.

Client Secrets Disclosure and impersonation (Client_Secrets_disclosure)

Threat Description

Obtain Secret From Source Code or Binary: This applies for all client types. For open source projects, secrets can be extracted directly from source code in their public repositories. Secrets can be extracted from application binaries just as easily when the published source is not available to the attacker. Even if an application takes significant measures to obfuscate secrets in their application distribution, one should consider that the secret can still be reverse-engineered by anyone with access to a complete functioning application bundle or binary.

Impact

- Client authentication of access to the authorization server can be bypassed. - Stolen refresh tokens or authorization "codes" can be replayed. - Client spoofing/impersonation
CONFIDENTIALITY
INTEGRITY

CVSS

Base score: 6.8 (Medium)
Vector:CVSS:3.0/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:N

Counter-measures for Client_Secrets_disclosure

5_2_3_1_CLIENT_CHECK1 Checks on client's security policy

Don't issue secrets to public clients or clients with inappropriate security policy

Countermeasure in place? ✔ Public and disclosable? ✔ Is operational?✔ (operated by AUTHORIZATION_SERVER)

5_2_3_2_USER_CONSENT1 Require User Consent for Public Clients without Secret

Authorization servers should not allow automatic authorization for public clients. The authorization server may issue an individual client id but should require that all authorizations are approved by the end user. For clients without secrets, this is a countermeasure against the following threat: - Impersonation of public client applications.

Countermeasure in place? ✔ Public and disclosable? ✔ Is operational?✔ (operated by AUTHORIZATION_SERVER)

5_2_3_3_CLIENT_ID_TO_REDIRECT_URI Issue a "client_id" Only in Combination with "redirect_uri"

The authorization server may issue a "client_id" and bind the "client_id" to a certain pre-configured "redirect_uri". Any authorization request with another redirect URI is refused automatically. Alternatively, the authorization server should not accept any dynamic redirect URI for such a "client_id" and instead should always redirect to the well-known pre-configured redirect URI. This is a countermeasure for clients without secrets against the following threats:

• Cross-site scripting attacks

• Impersonation of public client applications

Countermeasure in place? ✔ Public and disclosable? ✔ Is operational?✔ (operated by AUTHORIZATION_SERVER)

5_2_3_4_SPECIFIC_CLIENT_SECRETS Issue Installation-Specific Client Secrets

An authorization server may issue separate client identifiers and corresponding secrets to the different installations of a particular client (i.e., software package). The effect of such an approach would be to turn otherwise "public" clients back into "confidential" clients.

For web applications, this could mean creating one "client_id" and "client_secret" for each web site on which a software package is installed. So, the provider of that particular site could request a client id and secret from the authorization server during the setup of the web site. This would also allow the validation of some of the properties of that web site, such as redirect URI, web site URL, and whatever else proves useful. The web site provider has to ensure the security of the client secret on the site.

For native applications, things are more complicated because every copy of a particular application on any device is a different installation. Installation-specific secrets in this scenario will require obtaining a "client_id" and "client_secret" either

1. during the download process from the application market, or

2. during installation on the device.

Either approach will require an automated mechanism for issuing client ids and secrets, which is currently not defined by OAuth.

The first approach would allow the achievement of a certain level of trust in the authenticity of the application, whereas the second option only allows the authentication of the installation but not the validation of properties of the client. But this would at least help to prevent several replay attacks. Moreover, installation-specific "client_ids" and secrets allow the selective revocation of all refresh tokens of a specific installation at once.

Countermeasure in place? ✔ Public and disclosable? ✔ Is operational?✔ (operated by AUTHORIZATION_SERVER_OPERATOR)

5_2_3_5_VALIDATE_REDIRECT_URI Validate Pre-Registered "redirect_uri"

An authorization server should require all clients to register their "redirect_uri", and the "redirect_uri" should be the full URI as defined in [RFC6749]. The way that this registration is performed is out of scope of this document. As per the core spec, every actual redirect URI sent with the respective "client_id" to the end-user authorization endpoint must match the registered redirect URI. Where it does not match, the authorization server should assume that the inbound GET request has been sent by an attacker and refuse it. Note: The authorization server should not redirect the user agent back to the redirect URI of such an authorization request. Validating the pre-registered "redirect_uri" is a countermeasure against the following threats:

o Authorization "code" leakage through counterfeit web site: allows authorization servers to detect attack attempts after the first redirect to an end-user authorization endpoint (Section 4.4.1.7).

o Open redirector attack via a client redirection endpoint (Section 4.1.5).

o Open redirector phishing attack via an authorization server redirection endpoint (Section 4.2.4).

The underlying assumption of this measure is that an attacker will need to use another redirect URI in order to get access to the authorization "code". Deployments might consider the possibility of an attacker using spoofing attacks to a victim's device to circumvent this security measure.

Note: Pre-registering clients might not scale in some deployments (manual process) or require dynamic client registration (not specified yet). With the lack of dynamic client registration, a pre-registered "redirect_uri" only works for clients bound to certain deployments at development/configuration time. As soon as dynamic resource server discovery is required, the pre-registered "redirect_uri" may no longer be feasible. 5_Validate_redirect_uri

Note: An invalid redirect URI indicates an invalid client, whereas a valid redirect URI does not necessarily indicate a valid client. The level of confidence depends on the client type. For web applications, the level of confidence is high, since the redirect URI refers to the globally unique network endpoint of this application, whose fully qualified domain name (FQDN) is also validated using HTTPS server authentication by the user agent. In contrast, for native clients, the redirect URI typically refers to device local resources, e.g., a custom scheme. So, a malicious client on a particular device can use the valid redirect URI the legitimate client uses on all other devices.

Countermeasure in place? ❌ Public and disclosable? ✔ Is operational?✔ (operated by AUTHORIZATION_SERVER)

User Unintentionally Grants Too Much Access Scope (TOO_MUCH_GRANT)

Threat Description

When obtaining end-user authorization, the end user may not understand the scope of the access being granted and to whom, or they may end up providing a client with access to resources that should not be permitted.

Impact

Disclosure of RESOURCE_OWNER's RESOURCES
CONFIDENTIALITY

CVSS

Base score: 5.3 (Medium)
Vector:CVSS:3.0/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:N/A:N

Counter-measures for TOO_MUCH_GRANT

AUTH_SERVER_RE_CHECK_GRANTS AUTHORIZATION_SERVER policy discretional decision

Narrow the scope, based on the client. When obtaining end-user authorization and where the client requests scope, the authorization server may want to consider whether to honor that scope based on the client identifier. That decision is between the client and authorization server and is outside the scope of this spec. The authorization server may also want to consider what scope to grant based on the client type, e.g., providing lower scope to public clients (Section 5.1.5.1).

Countermeasure in place? ✔ Public and disclosable? ✔ Is operational?✔ (operated by AUTHORIZATION_SERVER)

USER_AUTH_AWARENESS Users educated to avoid phishing attacks

Authorization servers should attempt to educate users about the risks posed by phishing attacks and should provide mechanisms that make it easy for users to confirm the authenticity of their sites. Section 5.1.2).

Countermeasure in place? ✔ Public and disclosable? ✔ Is operational?✔ (operated by AUTHORIZATION_SERVER)

Authorization server token endpoint (endpoint in scope - ID: AUTH_SERVER_TOKEN_ENDPOINT)

Authorization server's endpoint for DF_AUTH_GRANT_AS and DF_ACCESS_TOKEN_CL

Authorization endpoint for resource owner (endpoint in scope - ID: AUTH_SERVER_AUTH_ENDPOINT)

Authorization server's endpoint for DF_AUTH_REDIRECT

Password Phishing by Counterfeit Authorization Server (AuthServerPhishing1)

Threat Description

A hostile party could take advantage of this by intercepting the client's requests and returning misleading or otherwise incorrect responses. This could be achieved using DNS or Address Resolution Protocol (ARP) spoofing. Wide deployment of OAuth and similar protocols may cause users to become inured to the practice of being redirected to web sites where they are asked to enter their passwords. If users are not careful to verify the authenticity of these web sites before entering their credentials, it will be possible for attackers to exploit this practice to steal users' passwords.

Impact

Steal users' passwords
CONFIDENTIALITY

CVSS

Base score: 6.8 (Medium)
Vector:CVSS:3.0/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:N

Counter-measures for AuthServerPhishing1

5_1_2_AUTH_SERVER_AUTHENTICATION TLS for the authorization server

Authorization servers should consider such attacks when developing services based on OAuth and should require the use of transport- layer security for any requests where the authenticity of the authorization server or of request responses is an issue (see Section 5.1.2).

HTTPS server authentication or similar means can be used to authenticate the identity of a server. The goal is to reliably bind the fully qualified domain name of the server to the public key presented by the server during connection establishment (see [RFC2818]). The client should validate the binding of the server to its domain name. If the server fails to prove that binding, the communication is considered a man-in-the-middle attack. This security measure depends on the certification authorities the client trusts for that purpose. Clients should carefully select those trusted CAs and protect the storage for trusted CA certificates from modifications. This is a countermeasure against the following threats:
o Spoofing
o Proxying
o Phishing by counterfeit servers

Countermeasure in place? ✔ Public and disclosable? ✔ Is operational?✔ (operated by AUTHORIZATION_SERVER)

USER_PHISHING_AWARENESS Users educated to avoid phishing attacks

Authorization servers should attempt to educate users about the risks posed by phishing attacks and should provide mechanisms that make it easy for users to confirm the authenticity of their sites. Section 5.1.2).

Countermeasure in place? ✔ Public and disclosable? ✔ Is operational?✔ (operated by AUTHORIZATION_SERVER)

User Unintentionally Grants Too Much Access Scope (TOO_MUCH_GRANT)

Threat Description

When obtaining end-user authorization, the end user may not understand the scope of the access being granted and to whom, or they may end up providing a client with access to resources that should not be permitted.

Impact

Disclosure of RESOURCE_OWNER's RESOURCES
CONFIDENTIALITY

CVSS

Base score: 5.3 (Medium)
Vector:CVSS:3.0/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:N/A:N

Counter-measures for TOO_MUCH_GRANT

AUTH_SERVER_RE_CHECK_GRANTS AUTHORIZATION_SERVER policy discretional decision

Narrow the scope, based on the client. When obtaining end-user authorization and where the client requests scope, the authorization server may want to consider whether to honor that scope based on the client identifier. That decision is between the client and authorization server and is outside the scope of this spec. The authorization server may also want to consider what scope to grant based on the client type, e.g., providing lower scope to public clients (Section 5.1.5.1).

Countermeasure in place? ✔ Public and disclosable? ✔ Is operational?✔ (operated by AUTHORIZATION_SERVER)

USER_AUTH_AWARENESS Users educated to avoid phishing attacks

Authorization servers should attempt to educate users about the risks posed by phishing attacks and should provide mechanisms that make it easy for users to confirm the authenticity of their sites. Section 5.1.2).

Countermeasure in place? ✔ Public and disclosable? ✔ Is operational?✔ (operated by AUTHORIZATION_SERVER)

Authorization server open redirect (OPEN_REDIRECTOR)

Assets (IDs) involved in this threat:

• DF_AUTH_REDIRECT - Auth User Agent Redirection

• AUTH_SERVER - Authorization server

• AUTH_SERVER_AUTH_ENDPOINT - Authorization endpoint for resource owner

Threat Description

An attacker could use the end-user authorization endpoint and the redirect URI parameter to abuse the authorization server as an open redirector. An open redirector is an endpoint using a parameter to automatically redirect a user agent to the location specified by the parameter value without any validation.

Impact

Phishing attacks can be executed exploiting AUTH_SERVER open redirect

CVSS

Base score: 8.2 (High)
Vector:CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:L/A:N

Counter-measures for OPEN_REDIRECTOR

PRE_REGISTERED_REDIRECT_URI Pre-registered redirect URI

Require clients to register any full redirect URIs (Section 5.2.3.5). Don’t redirect to a redirect URI if the client identifier or redirect URI can’t be verified (Section 5.2.3.5). Authorization servers should not automatically process repeat authorizations to public clients unless the client is validated using a pre-registered redirect URI (Section 5.2.3.5).

Countermeasure in place? ✔ Public and disclosable? ✔

Malicious Client Obtains Existing Authorization by Fraud (PUBLIC_CLIENT_SPOOFING1)

Assets (IDs) involved in this threat:

• DF_AUTH_REDIRECT - Auth User Agent Redirection

• AUTH_SERVER_AUTH_ENDPOINT - Authorization endpoint for resource owner

• PUBLIC_CLIENT - Public Client

Threat Description

Authorization servers may wish to automatically process authorization requests from clients that have been previously authorized by the user. When the user is redirected to the authorization server's end- user authorization endpoint to grant access, the authorization server detects that the user has already granted access to that particular client. Instead of prompting the user for approval, the authorization server automatically redirects the user back to the client.

A malicious client may exploit that feature and try to obtain such an authorization "code" instead of the legitimate client.

Impact

Disclosure of RESOURCE_OWNER's RESOURCES
CONFIDENTIALITY

CVSS

Base score: 8.1 (High)
Vector:CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:N

Counter-measures for PUBLIC_CLIENT_SPOOFING1

Reference to OAuth2.AuthorizationServer.OPEN_REDIRECTOR.PRE_REGISTERED_REDIRECT_URI Pre-registered redirect URI

Require clients to register any full redirect URIs (Section 5.2.3.5). Don’t redirect to a redirect URI if the client identifier or redirect URI can’t be verified (Section 5.2.3.5). Authorization servers should not automatically process repeat authorizations to public clients unless the client is validated using a pre-registered redirect URI (Section 5.2.3.5).

Countermeasure in place? ✔ Public and disclosable? ✔

REDUCED_ACCESS_TOKEN_SCOPE Limiting the scope of access tokens obtained through automated approvals

Authorization servers can mitigate the risks associated with automatic processing by limiting the scope of access tokens obtained through automated approvals (Section 5.1.5.1).

Countermeasure in place? ❌ Public and disclosable? ✔ Is operational?✔ (operated by AUTHORIZATION_SERVER)

Eavesdropping Access Tokens (4_3_1_EAVESDROPPING_ACCESS_TOKENS1)

Assets (IDs) involved in this threat:

• DF_ACCESS_TOKEN_CL - Auth server sending the access token to the client

• DF_AUTH_GRANT_AS - Client requesting Authorization Server for the Access Token

• AUTH_SERVER_TOKEN_ENDPOINT - Authorization server token endpoint

Threat Description

Attackers may attempt to eavesdrop access tokens in transit from the authorization server to the client.

Impact

The attacker is able to access all resources with the permissions covered by the scope of the particular access token.
CONFIDENTIALITY
INTEGRITY

CVSS

Base score: 7.4 (High)
Vector:CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N

Counter-measures for 4_3_1_EAVESDROPPING_ACCESS_TOKENS1

CLIENT_AUTH_SERVER_TLS Secure transport layer to CLient to AUTH_SERVER by TLS

As per the core OAuth spec, the authorization servers must ensure that these transmissions are protected using transport-layer mechanisms such as TLS (see Section 5.1.1).

Countermeasure in place? ❌ Public and disclosable? ✔ Is operational?✔ (operated by AUTHORIZATION_SERVER)

Reference to OAuth2.AuthorizationServer.PUBLIC_CLIENT_SPOOFING1.REDUCED_ACCESS_TOKEN_SCOPE Limiting the scope of access tokens obtained through automated approvals

Authorization servers can mitigate the risks associated with automatic processing by limiting the scope of access tokens obtained through automated approvals (Section 5.1.5.1).

Countermeasure in place? ❌ Public and disclosable? ✔ Is operational?✔ (operated by AUTHORIZATION_SERVER)

Obtaining Access Tokens from Authorization Server Database (4_3_2_AS_DB_TOKEN_DISCLOSURE)

Assets (IDs) involved in this threat:

• ACCESS_TOKEN - Access Token

• AUTH_SERVER - Authorization server

Threat Description

An attacker may obtain access tokens from the authorization server’s database by gaining access to the database or launching a SQL injection attack.

This threat is applicable if the authorization server stores access tokens as handles in a database.

Impact

The attacker is able to access all resources for all tokens in Auth Server.
CONFIDENTIALITY
INTEGRITY

CVSS

Base score: 8.1 (High)
Vector:CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H

Counter-measures for 4_3_2_AS_DB_TOKEN_DISCLOSURE

5_1_4_1_3_HASHED_TOKEN_DB Store access token hashes only (Section 5.1.4.1.3).

Store access token hashes only (Section 5.1.4.1.3).

Countermeasure in place? ✔ Public and disclosable? ✔

5_1_4_1_1_SYS_SEC Enforce Standard System Security Means

A server system may be locked down so that no attacker may get access to sensitive configuration files and databases.

Countermeasure in place? ❌ Public and disclosable? ✔ Is operational?✔ (operated by AUTHORIZATION_SERVER_OPERATOR)

5_1_4_1_2_SQL_SEC Enforce Standard SQL Injection Countermeasures

If a client identifier or other authentication component is queried or compared against a SQL database, it may become possible for an injection attack to occur if parameters received are not validated before submission to the database.
o Ensure that server code is using the minimum database privileges possible to reduce the "surface" of possible attacks.
o Avoid dynamic SQL using concatenated input. If possible, use static SQL.
o When using dynamic SQL, parameterize queries using bind arguments. Bind arguments eliminate the possibility of SQL injections.
o Filter and sanitize the input. For example, if an identifier has a known format, ensure that the supplied value matches the identifier syntax rules.

Countermeasure in place? ❌ Public and disclosable? ✔

Disclosure of Client Credentials during Transmission (4_3_3_CLIENT_CREDENTIALS_DISCLOSURE)

Assets (IDs) involved in this threat:

• DF_AUTH_GRANT_AS - Client requesting Authorization Server for the Access Token

Threat Description

An attacker could attempt to eavesdrop the transmission of client credentials between the client and server during the client authentication process or during OAuth token requests.

Impact

Revelation of a client credential enabling phishing or impersonation of a client service.
CONFIDENTIALITY
INTEGRITY

CVSS

Base score: 7.4 (High)
Vector:CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N

Counter-measures for 4_3_3_CLIENT_CREDENTIALS_DISCLOSURE

5_1_1_CONFIDENTIAL_REQUESTS Ensure Confidentiality of Requests (TLS)

This is applicable to all requests sent from the client to the authorization server or resource server. While OAuth provides a mechanism for verifying the integrity of requests, it provides no guarantee of request confidentiality. Unless further precautions are taken, eavesdroppers will have full access to request content and may be able to mount interception or replay attacks by using the contents of requests, e.g., secrets or tokens. Attacks can be mitigated by using transport-layer mechanisms such as TLS [RFC5246]. A virtual private network (VPN), e.g., based on IPsec VPNs [RFC4301], may be considered as well. Note: This document assumes end-to-end TLS protected connections between the respective protocol entities. Deployments deviating from this assumption by offloading TLS in between (e.g., on the data center edge) must refine this threat model in order to account for the additional (mainly insider) threat this may cause. This is a countermeasure against the following threats:
o Replay of access tokens obtained on the token’s endpoint or the resource server’s endpoint
o Replay of refresh tokens obtained on the token’s endpoint Replay of authorization "codes" obtained on the token’s endpoint (redirect?)
o Replay of user passwords and client secrets

Countermeasure in place? ✔ Public and disclosable? ✔ Is operational?✔ (operated by CLIENT_OPERATOR)

CONFIDENTIAL_CREDENTIALS_REQUESTS Do not send plaintext credentials

Use alternative authentication means that do not require the sending of plaintext credentials over the wire (e.g., Hash-based Message Authentication Code).

Countermeasure in place? ❌ Public and disclosable? ✔

Obtaining Client Secret from Authorization Server Database (4_3_4_CLIENT_CREDENTIALS_DISCLOSURE)

Assets (IDs) involved in this threat:

• CLIENT_SECRETS - Client secret for authentication with AUTH_SERVER

Threat Description

An attacker may obtain valid "client_id"/secret combinations from the authorization server’s database by gaining access to the database or launching a SQL injection attack.

Impact

Disclosure of all "client_id"/secret combinations. This allows the attacker to act on behalf of legitimate clients.
CONFIDENTIALITY
INTEGRITY

CVSS

Base score: 7.4 (High)
Vector:CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N

Counter-measures for 4_3_4_CLIENT_CREDENTIALS_DISCLOSURE

Reference to OAuth2.AuthorizationServer.4_3_2_AS_DB_TOKEN_DISCLOSURE.5_1_4_1_2_SQL_SEC Enforce Standard SQL Injection Countermeasures

If a client identifier or other authentication component is queried or compared against a SQL database, it may become possible for an injection attack to occur if parameters received are not validated before submission to the database.
o Ensure that server code is using the minimum database privileges possible to reduce the "surface" of possible attacks.
o Avoid dynamic SQL using concatenated input. If possible, use static SQL.
o When using dynamic SQL, parameterize queries using bind arguments. Bind arguments eliminate the possibility of SQL injections.
o Filter and sanitize the input. For example, if an identifier has a known format, ensure that the supplied value matches the identifier syntax rules.

Countermeasure in place? ❌ Public and disclosable? ✔

Reference to OAuth2.AuthorizationServer.4_3_2_AS_DB_TOKEN_DISCLOSURE.5_1_4_1_1_SYS_SEC Enforce Standard System Security Means

A server system may be locked down so that no attacker may get access to sensitive configuration files and databases.

Countermeasure in place? ❌ Public and disclosable? ✔ Is operational?✔ (operated by AUTHORIZATION_SERVER_OPERATOR)

5_1_4_1_CRED_PROTECTION Enforce Credential Storage Protection Best Practices

Administrators should undertake industry best practices to protect the storage of credentials (for example, see [OWASP]). Such practices may include but are not limited to the following sub-sections.

Countermeasure in place? ❌ Public and disclosable? ✔ Is operational?✔ (operated by AUTHORIZATION_SERVER_OPERATOR)

Obtaining Client Secret by Online Guessing (4_3_5_CLIENT_SECRET_BRUTE_FORCE)

Assets (IDs) involved in this threat:

• CLIENT_SECRETS - Client secret for authentication with AUTH_SERVER

Threat actors:

• ANONYMOUS

Threat Description

An attacker may try to guess valid "client_id"/secret pairs.

Impact

Disclosure of a single "client_id"/secret pair.
CONFIDENTIALITY
INTEGRITY

CVSS

Base score: 7.7 (High)
Vector:CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:L

Counter-measures for 4_3_5_CLIENT_SECRET_BRUTE_FORCE

5_1_4_2_2_HIGH_ENTROPY_SECRETS Use High Entropy for Secrets

When creating secrets not intended for usage by human users (e.g., client secrets or token handles), the authorization server should include a reasonable level of entropy in order to mitigate the risk of guessing attacks. The token value should be >=128 bits long and constructed from a cryptographically strong random or pseudo-random number sequence (see [RFC4086] for best current practice) generated by the authorization server.

Countermeasure in place? ❌ Public and disclosable? ✔

5_1_4_2_3_LOCK_ACCOUNTS Lock Accounts

Online attacks on passwords can be mitigated by locking the respective accounts after a certain number of failed attempts. Note: This measure can be abused to lock down legitimate service users.

Countermeasure in place? ❌ Public and disclosable? ✔

5_2_3_7_STRONG_CLIENT_AUTHENTICATION Use strong client authentication

By using an alternative form of authentication such as client assertion [OAuth-ASSERTIONS], the need to distribute a "client_secret" is eliminated. This may require the use of a secure private key store or other supplemental authentication system as specified by the client assertion issuer in its authentication process. (e.g., client_assertion/client_token)

Countermeasure in place? ❌ Public and disclosable? ✔

Auth code is returned to the User Agent from the AUTH_SERVER (dataflow in scope - ID: DF_AUTH_CODE_AS)

AUTH_SERVER response 30x (redirect) Assuming the resource owner grants access, the authorization server redirects the user-agent back to the client using the redirection URI provided earlier (in the request or during client registration). The redirection URI includes an authorization code and any local state provided by the client earlier.

Auth code redirected to the CLIENT (dataflow in scope - ID: DF_AUTH_CODE_CLI)

USER_AGENT request (redirected from DF_AUTH_CODE_AS 30x response) Assuming the resource owner grants access, the authorization server redirects the user-agent back to the client using the redirection URI provided earlier (in the request or during client registration). The redirection URI includes an authorization code and any local state provided by the client earlier.

Eavesdropping or Leaking Authorization codes (4_4_1_1_AUTH_CODE_DISCLOSURE)

Assets (IDs) involved in this threat:

• AUTHORIZATION_GRANT - Authorization Grant

Threat actors:

• ANONYMOUS

Threat Description

An attacker could try to eavesdrop transmission of the authorization "code" between the authorization server and client. Furthermore, authorization "codes" are passed via the browser, which may unintentionally leak those codes to untrusted web sites and attackers in different ways:
o Referrer headers: Browsers frequently pass a "referer" header when a web page embeds content, or when a user travels from one web page to another web page. These referrer headers may be sent even when the origin site does not trust the destination site. The referrer header is commonly logged for traffic analysis purposes.
o Request logs: Web server request logs commonly include query parameters on requests.
o Open redirectors: Web sites sometimes need to send users to another destination via a redirector. Open redirectors pose a particular risk to web-based delegation protocols because the redirector can leak verification codes to untrusted destination sites.
o Browser history: Web browsers commonly record visited URLs in the browser history. Another user of the same web browser may be able to view URLs that were visited by previous users. Note: A description of similar attacks on the SAML protocol can be found at [OASIS.sstc-saml-bindings-1.1], Section 4.1.1.9.1; [Sec-Analysis]; and [OASIS.sstc-sec-analysis-response-01].

Impact

Auth codes can be used to
CONFIDENTIALITY
INTEGRITY

CVSS

Base score: 8.1 (High)
Vector:CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:N

Counter-measures for 4_4_1_1_AUTH_CODE_DISCLOSURE

Reference to OAuth2.AuthorizationServer.4_3_3_CLIENT_CREDENTIALS_DISCLOSURE.5_1_1_CONFIDENTIAL_REQUESTS Ensure Confidentiality of Requests (TLS)

This is applicable to all requests sent from the client to the authorization server or resource server. While OAuth provides a mechanism for verifying the integrity of requests, it provides no guarantee of request confidentiality. Unless further precautions are taken, eavesdroppers will have full access to request content and may be able to mount interception or replay attacks by using the contents of requests, e.g., secrets or tokens. Attacks can be mitigated by using transport-layer mechanisms such as TLS [RFC5246]. A virtual private network (VPN), e.g., based on IPsec VPNs [RFC4301], may be considered as well. Note: This document assumes end-to-end TLS protected connections between the respective protocol entities. Deployments deviating from this assumption by offloading TLS in between (e.g., on the data center edge) must refine this threat model in order to account for the additional (mainly insider) threat this may cause. This is a countermeasure against the following threats:
o Replay of access tokens obtained on the token’s endpoint or the resource server’s endpoint
o Replay of refresh tokens obtained on the token’s endpoint Replay of authorization "codes" obtained on the token’s endpoint (redirect?)
o Replay of user passwords and client secrets

Countermeasure in place? ✔ Public and disclosable? ✔ Is operational?✔ (operated by CLIENT_OPERATOR)

5_2_4_4_CLIENT_TO_CODE_BINDING Binding of Authorization "code" to "client_id"

The authorization server should bind every authorization "code" to the id of the respective client that initiated the end-user authorization process. This measure is a countermeasure against:
o Replay of authorization "codes" with different client credentials, since an attacker cannot use another "client_id" to exchange an authorization "code" into a token
o Online guessing of authorization "codes" Note: This binding should be protected from unauthorized modifications (e.g., using protected memory and/or a secure database). Also: The authorization server will require the client to authenticate wherever possible, so the binding of the authorization "code" to a certain client can be validated in a reliable way (see Section 5.2.4.4).

Countermeasure in place? ✔ Public and disclosable? ✔ Is operational?✔ (operated by AUTHORIZATION_SERVER_OPERATOR)

5_1_5_3_SHORT_EXPIRY_CODE Use Short Expiration Time

A short expiration time for tokens is a means of protection against the following threats:
o replay
o token leak (a short expiration time will reduce impact)
o online guessing (a short expiration time will reduce the likelihood of success) Note: Short token duration requires more precise clock synchronization between the authorization server and resource server. Furthermore, shorter duration may require more token refreshes (access token) or repeated end-user authorization processes (authorization "code" and refresh token).

Countermeasure in place? ❌ Public and disclosable? ✔ Is operational?✔ (operated by AUTHORIZATION_SERVER_OPERATOR)

5_1_5_4_ONE_TIME_USE_TOKEN Limit Number of Usages or One-Time Usage

The authorization server may restrict the number of requests or operations that can be performed with a certain token. This mechanism can be used to mitigate the following threats:
o replay of tokens
o guessing For example, if an authorization server observes more than one attempt to redeem an authorization "code", the authorization server may want to revoke all access tokens granted based on the authorization "code" as well as reject the current request. As with the authorization "code", access tokens may also have a limited number of operations. This either forces client applications to re-authenticate and use a refresh token to obtain a fresh access token, or forces the client to re-authorize the access token by involving the user.

Countermeasure in place? ❌ Public and disclosable? ✔ Is operational?✔ (operated by AUTHORIZATION_SERVER_OPERATOR)

5_2_1_1_TOKEN_ABUSE_DETECTION Automatic Revocation of Derived Tokens If Abuse Is Detected

If an authorization server observes multiple attempts to redeem an authorization grant (e.g., such as an authorization "code"), the authorization server may want to revoke all tokens granted based on the authorization grant

Countermeasure in place? ❌ Public and disclosable? ✔ Is operational?✔ (operated by AUTHORIZATION_SERVER_OPERATOR)

USER_AGENT_PAGE_RELOAD Reload the target page

The client server may reload the target page of the redirect URI in order to automatically clean up the browser cache.

Countermeasure in place? ❌ Public and disclosable? ✔ Is operational?✔ (operated by CLIENT_OPERATOR)

Obtaining Authorization codes from AuthorizationServer Database (4_4_1_2_AUTH_CODE_DISCLOSURE_DB)

Assets (IDs) involved in this threat:

• AUTH_SERVER - Authorization server

Threat actors:

• ANONYMOUS

Threat Description

This threat is applicable if the authorization server stores authorization "codes" as handles in a database. An attacker may obtain authorization "codes" from the authorization server’s database by gaining access to the database or launching a SQL injection attack.

Impact

Disclosure of all authorization "codes", most likely along with the respective "redirect_uri" and "client_id" values.
CONFIDENTIALITY
INTEGRITY

CVSS

Base score: 7.4 (High)
Vector:CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N

Counter-measures for 4_4_1_2_AUTH_CODE_DISCLOSURE_DB

Reference to OAuth2.AuthorizationServer.4_3_2_AS_DB_TOKEN_DISCLOSURE.5_1_4_1_1_SYS_SEC Enforce Standard System Security Means

A server system may be locked down so that no attacker may get access to sensitive configuration files and databases.

Countermeasure in place? ❌ Public and disclosable? ✔ Is operational?✔ (operated by AUTHORIZATION_SERVER_OPERATOR)

Reference to OAuth2.AuthorizationServer.4_3_2_AS_DB_TOKEN_DISCLOSURE.5_1_4_1_2_SQL_SEC Enforce Standard SQL Injection Countermeasures

If a client identifier or other authentication component is queried or compared against a SQL database, it may become possible for an injection attack to occur if parameters received are not validated before submission to the database.
o Ensure that server code is using the minimum database privileges possible to reduce the "surface" of possible attacks.
o Avoid dynamic SQL using concatenated input. If possible, use static SQL.
o When using dynamic SQL, parameterize queries using bind arguments. Bind arguments eliminate the possibility of SQL injections.
o Filter and sanitize the input. For example, if an identifier has a known format, ensure that the supplied value matches the identifier syntax rules.

Countermeasure in place? ❌ Public and disclosable? ✔

Reference to OAuth2.AuthorizationServer.4_3_2_AS_DB_TOKEN_DISCLOSURE.5_1_4_1_3_HASHED_TOKEN_DB Store access token hashes only (Section 5.1.4.1.3).

Store access token hashes only (Section 5.1.4.1.3).

Countermeasure in place? ✔ Public and disclosable? ✔

Online Guessing of Authorization codes (4_4_1_3_AUTH_CODE_BRUTE_FORCE)

Assets (IDs) involved in this threat:

• AUTHORIZATION_GRANT - Authorization Grant

Threat actors:

• ANONYMOUS

Threat Description

An attacker may try to guess valid authorization "code" values and send the guessed code value using the grant type "code" in order to obtain a valid access token.

Impact

Disclosure of a single access token and probably also an associated refresh token.
CONFIDENTIALITY
INTEGRITY

CVSS

Base score: 7.4 (High)
Vector:CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N

Counter-measures for 4_4_1_3_AUTH_CODE_BRUTE_FORCE

Reference to OAuth2.AuthorizationServer.4_3_5_CLIENT_SECRET_BRUTE_FORCE.5_1_4_2_2_HIGH_ENTROPY_SECRETS Use High Entropy for Secrets

When creating secrets not intended for usage by human users (e.g., client secrets or token handles), the authorization server should include a reasonable level of entropy in order to mitigate the risk of guessing attacks. The token value should be >=128 bits long and constructed from a cryptographically strong random or pseudo-random number sequence (see [RFC4086] for best current practice) generated by the authorization server.

Countermeasure in place? ❌ Public and disclosable? ✔

5_1_5_9_SIGNED_TOKEN Sign Self-Contained Tokens

Self-contained tokens should be signed in order to detect any attempt to modify or produce faked tokens (e.g., Hash-based Message Authentication Code or digital signatures).

Countermeasure in place? ❌ Public and disclosable? ✔ Is operational?✔ (operated by AUTHORIZATION_SERVER_OPERATOR)

Reference to OAuth2.Client.Client_Secrets_disclosure.5_2_3_4_SPECIFIC_CLIENT_SECRETS Issue Installation-Specific Client Secrets

An authorization server may issue separate client identifiers and corresponding secrets to the different installations of a particular client (i.e., software package). The effect of such an approach would be to turn otherwise "public" clients back into "confidential" clients.

For web applications, this could mean creating one "client_id" and "client_secret" for each web site on which a software package is installed. So, the provider of that particular site could request a client id and secret from the authorization server during the setup of the web site. This would also allow the validation of some of the properties of that web site, such as redirect URI, web site URL, and whatever else proves useful. The web site provider has to ensure the security of the client secret on the site.

For native applications, things are more complicated because every copy of a particular application on any device is a different installation. Installation-specific secrets in this scenario will require obtaining a "client_id" and "client_secret" either

1. during the download process from the application market, or

2. during installation on the device.

Either approach will require an automated mechanism for issuing client ids and secrets, which is currently not defined by OAuth.

The first approach would allow the achievement of a certain level of trust in the authenticity of the application, whereas the second option only allows the authentication of the installation but not the validation of properties of the client. But this would at least help to prevent several replay attacks. Moreover, installation-specific "client_ids" and secrets allow the selective revocation of all refresh tokens of a specific installation at once.

Countermeasure in place? ✔ Public and disclosable? ✔ Is operational?✔ (operated by AUTHORIZATION_SERVER_OPERATOR)

5_2_4_5_REDIRECT_CODE_BINDING Binding of Authorization "code" to "redirect_uri"

The authorization server should be able to bind every authorization "code" to the actual redirect URI used as the redirect target of the client in the end-user authorization process. This binding should be validated when the client attempts to exchange the respective authorization "code" for an access token. This measure is a countermeasure against authorization "code" leakage through counterfeit web sites, since an attacker cannot use another redirect URI to exchange an authorization "code" into a token.

Countermeasure in place? ❌ Public and disclosable? ✔ Is operational?✔ (operated by AUTHORIZATION_SERVER_OPERATOR)

Reference to OAuth2.Flows.Flows_AuthCode.4_4_1_1_AUTH_CODE_DISCLOSURE.5_1_5_3_SHORT_EXPIRY_CODE Use Short Expiration Time

A short expiration time for tokens is a means of protection against the following threats:
o replay
o token leak (a short expiration time will reduce impact)
o online guessing (a short expiration time will reduce the likelihood of success) Note: Short token duration requires more precise clock synchronization between the authorization server and resource server. Furthermore, shorter duration may require more token refreshes (access token) or repeated end-user authorization processes (authorization "code" and refresh token).

Countermeasure in place? ❌ Public and disclosable? ✔ Is operational?✔ (operated by AUTHORIZATION_SERVER_OPERATOR)

Malicious Client Obtains Authorization (4_4_1_4_CLIENT_SPOOFING1)

Threat actors:

• ANONYMOUS

Threat Description

A malicious client could pretend to be a valid client and obtain an access authorization in this way. The malicious client could even utilize screen-scraping techniques in order to simulate a user’s consent in the authorization flow.

Impact

Disclosure of a single access token and probably also an associated refresh token.
CONFIDENTIALITY
INTEGRITY

CVSS

Base score: 7.4 (High)
Vector:CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N

Counter-measures for 4_4_1_4_CLIENT_SPOOFING1

Reference to OAuth2.Client.Client_Secrets_disclosure.5_2_3_4_SPECIFIC_CLIENT_SECRETS Issue Installation-Specific Client Secrets

An authorization server may issue separate client identifiers and corresponding secrets to the different installations of a particular client (i.e., software package). The effect of such an approach would be to turn otherwise "public" clients back into "confidential" clients.

For web applications, this could mean creating one "client_id" and "client_secret" for each web site on which a software package is installed. So, the provider of that particular site could request a client id and secret from the authorization server during the setup of the web site. This would also allow the validation of some of the properties of that web site, such as redirect URI, web site URL, and whatever else proves useful. The web site provider has to ensure the security of the client secret on the site.

For native applications, things are more complicated because every copy of a particular application on any device is a different installation. Installation-specific secrets in this scenario will require obtaining a "client_id" and "client_secret" either

1. during the download process from the application market, or

2. during installation on the device.

Either approach will require an automated mechanism for issuing client ids and secrets, which is currently not defined by OAuth.

The first approach would allow the achievement of a certain level of trust in the authenticity of the application, whereas the second option only allows the authentication of the installation but not the validation of properties of the client. But this would at least help to prevent several replay attacks. Moreover, installation-specific "client_ids" and secrets allow the selective revocation of all refresh tokens of a specific installation at once.

Countermeasure in place? ✔ Public and disclosable? ✔ Is operational?✔ (operated by AUTHORIZATION_SERVER_OPERATOR)

Reference to OAuth2.Client.Client_Secrets_disclosure.5_2_3_5_VALIDATE_REDIRECT_URI Validate Pre-Registered "redirect_uri"

An authorization server should require all clients to register their "redirect_uri", and the "redirect_uri" should be the full URI as defined in [RFC6749]. The way that this registration is performed is out of scope of this document. As per the core spec, every actual redirect URI sent with the respective "client_id" to the end-user authorization endpoint must match the registered redirect URI. Where it does not match, the authorization server should assume that the inbound GET request has been sent by an attacker and refuse it. Note: The authorization server should not redirect the user agent back to the redirect URI of such an authorization request. Validating the pre-registered "redirect_uri" is a countermeasure against the following threats:

o Authorization "code" leakage through counterfeit web site: allows authorization servers to detect attack attempts after the first redirect to an end-user authorization endpoint (Section 4.4.1.7).

o Open redirector attack via a client redirection endpoint (Section 4.1.5).

o Open redirector phishing attack via an authorization server redirection endpoint (Section 4.2.4).

The underlying assumption of this measure is that an attacker will need to use another redirect URI in order to get access to the authorization "code". Deployments might consider the possibility of an attacker using spoofing attacks to a victim's device to circumvent this security measure.

Note: Pre-registering clients might not scale in some deployments (manual process) or require dynamic client registration (not specified yet). With the lack of dynamic client registration, a pre-registered "redirect_uri" only works for clients bound to certain deployments at development/configuration time. As soon as dynamic resource server discovery is required, the pre-registered "redirect_uri" may no longer be feasible. 5_Validate_redirect_uri

Note: An invalid redirect URI indicates an invalid client, whereas a valid redirect URI does not necessarily indicate a valid client. The level of confidence depends on the client type. For web applications, the level of confidence is high, since the redirect URI refers to the globally unique network endpoint of this application, whose fully qualified domain name (FQDN) is also validated using HTTPS server authentication by the user agent. In contrast, for native clients, the redirect URI typically refers to device local resources, e.g., a custom scheme. So, a malicious client on a particular device can use the valid redirect URI the legitimate client uses on all other devices.

Countermeasure in place? ❌ Public and disclosable? ✔ Is operational?✔ (operated by AUTHORIZATION_SERVER)

5_2_4_3_VALIDATION_OF_CLIENT_BY_END_USER Validation of Client Properties by End User

In the authorization process, the user is typically asked to approve a client’s request for authorization. This is an important security mechanism by itself because the end user can be involved in the validation of client properties, such as whether the client name known to the authorization server fits the name of the web site or the application the end user is using. This measure is especially helpful in situations where the authorization server is unable to authenticate the client. It is a countermeasure against:
o A malicious application
o A client application masquerading as another client

Countermeasure in place? ❌ Public and disclosable? ✔ Is operational?✔ (operated by RESOURCE_OWNER)

5_2_4_1_REPEAT_VALIDATE_CLIENT Automatic Processing of Repeated Authorizations Requires Client Validation

Authorization servers should NOT automatically process repeat authorizations where the client is not authenticated through a client secret or some other authentication mechanism such as a signed authentication assertion certificate (Section 5.2.3.7) or validation of a pre-registered redirect URI (Section 5.2.3.5).

Countermeasure in place? ❌ Public and disclosable? ✔ Is operational?✔ (operated by AUTHORIZATION_SERVER_OPERATOR)

REQUIRE_USER_MANUAL_STEP Automatic Processing of Repeated Authorizations Requires Client Validation

If the authorization server automatically authenticates the end user, it may nevertheless require some user input in order to prevent screen scraping. Examples are CAPTCHAs (Completely Automated Public Turing tests to tell Computers and Humans Apart) or other multi-factor authentication techniques such as random questions, token code generators, etc.

Countermeasure in place? ❌ Public and disclosable? ✔ Is operational?✔ (operated by AUTHORIZATION_SERVER_OPERATOR)

5_1_5_1_LIMITED_SCOPE_TOKEN Limit Token Scope

The authorization server may decide to reduce or limit the scope associated with a token. The basis of this decision is out of scope; examples are:

o a client-specific policy, e.g., issue only less powerful tokens to public clients,
o a service-specific policy, e.g., it is a very sensitive service,
o a resource-owner-specific setting, or
o combinations of such policies and preferences.

The authorization server may allow different scopes dependent on the grant type. For example, end-user authorization via direct interaction with the end user (authorization "code") might be considered more reliable than direct authorization via grant type "username"/"password". This means will reduce the impact of the following threats:
o token leakage
o token issuance to malicious software
o unintended issuance of powerful tokens with resource owner credentials flow

Countermeasure in place? ❌ Public and disclosable? ✔ Is operational?✔ (operated by AUTHORIZATION_SERVER_OPERATOR)

Authorization code Phishing (4_4_1_5_CLIENT_SPOOFING2)

Threat actors:

• ANONYMOUS

Threat Description

A hostile party could impersonate the client site and get access to the authorization "code". This could be achieved using DNS or ARP spoofing. This applies to clients, which are web applications; thus, the redirect URI is not local to the host where the user’s browser is running.

Impact

This affects web applications and may lead to a disclosure of authorization "codes" and, potentially, the corresponding access and refresh tokens.
CONFIDENTIALITY
INTEGRITY

CVSS

Base score: 6.9 (Medium)
Vector:CVSS:3.1/AV:L/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:L

Counter-measures for 4_4_1_5_CLIENT_SPOOFING2

Reference to OAuth2.AuthorizationServer.AuthServerPhishing1.5_1_2_AUTH_SERVER_AUTHENTICATION TLS for the authorization server

Authorization servers should consider such attacks when developing services based on OAuth and should require the use of transport- layer security for any requests where the authenticity of the authorization server or of request responses is an issue (see Section 5.1.2).

HTTPS server authentication or similar means can be used to authenticate the identity of a server. The goal is to reliably bind the fully qualified domain name of the server to the public key presented by the server during connection establishment (see [RFC2818]). The client should validate the binding of the server to its domain name. If the server fails to prove that binding, the communication is considered a man-in-the-middle attack. This security measure depends on the certification authorities the client trusts for that purpose. Clients should carefully select those trusted CAs and protect the storage for trusted CA certificates from modifications. This is a countermeasure against the following threats:
o Spoofing
o Proxying
o Phishing by counterfeit servers

Countermeasure in place? ✔ Public and disclosable? ✔ Is operational?✔ (operated by AUTHORIZATION_SERVER)

Reference to OAuth2.Flows.Flows_AuthCode.4_4_1_1_AUTH_CODE_DISCLOSURE.5_2_4_4_CLIENT_TO_CODE_BINDING Binding of Authorization "code" to "client_id"

The authorization server should bind every authorization "code" to the id of the respective client that initiated the end-user authorization process. This measure is a countermeasure against:
o Replay of authorization "codes" with different client credentials, since an attacker cannot use another "client_id" to exchange an authorization "code" into a token
o Online guessing of authorization "codes" Note: This binding should be protected from unauthorized modifications (e.g., using protected memory and/or a secure database). Also: The authorization server will require the client to authenticate wherever possible, so the binding of the authorization "code" to a certain client can be validated in a reliable way (see Section 5.2.4.4).

Countermeasure in place? ✔ Public and disclosable? ✔ Is operational?✔ (operated by AUTHORIZATION_SERVER_OPERATOR)

Authorization code Phishing (4_4_1_6_CLIENT_SPOOFING3)

Threat actors:

• ANONYMOUS

Threat Description

A hostile party could impersonate the client site and impersonate the user’s session on this client. This could be achieved using DNS or ARP spoofing. This applies to clients, which are web applications; thus, the redirect URI is not local to the host where the user’s browser is running.

Impact

An attacker who intercepts the authorization "code" as it is sent by the browser to the callback endpoint can gain access to protected resources by submitting the authorization "code" to the client. The client will exchange the authorization "code" for an access token and use the access token to access protected resources for the benefit of the attacker, delivering protected resources to the attacker, or modifying protected resources as directed by the attacker. If OAuth is used by the client to delegate authentication to a social site (e.g., as in the implementation of a "Login" button on a third-party social network site), the attacker can use the intercepted authorization "code" to log into the client as the user. Note: Authenticating the client during authorization "code" exchange will not help to detect such an attack, as it is the legitimate client that obtains the tokens.
CONFIDENTIALITY
INTEGRITY

CVSS

Base score: 6.9 (Medium)
Vector:CVSS:3.1/AV:L/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:L

Counter-measures for 4_4_1_6_CLIENT_SPOOFING3

Reference to OAuth2.AuthorizationServer.AuthServerPhishing1.5_1_2_AUTH_SERVER_AUTHENTICATION TLS for the authorization server

Authorization servers should consider such attacks when developing services based on OAuth and should require the use of transport- layer security for any requests where the authenticity of the authorization server or of request responses is an issue (see Section 5.1.2).

HTTPS server authentication or similar means can be used to authenticate the identity of a server. The goal is to reliably bind the fully qualified domain name of the server to the public key presented by the server during connection establishment (see [RFC2818]). The client should validate the binding of the server to its domain name. If the server fails to prove that binding, the communication is considered a man-in-the-middle attack. This security measure depends on the certification authorities the client trusts for that purpose. Clients should carefully select those trusted CAs and protect the storage for trusted CA certificates from modifications. This is a countermeasure against the following threats:
o Spoofing
o Proxying
o Phishing by counterfeit servers

Countermeasure in place? ✔ Public and disclosable? ✔ Is operational?✔ (operated by AUTHORIZATION_SERVER)

Authorization code Leakage through Counterfeit Client (4_4_1_7_CLIENT_SPOOFING4)

Threat actors:

• CLIENT_OPERATOR

Threat Description

The attacker leverages the authorization "code" grant type in an attempt to get another user (victim) to log in, authorize access to his/her resources, and subsequently obtain the authorization "code" and inject it into a client application using the attacker’s account. The goal is to associate an access authorization for resources of the victim with the user account of the attacker on a client site. The attacker abuses an existing client application and combines it with his own counterfeit client web site. The attacker depends on the victim expecting the client application to request access to a certain resource server. The victim, seeing only a normal request from an expected application, approves the request. The attacker then uses the victim’s authorization to gain access to the information unknowingly authorized by the victim. The attacker conducts the following flow:

1. The attacker accesses the client web site (or application) and initiates data access to a particular resource server. The client web site in turn initiates an authorization request to the resource server’s authorization server. Instead of proceeding with the authorization process, the attacker modifies the authorization server end-user authorization URL as constructed by the client to include a redirect URI parameter referring to a web site under his control (attacker’s web site).

2. The attacker tricks another user (the victim) into opening that modified end-user authorization URI and authorizing access (e.g., via an email link or blog link). The way the attacker achieves this goal is out of scope.

3. Having clicked the link, the victim is requested to authenticate and authorize the client site to have access.

4. After completion of the authorization process, the authorization server redirects the user agent to the attacker’s web site instead of the original client web site.

5. The attacker obtains the authorization "code" from his web site by means that are out of scope of this document.

6. He then constructs a redirect URI to the target web site (or application) based on the original authorization request’s redirect URI and the newly obtained authorization "code", and directs his user agent to this URL. The authorization "code" is injected into the original client site (or application).

7. The client site uses the authorization "code" to fetch a token from the authorization server and associates this token with the attacker’s user account on this site.

8. The attacker may now access the victim’s resources using the client site.

Impact

The attacker gains access to the victim’s resources as associated with his account on the client site.
CONFIDENTIALITY
INTEGRITY
NON_REPUDIATION

CVSS

Base score: 6.5 (Medium)
Vector:CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:N

Counter-measures for 4_4_1_7_CLIENT_SPOOFING4

Reference to OAuth2.Flows.Flows_AuthCode.4_4_1_3_AUTH_CODE_BRUTE_FORCE.5_2_4_5_REDIRECT_CODE_BINDING Binding of Authorization "code" to "redirect_uri"

The authorization server should be able to bind every authorization "code" to the actual redirect URI used as the redirect target of the client in the end-user authorization process. This binding should be validated when the client attempts to exchange the respective authorization "code" for an access token. This measure is a countermeasure against authorization "code" leakage through counterfeit web sites, since an attacker cannot use another redirect URI to exchange an authorization "code" into a token.

Countermeasure in place? ❌ Public and disclosable? ✔ Is operational?✔ (operated by AUTHORIZATION_SERVER_OPERATOR)

Reference to OAuth2.Client.Client_Secrets_disclosure.5_2_3_4_SPECIFIC_CLIENT_SECRETS Issue Installation-Specific Client Secrets

An authorization server may issue separate client identifiers and corresponding secrets to the different installations of a particular client (i.e., software package). The effect of such an approach would be to turn otherwise "public" clients back into "confidential" clients.

For web applications, this could mean creating one "client_id" and "client_secret" for each web site on which a software package is installed. So, the provider of that particular site could request a client id and secret from the authorization server during the setup of the web site. This would also allow the validation of some of the properties of that web site, such as redirect URI, web site URL, and whatever else proves useful. The web site provider has to ensure the security of the client secret on the site.

For native applications, things are more complicated because every copy of a particular application on any device is a different installation. Installation-specific secrets in this scenario will require obtaining a "client_id" and "client_secret" either

1. during the download process from the application market, or

2. during installation on the device.

Either approach will require an automated mechanism for issuing client ids and secrets, which is currently not defined by OAuth.

The first approach would allow the achievement of a certain level of trust in the authenticity of the application, whereas the second option only allows the authentication of the installation but not the validation of properties of the client. But this would at least help to prevent several replay attacks. Moreover, installation-specific "client_ids" and secrets allow the selective revocation of all refresh tokens of a specific installation at once.

Countermeasure in place? ✔ Public and disclosable? ✔ Is operational?✔ (operated by AUTHORIZATION_SERVER_OPERATOR)

Reference to OAuth2.Flows.Flows_AuthCode.4_4_1_1_AUTH_CODE_DISCLOSURE.5_2_4_4_CLIENT_TO_CODE_BINDING Binding of Authorization "code" to "client_id"

The authorization server should bind every authorization "code" to the id of the respective client that initiated the end-user authorization process. This measure is a countermeasure against:
o Replay of authorization "codes" with different client credentials, since an attacker cannot use another "client_id" to exchange an authorization "code" into a token
o Online guessing of authorization "codes" Note: This binding should be protected from unauthorized modifications (e.g., using protected memory and/or a secure database). Also: The authorization server will require the client to authenticate wherever possible, so the binding of the authorization "code" to a certain client can be validated in a reliable way (see Section 5.2.4.4).

Countermeasure in place? ✔ Public and disclosable? ✔ Is operational?✔ (operated by AUTHORIZATION_SERVER_OPERATOR)

IMPLICIT_GRANT_FLOW Implicit grant flow

The client may consider using other flows that are not vulnerable to this kind of attack, such as the implicit grant type (see Section 4.4.2) or resource owner password credentials (see Section 4.4.3).

Countermeasure in place? ❌ Public and disclosable? ✔

CSRF Attack against redirect-uri (4_4_1_8_CSRF_ON_REDIRECT)

Assets (IDs) involved in this threat:

• DF_AUTH_REDIRECT - Auth User Agent Redirection

Threat actors:

• ANONYMOUS

Threat Description

Cross-site request forgery (CSRF) is a web-based attack whereby HTTP requests are transmitted from a user that the web site trusts or has authenticated (e.g., via HTTP redirects or HTML forms). CSRF attacks on OAuth approvals can allow an attacker to obtain authorization to OAuth protected resources without the consent of the user. This attack works against the redirect URI used in the authorization "code" flow. An attacker could authorize an authorization "code" to their own protected resources on an authorization server. He then aborts the redirect flow back to the client on his device and tricks the victim into executing the redirect back to the client. The client receives the redirect, fetches the token(s) from the authorization server, and associates the victim’s client session with the resources accessible using the token.

Impact

The user accesses resources on behalf of the attacker. The effective impact depends on the type of resource accessed. For example, the user may upload private items to an attacker’s resources. Or, when using OAuth in 3rd-party login scenarios, the user may associate his client account with the attacker’s identity at the external Identity Provider. In this way, the attacker could easily access the victim’s data at the client by logging in from another device with his credentials at the external Identity Provider.
CONFIDENTIALITY
NON_REPUDIATION

CVSS

Base score: 8.1 (High)
Vector:CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:N

Counter-measures for 4_4_1_8_CSRF_ON_REDIRECT

5_3_5_ANTI_CSRF_STATE_PARAM Link the state Parameter to User Agent Session (anti CSRF)

The "state" parameter is used to link client requests and prevent CSRF attacks, for example, attacks against the redirect URI. An attacker could inject their own authorization "code" or access token, which can result in the client using an access token associated with the attacker’s protected resources rather than the victim’s (e.g., save the victim’s bank account information to a protected resource controlled by the attacker). The client should utilize the "state" request parameter to send the authorization server a value that binds the request to the user agent’s authenticated state (e.g., a hash of the session cookie used to authenticate the user agent) when making an authorization request. Once authorization has been obtained from the end user, the authorization server redirects the end-user’s user agent back to the client with the required binding value contained in the "state" parameter. The binding value enables the client to verify the validity of the request by matching the binding value to the user agent’s authenticated state.

Countermeasure in place? ❌ Public and disclosable? ✔ Is operational?✔ (operated by CLIENT_OPERATOR)

USER_EDUCATION Users can be educated to not follow untrusted URLs

Client developers and end users can be educated to not follow untrusted URLs.

Countermeasure in place? ❌ Public and disclosable? ✔ Is operational?✔ (operated by AUTHORIZATION_SERVER_OPERATOR)

Clickjacking Attack against Authorization (4_4_1_9_CLICKJACKING)

Assets (IDs) involved in this threat:

• DF_AUTH_REDIRECT - Auth User Agent Redirection

Threat actors:

• ANONYMOUS

Threat Description

With clickjacking, a malicious site loads the target site in a transparent iFrame (see [iFrame]) overlaid on top of a set of dummy buttons that are carefully constructed to be placed directly under important buttons on the target site. When a user clicks a visible button, they are actually clicking a button (such as an "Authorize" button) on the hidden page.

Impact

An attacker can steal a user’s authentication credentials and access their resources.
CONFIDENTIALITY
NON_REPUDIATION

CVSS

Base score: 8.1 (High)
Vector:CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:N

Counter-measures for 4_4_1_9_CLICKJACKING

5_2_2_6_X_FRAME_OPTION Link the state Parameter to User Agent Session (anti CSRF)

For newer browsers, avoidance of iFrames can be enforced on the server side by using the X-FRAME-OPTIONS header (see [X-Frame-Options]). This header can have two values, "DENY" and "SAMEORIGIN", which will block any framing or any framing by sites with a different origin, respectively. The value "ALLOW-FROM" specifies a list of trusted origins that iFrames may originate from. This is a countermeasure against the following threat:

o Clickjacking attacks

Countermeasure in place? ❌ Public and disclosable? ✔ Is operational?✔ (operated by AUTHORIZATION_SERVER_OPERATOR)

FRAMEBUSTING JavaScript frame-busting

For older browsers, JavaScript frame-busting (see [Framebusting]) techniques can be used but may not be effective in all browsers.

Countermeasure in place? ❌ Public and disclosable? ✔ Is operational?✔ (operated by AUTHORIZATION_SERVER_OPERATOR)

Resource Owner Impersonation (4_4_1_10_RESOURCE_OWNER_SPOOFING1)

Assets (IDs) involved in this threat:

• DF_AUTH_REDIRECT - Auth User Agent Redirection

Threat actors:

• CLIENT_OPERATOR

Threat Description

When a client requests access to protected resources, the authorization flow normally involves the resource owner’s explicit response to the access request, either granting or denying access to the protected resources. A malicious client can exploit knowledge of the structure of this flow in order to gain authorization without the resource owner’s consent, by transmitting the necessary requests programmatically and simulating the flow against the authorization server. That way, the client may gain access to the victim’s resources without her approval. An authorization server will be vulnerable to this threat if it uses non-interactive authentication mechanisms or splits the authorization flow across multiple pages. The malicious client might embed a hidden HTML user agent, interpret the HTML forms sent by the authorization server, and automatically send the corresponding form HTTP POST requests. As a prerequisite, the attacker must be able to execute the authorization process in the context of an already-authenticated session of the resource owner with the authorization server. There are different ways to achieve this:

o The malicious client could abuse an existing session in an external browser or cross-browser cookies on the particular device.

o The malicious client could also request authorization for an initial scope acceptable to the user and then silently abuse the resulting session in his browser instance to "silently" request another scope.

o Alternatively, the attacker might exploit an authorization server’s ability to authenticate the resource owner automatically and without user interactions, e.g., based on certificates. In all cases, such an attack is limited to clients running on the victim’s device, either within the user agent or as a native app. Please note: Such attacks cannot be prevented using CSRF countermeasures, since the attacker just "executes" the URLs as prepared by the authorization server including any nonce, etc.

Impact

CONFIDENTIALITY
NON_REPUDIATION

CVSS

Base score: 8.1 (High)
Vector:CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:N

Counter-measures for 4_4_1_10_RESOURCE_OWNER_SPOOFING1

INTERACTIVE_APPROVAL Interactive (non automatic) user approval

Authorization servers should decide, based on an analysis of the risk associated with this threat, whether to detect and prevent this threat. In order to prevent such an attack, the authorization server may force a user interaction based on non-predictable input values as part of the user consent approval. The authorization server could

o combine password authentication and user consent in a single form,

o make use of CAPTCHAs, or

o use one-time secrets sent out of band to the resource owner (e.g., via text or instant message).

Countermeasure in place? ❌ Public and disclosable? ✔ Is operational?✔ (operated by AUTHORIZATION_SERVER_OPERATOR)

NOTIFY_APPROVAL Notify User's approval

In order to allow the resource owner to detect abuse, the authorization server could notify the resource owner of any approval by appropriate means, e.g., text or instant message, or email.

Countermeasure in place? ❌ Public and disclosable? ✔ Is operational?✔ (operated by AUTHORIZATION_SERVER_OPERATOR)

Resource Owner Impersonation (4_4_1_11_DOS_TOKEN_ENTROPY)

Assets (IDs) involved in this threat:

• DF_AUTH_REDIRECT - Auth User Agent Redirection

Threat actors:

• CLIENT_OPERATOR

Threat Description

If an authorization server includes a nontrivial amount of entropy in authorization "codes" or access tokens (limiting the number of possible codes/tokens) and automatically grants either without user intervention and has no limit on codes or access tokens per user, an attacker could exhaust the pool of authorization "codes" by repeatedly directing the user’s browser to request authorization "codes" or access tokens.

Impact

AVAILABILITY

CVSS

Base score: 6.5 (Medium)
Vector:CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H

Counter-measures for 4_4_1_11_DOS_TOKEN_ENTROPY

AUTH_SERVER_PER_USER_LIMIT Limit access tokens granted per user

The authorization server should consider limiting the number of access tokens granted per user.

Countermeasure in place? ❌ Public and disclosable? ✔ Is operational?✔ (operated by AUTHORIZATION_SERVER_OPERATOR)

AUTH_CODE_HIGH_ENTROPY High entropy codes

The authorization server should include a nontrivial amount of entropy in authorization "codes".

Countermeasure in place? ❌ Public and disclosable? ✔

DoS Using Manufactured Authorization "codes" (4_4_1_12_DOS2)

Assets (IDs) involved in this threat:

• AUTH_SERVER - Authorization server

Threat actors:

• CLIENT_OPERATOR

Threat Description

An attacker who owns a botnet can locate the redirect URIs of clients that listen on HTTP, access them with random authorization "codes", and cause a large number of HTTPS connections to be concentrated onto the authorization server. This can result in a denial-of-service (DoS) attack on the authorization server. This attack can still be effective even when CSRF defense/the "state" parameter (see Section 4.4.1.8) is deployed on the client side. With such a defense, the attacker might need to incur an additional HTTP request to obtain a valid CSRF code/"state" parameter. This apparently cuts down the effectiveness of the attack by a factor of 2. However, if the HTTPS/HTTP cost ratio is higher than 2 (the cost factor is estimated to be around 3.5x at [SSL-Latency]), the attacker still achieves a magnification of resource utilization at the expense of the authorization server.

Impact

There are a few effects that the attacker can accomplish with this OAuth flow that they cannot easily achieve otherwise. 1. Connection laundering: With the clients as the relay between the attacker and the authorization server, the authorization server learns little or no information about the identity of the attacker. Defenses such as rate-limiting on the offending attacker machines are less effective because it is difficult to identify the attacking machines. Although an attacker could also launder its connections through an anonymizing system such as Tor, the effectiveness of that approach depends on the capacity of the anonymizing system. On the other hand, a potentially large number of OAuth clients could be utilized for this attack. 2. Asymmetric resource utilization: The attacker incurs the cost of an HTTP connection and causes an HTTPS connection to be made on the authorization server; the attacker can coordinate the timing of such HTTPS connections across multiple clients relatively easily. Although the attacker could achieve something similar, say, by including an iFrame pointing to the HTTPS URL of the authorization server in an HTTP web page and luring web users to visit that page, timing attacks using such a scheme may be more difficult, as it seems nontrivial to synchronize a large number of users to simultaneously visit a particular site under the attacker’s control.
AVAILABILITY

CVSS

Base score: 5.3 (Medium)
Vector:CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H

Counter-measures for 4_4_1_12_DOS2

Reference to OAuth2.Flows.Flows_AuthCode.4_4_1_8_CSRF_ON_REDIRECT.5_3_5_ANTI_CSRF_STATE_PARAM Link the state Parameter to User Agent Session (anti CSRF)

The "state" parameter is used to link client requests and prevent CSRF attacks, for example, attacks against the redirect URI. An attacker could inject their own authorization "code" or access token, which can result in the client using an access token associated with the attacker’s protected resources rather than the victim’s (e.g., save the victim’s bank account information to a protected resource controlled by the attacker). The client should utilize the "state" request parameter to send the authorization server a value that binds the request to the user agent’s authenticated state (e.g., a hash of the session cookie used to authenticate the user agent) when making an authorization request. Once authorization has been obtained from the end user, the authorization server redirects the end-user’s user agent back to the client with the required binding value contained in the "state" parameter. The binding value enables the client to verify the validity of the request by matching the binding value to the user agent’s authenticated state.

Countermeasure in place? ❌ Public and disclosable? ✔ Is operational?✔ (operated by CLIENT_OPERATOR)

CLIENT_LIMITS_PER_USER Client limits authenticated users codes

If the client authenticates the user, either through a single- sign-on protocol or through local authentication, the client should suspend the access by a user account if the number of invalid authorization "codes" submitted by this user exceeds a certain threshold.

Countermeasure in place? ❌ Public and disclosable? ✔ Is operational?✔ (operated by CLIENT_OPERATOR)

AUTH_RATE_LIMIT Client limits authenticated users codes

The authorization server should send an error response to the client reporting an invalid authorization "code" and rate-limit or disallow connections from clients whose number of invalid requests exceeds a threshold.

Countermeasure in place? ❌ Public and disclosable? ✔ Is operational?✔ (operated by AUTHORIZATION_SERVER_OPERATOR)

DoS Using Manufactured Authorization "codes" (4_4_1_13_CODE_SUBSTITUTION)

Threat actors:

• CLIENT_OPERATOR

Threat Description

An attacker could attempt to log into an application or web site using a victim’s identity. Applications relying on identity data provided by an OAuth protected service API to login users are vulnerable to this threat. This pattern can be found in so-called "social login" scenarios. As a prerequisite, a resource server offers an API to obtain personal information about a user that could be interpreted as having obtained a user identity. In this sense, the client is treating the resource server API as an "identity" API. A client utilizes OAuth to obtain an access token for the identity API. It then queries the identity API for an identifier and uses it to look up its internal user account data (login). The client assumes that, because it was able to obtain information about the user, the user has been authenticated. If the client uses the grant type "code", the attacker needs to gather a valid authorization "code" of the respective victim from the same Identity Provider used by the target client application. The attacker tricks the victim into logging into a malicious app (which may appear to be legitimate to the Identity Provider) using the same Identity Provider as the target application. This results in the Identity Provider’s authorization server issuing an authorizatio "code" for the respective identity API. The malicious app then sends this code to the attacker, which in turn triggers a login process within the target application. The attacker now manipulates the authorization response and substitutes their code (bound to their identity) for the victim’s code. This code is then exchanged by the client for an access token, which in turn is accepted by the identity API, since the audience, with respect to the resource server, is correct. But since the identifier returned by the identity API is determined by the identity in the access token (issued based on the victim’s code), the attacker is logged into the target application under the victim’s identity.

Impact

The attacker gains access to an application and user-specific data within the application.
CONFIDENTIALITY
INTEGRITY
NON_REPUDIATION

CVSS

Base score: 5.4 (Medium)
Vector:CVSS:3.1/AV:N/AC:H/PR:L/UI:R/S:U/C:H/I:L/A:N

Counter-measures for 4_4_1_13_CODE_SUBSTITUTION

IN_REQUEST_CLIENTID Clients indicate their ids in requests

All clients must indicate their client ids with every request to exchange an authorization "code" for an access token. The authorization server must validate whether the particular authorization "code" has been issued to the particular client. If possible, the client shall be authenticated beforehand.

Countermeasure in place? ❌ Public and disclosable? ✔ Is operational?✔ (operated by AUTHORIZATION_SERVER_OPERATOR)

SECURE_USER_LOGIN_PROTOCOL Secure User Login Protocol

Clients should use an appropriate protocol, such as OpenID (cf. [OPENID]) or SAML (cf. [OASIS.sstc-saml-bindings-1.1]) to implement user login. Both support audience restrictions on clients.

Countermeasure in place? ❌ Public and disclosable? ✔ Is operational?✔ (operated by CLIENT_OPERATOR)

Access Token Leak in Transport/Endpoints (4_4_2_1_TOKEN_LEAK1_NETWORK)

Assets (IDs) involved in this threat:

• AUTHORIZATION_GRANT - Authorization Grant

Threat actors:

• ANONYMOUS

Threat Description

This token might be eavesdropped by an attacker. The token is sent from the server to the client via a URI fragment of the redirect URI. If the communication is not secured or the endpoint is not secured, the token could be leaked by parsing the returned URI.

Impact

The attacker would be able to assume the same rights granted by the token.
CONFIDENTIALITY
INTEGRITY

CVSS

Base score: 5.9 (Medium)
Vector:CVSS:3.1/AV:A/AC:H/PR:N/UI:N/S:U/C:H/I:L/A:N

Counter-measures for 4_4_2_1_TOKEN_LEAK1_NETWORK

Reference to OAuth2.AuthorizationServer.4_3_3_CLIENT_CREDENTIALS_DISCLOSURE.5_1_1_CONFIDENTIAL_REQUESTS Ensure Confidentiality of Requests (TLS)

This is applicable to all requests sent from the client to the authorization server or resource server. While OAuth provides a mechanism for verifying the integrity of requests, it provides no guarantee of request confidentiality. Unless further precautions are taken, eavesdroppers will have full access to request content and may be able to mount interception or replay attacks by using the contents of requests, e.g., secrets or tokens. Attacks can be mitigated by using transport-layer mechanisms such as TLS [RFC5246]. A virtual private network (VPN), e.g., based on IPsec VPNs [RFC4301], may be considered as well. Note: This document assumes end-to-end TLS protected connections between the respective protocol entities. Deployments deviating from this assumption by offloading TLS in between (e.g., on the data center edge) must refine this threat model in order to account for the additional (mainly insider) threat this may cause. This is a countermeasure against the following threats:
o Replay of access tokens obtained on the token’s endpoint or the resource server’s endpoint
o Replay of refresh tokens obtained on the token’s endpoint Replay of authorization "codes" obtained on the token’s endpoint (redirect?)
o Replay of user passwords and client secrets

Countermeasure in place? ✔ Public and disclosable? ✔ Is operational?✔ (operated by CLIENT_OPERATOR)

Access Token Leak in Browser History (4_4_2_2_TOKEN_LEAK2_BROWSER_HISTORY)

Assets (IDs) involved in this threat:

• AUTHORIZATION_GRANT - Authorization Grant

Threat actors:

• ANONYMOUS

Threat Description

An attacker could obtain the token from the browser’s history. Note that this means the attacker needs access to the particular device.

Impact

The attacker would be able to assume the same rights granted by the token.
CONFIDENTIALITY
INTEGRITY

CVSS

Base score: 6.1 (Medium)
Vector:CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:L/A:N

Counter-measures for 4_4_2_2_TOKEN_LEAK2_BROWSER_HISTORY

Reference to OAuth2.Flows.Flows_AuthCode.4_4_1_1_AUTH_CODE_DISCLOSURE.5_1_5_3_SHORT_EXPIRY_CODE Use Short Expiration Time

A short expiration time for tokens is a means of protection against the following threats:
o replay
o token leak (a short expiration time will reduce impact)
o online guessing (a short expiration time will reduce the likelihood of success) Note: Short token duration requires more precise clock synchronization between the authorization server and resource server. Furthermore, shorter duration may require more token refreshes (access token) or repeated end-user authorization processes (authorization "code" and refresh token).

Countermeasure in place? ❌ Public and disclosable? ✔ Is operational?✔ (operated by AUTHORIZATION_SERVER_OPERATOR)

NON_CACHEABLE_RESPONSES Make responses non-cacheable.

Make responses non-cacheable.

Countermeasure in place? ❌ Public and disclosable? ✔ Is operational?✔ (operated by AUTHORIZATION_SERVER_OPERATOR)

Malicious Client Obtains Authorization (4_4_2_2_TOKEN_LEAK2_BROWSER_HISTORY)

Assets (IDs) involved in this threat:

• AUTHORIZATION_GRANT - Authorization Grant

Threat actors:

• ANONYMOUS

Threat Description

A malicious client could attempt to obtain a token by fraud.

Impact

The attacker would be able to assume the same rights granted by the token.
CONFIDENTIALITY
INTEGRITY

CVSS

Base score: 7.4 (High)
Vector:CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N

Counter-measures for 4_4_2_2_TOKEN_LEAK2_BROWSER_HISTORY

Reference to OAuth2.Client.Client_Secrets_disclosure.5_2_3_5_VALIDATE_REDIRECT_URI Validate Pre-Registered "redirect_uri"

An authorization server should require all clients to register their "redirect_uri", and the "redirect_uri" should be the full URI as defined in [RFC6749]. The way that this registration is performed is out of scope of this document. As per the core spec, every actual redirect URI sent with the respective "client_id" to the end-user authorization endpoint must match the registered redirect URI. Where it does not match, the authorization server should assume that the inbound GET request has been sent by an attacker and refuse it. Note: The authorization server should not redirect the user agent back to the redirect URI of such an authorization request. Validating the pre-registered "redirect_uri" is a countermeasure against the following threats:

o Authorization "code" leakage through counterfeit web site: allows authorization servers to detect attack attempts after the first redirect to an end-user authorization endpoint (Section 4.4.1.7).

o Open redirector attack via a client redirection endpoint (Section 4.1.5).

o Open redirector phishing attack via an authorization server redirection endpoint (Section 4.2.4).

The underlying assumption of this measure is that an attacker will need to use another redirect URI in order to get access to the authorization "code". Deployments might consider the possibility of an attacker using spoofing attacks to a victim's device to circumvent this security measure.

Note: Pre-registering clients might not scale in some deployments (manual process) or require dynamic client registration (not specified yet). With the lack of dynamic client registration, a pre-registered "redirect_uri" only works for clients bound to certain deployments at development/configuration time. As soon as dynamic resource server discovery is required, the pre-registered "redirect_uri" may no longer be feasible. 5_Validate_redirect_uri

Note: An invalid redirect URI indicates an invalid client, whereas a valid redirect URI does not necessarily indicate a valid client. The level of confidence depends on the client type. For web applications, the level of confidence is high, since the redirect URI refers to the globally unique network endpoint of this application, whose fully qualified domain name (FQDN) is also validated using HTTPS server authentication by the user agent. In contrast, for native clients, the redirect URI typically refers to device local resources, e.g., a custom scheme. So, a malicious client on a particular device can use the valid redirect URI the legitimate client uses on all other devices.

Countermeasure in place? ❌ Public and disclosable? ✔ Is operational?✔ (operated by AUTHORIZATION_SERVER)

Reference to OAuth2.Flows.Flows_AuthCode.4_4_1_4_CLIENT_SPOOFING1.5_2_4_3_VALIDATION_OF_CLIENT_BY_END_USER Validation of Client Properties by End User

In the authorization process, the user is typically asked to approve a client’s request for authorization. This is an important security mechanism by itself because the end user can be involved in the validation of client properties, such as whether the client name known to the authorization server fits the name of the web site or the application the end user is using. This measure is especially helpful in situations where the authorization server is unable to authenticate the client. It is a countermeasure against:
o A malicious application
o A client application masquerading as another client

Countermeasure in place? ❌ Public and disclosable? ✔ Is operational?✔ (operated by RESOURCE_OWNER)

Reference to OAuth2.Flows.Flows_AuthCode.4_4_1_4_CLIENT_SPOOFING1.5_2_4_1_REPEAT_VALIDATE_CLIENT Automatic Processing of Repeated Authorizations Requires Client Validation

Authorization servers should NOT automatically process repeat authorizations where the client is not authenticated through a client secret or some other authentication mechanism such as a signed authentication assertion certificate (Section 5.2.3.7) or validation of a pre-registered redirect URI (Section 5.2.3.5).

Countermeasure in place? ❌ Public and disclosable? ✔ Is operational?✔ (operated by AUTHORIZATION_SERVER_OPERATOR)

Reference to OAuth2.Flows.Flows_AuthCode.4_4_1_4_CLIENT_SPOOFING1.REQUIRE_USER_MANUAL_STEP Automatic Processing of Repeated Authorizations Requires Client Validation

If the authorization server automatically authenticates the end user, it may nevertheless require some user input in order to prevent screen scraping. Examples are CAPTCHAs (Completely Automated Public Turing tests to tell Computers and Humans Apart) or other multi-factor authentication techniques such as random questions, token code generators, etc.

Countermeasure in place? ❌ Public and disclosable? ✔ Is operational?✔ (operated by AUTHORIZATION_SERVER_OPERATOR)

Reference to OAuth2.Flows.Flows_AuthCode.4_4_1_4_CLIENT_SPOOFING1.5_1_5_1_LIMITED_SCOPE_TOKEN Limit Token Scope

The authorization server may decide to reduce or limit the scope associated with a token. The basis of this decision is out of scope; examples are:

o a client-specific policy, e.g., issue only less powerful tokens to public clients,
o a service-specific policy, e.g., it is a very sensitive service,
o a resource-owner-specific setting, or
o combinations of such policies and preferences.

The authorization server may allow different scopes dependent on the grant type. For example, end-user authorization via direct interaction with the end user (authorization "code") might be considered more reliable than direct authorization via grant type "username"/"password". This means will reduce the impact of the following threats:
o token leakage
o token issuance to malicious software
o unintended issuance of powerful tokens with resource owner credentials flow

Countermeasure in place? ❌ Public and disclosable? ✔ Is operational?✔ (operated by AUTHORIZATION_SERVER_OPERATOR)

Manipulation of Scripts (4_4_2_4_MANIPULATION_SCRIPTS)

Assets (IDs) involved in this threat:

• AUTHORIZATION_GRANT - Authorization Grant

Threat actors:

• ANONYMOUS

Threat Description

A hostile party could act as the client web server and replace or modify the actual implementation of the client (script). This could be achieved using DNS or ARP spoofing. This applies to clients implemented within the web browser in a scripting language.

Impact

The attacker could obtain user credential information and assume the full identity of the user.
CONFIDENTIALITY
INTEGRITY

CVSS

Base score: 5.4 (Medium)
Vector:CVSS:3.1/AV:A/AC:H/PR:L/UI:N/S:U/C:H/I:L/A:N

Counter-measures for 4_4_2_4_MANIPULATION_SCRIPTS

Reference to OAuth2.AuthorizationServer.AuthServerPhishing1.5_1_2_AUTH_SERVER_AUTHENTICATION TLS for the authorization server

Authorization servers should consider such attacks when developing services based on OAuth and should require the use of transport- layer security for any requests where the authenticity of the authorization server or of request responses is an issue (see Section 5.1.2).

HTTPS server authentication or similar means can be used to authenticate the identity of a server. The goal is to reliably bind the fully qualified domain name of the server to the public key presented by the server during connection establishment (see [RFC2818]). The client should validate the binding of the server to its domain name. If the server fails to prove that binding, the communication is considered a man-in-the-middle attack. This security measure depends on the certification authorities the client trusts for that purpose. Clients should carefully select those trusted CAs and protect the storage for trusted CA certificates from modifications. This is a countermeasure against the following threats:
o Spoofing
o Proxying
o Phishing by counterfeit servers

Countermeasure in place? ✔ Public and disclosable? ✔ Is operational?✔ (operated by AUTHORIZATION_SERVER)

Reference to OAuth2.AuthorizationServer.4_3_3_CLIENT_CREDENTIALS_DISCLOSURE.5_1_1_CONFIDENTIAL_REQUESTS Ensure Confidentiality of Requests (TLS)

This is applicable to all requests sent from the client to the authorization server or resource server. While OAuth provides a mechanism for verifying the integrity of requests, it provides no guarantee of request confidentiality. Unless further precautions are taken, eavesdroppers will have full access to request content and may be able to mount interception or replay attacks by using the contents of requests, e.g., secrets or tokens. Attacks can be mitigated by using transport-layer mechanisms such as TLS [RFC5246]. A virtual private network (VPN), e.g., based on IPsec VPNs [RFC4301], may be considered as well. Note: This document assumes end-to-end TLS protected connections between the respective protocol entities. Deployments deviating from this assumption by offloading TLS in between (e.g., on the data center edge) must refine this threat model in order to account for the additional (mainly insider) threat this may cause. This is a countermeasure against the following threats:
o Replay of access tokens obtained on the token’s endpoint or the resource server’s endpoint
o Replay of refresh tokens obtained on the token’s endpoint Replay of authorization "codes" obtained on the token’s endpoint (redirect?)
o Replay of user passwords and client secrets

Countermeasure in place? ✔ Public and disclosable? ✔ Is operational?✔ (operated by CLIENT_OPERATOR)

ONE_TIME_PER_USE_SECRET One-time, per-use secrets (e.g., "client_secret")

Introduce one-time, per-use secrets (e.g., "client_secret") values that can only be used by scripts in a small time window once loaded from a server. The intention would be to reduce the effectiveness of copying client-side scripts for re-use in an attacker’s modified code.

Countermeasure in place? ❌ Public and disclosable? ✔ Is operational?✔ (operated by CLIENT_OPERATOR)

CSRF Attack against redirect-uri (4_4_2_5_CSRF_IMPLICIT)

Assets (IDs) involved in this threat:

• AUTHORIZATION_GRANT - Authorization Grant

Threat actors:

• ANONYMOUS

Threat Description

CSRF attacks (see Section 4.4.1.8) also work against the redirect URI used in the implicit grant flow. An attacker could acquire an access token to their own protected resources. He could then construct a redirect URI and embed their access token in that URI. If he can trick the user into following the redirect URI and the client does not have protection against this attack, the user may have the attacker’s access token authorized within their client.

Impact

The user accesses resources on behalf of the attacker. The effective impact depends on the type of resource accessed. For example, the user may upload private items to an attacker’s resources. Or, when using OAuth in 3rd-party login scenarios, the user may associate his client account with the attacker’s identity at the external Identity Provider. In this way, the attacker could easily access the victim’s data at the client by logging in from another device with his credentials at the external Identity Provider.
CONFIDENTIALITY
INTEGRITY

CVSS

Base score: 5.4 (Medium)
Vector:CVSS:3.1/AV:A/AC:H/PR:L/UI:N/S:U/C:H/I:L/A:N

Counter-measures for 4_4_2_5_CSRF_IMPLICIT

STATE_PARAM_VALIDATION Link the authorization request with the redirect URI (state param)

The "state" parameter should be used to link the authorization request with the redirect URI used to deliver the access token. This will ensure that the client is not tricked into completing any redirect callback unless it is linked to an authorization request initiated by the client. The "state" parameter should not be guessable, and the client should be capable of keeping the "state" parameter secret.

Countermeasure in place? ❌ Public and disclosable? ✔ Is operational?✔ (operated by CLIENT_OPERATOR)

Reference to OAuth2.Flows.Flows_AuthCode.4_4_1_8_CSRF_ON_REDIRECT.USER_EDUCATION Users can be educated to not follow untrusted URLs

Client developers and end users can be educated to not follow untrusted URLs.

Countermeasure in place? ❌ Public and disclosable? ✔ Is operational?✔ (operated by AUTHORIZATION_SERVER_OPERATOR)

Token Substitution (OAuth Login) (4_4_2_6_TOKEN_SUBSTITUTION)

Assets (IDs) involved in this threat:

• AUTHORIZATION_GRANT - Authorization Grant

Threat actors:

• ANONYMOUS

Threat Description

An attacker could attempt to log into an application or web site using a victim’s identity. Applications relying on identity data provided by an OAuth protected service API to login users are vulnerable to this threat. This pattern can be found in so-called "social login" scenarios. As a prerequisite, a resource server offers an API to obtain personal information about a user that could be interpreted as having obtained a user identity. In this sense, the client is treating the resource server API as an "identity" API. A client utilizes OAuth to obtain an access token for the identity API. It then queries the identity API for an identifier and uses it to look up its internal user account data (login). The client assumes that, because it was able to obtain information about the user, the user has been authenticated. To succeed, the attacker needs to gather a valid access token of the respective victim from the same Identity Provider used by the target client application. The attacker tricks the victim into logging into a malicious app (which may appear to be legitimate to the Identity Provider) using the same Identity Provider as the target application. This results in the Identity Provider’s authorization server issuing an access token for the respective identity API. The malicious app then sends this access token to the attacker, which in turn triggers a login process within the target application. The attacker now manipulates the authorization response and substitutes their access token (bound to their identity) for the victim’s access token. This token is accepted by the identity API, since the audience, with respect to the resource server, is correct. But since the identifier returned by the identity API is determined by the identity in the access token, the attacker is logged into the target application under the victim’s identity.

Impact

The attacker gains access to an application and user-specific data within the application.
CONFIDENTIALITY
INTEGRITY

CVSS

Base score: 5.4 (Medium)
Vector:CVSS:3.1/AV:N/AC:H/PR:L/UI:R/S:U/C:H/I:L/A:N

Counter-measures for 4_4_2_6_TOKEN_SUBSTITUTION

Reference to OAuth2.Flows.Flows_AuthCode.4_4_1_13_CODE_SUBSTITUTION.SECURE_USER_LOGIN_PROTOCOL Secure User Login Protocol

Clients should use an appropriate protocol, such as OpenID (cf. [OPENID]) or SAML (cf. [OASIS.sstc-saml-bindings-1.1]) to implement user login. Both support audience restrictions on clients.

Countermeasure in place? ❌ Public and disclosable? ✔ Is operational?✔ (operated by CLIENT_OPERATOR)