OAuth 2.0 Threat Model and Security Considerations
RFC 6819
Document | Type | RFC - Informational (January 2013) Errata | |
---|---|---|---|
Authors | Torsten Lodderstedt , Mark McGloin , Phil Hunt | ||
Last updated | 2020-01-31 | ||
RFC stream | Internet Engineering Task Force (IETF) | ||
Formats | |||
Additional resources | Mailing list discussion | ||
IESG | Responsible AD | Stephen Farrell | |
Send notices to | (None) |
RFC 6819
o 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. 4.4.2.5. Threat: CSRF Attack against redirect-uri 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. Countermeasures: o 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. o Client developers and end users can be educated to not follow untrusted URLs. 4.4.2.6. Threat: Token Substitution (OAuth Login) 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. Lodderstedt, et al. Informational [Page 39] RFC 6819 OAuth 2.0 Security January 2013 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. Countermeasures: o 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. 4.4.3. Resource Owner Password Credentials The resource owner password credentials grant type (see [RFC6749], Section 4.3), often used for legacy/migration reasons, allows a client to request an access token using an end-user's user id and password along with its own credential. This grant type has higher risk because it maintains the UID/password anti-pattern. Additionally, because the user does not have control over the authorization process, clients using this grant type are not limited Lodderstedt, et al. Informational [Page 40] RFC 6819 OAuth 2.0 Security January 2013 by scope but instead have potentially the same capabilities as the user themselves. As there is no authorization step, the ability to offer token revocation is bypassed. Because passwords are often used for more than 1 service, this anti-pattern may also put at risk whatever else is accessible with the supplied credential. Additionally, any easily derived equivalent (e.g., joe@example.com and joe@example.net) might easily allow someone to guess that the same password can be used elsewhere. Impact: The resource server can only differentiate scope based on the access token being associated with a particular client. The client could also acquire long-lived tokens and pass them up to an attacker's web service for further abuse. The client, eavesdroppers, or endpoints could eavesdrop the user id and password. Countermeasures: o Except for migration reasons, minimize use of this grant type. o The authorization server should validate the client id associated with the particular refresh token with every refresh request (Section 5.2.2.2). o As per the core OAuth specification, the authorization server must ensure that these transmissions are protected using transport- layer mechanisms such as TLS (see Section 5.1.1). o Rather than encouraging users to use a UID and password, service providers should instead encourage users not to use the same password for multiple services. o Limit use of resource owner password credential grants to scenarios where the client application and the authorizing service are from the same organization. 4.4.3.1. Threat: Accidental Exposure of Passwords at Client Site If the client does not provide enough protection, an attacker or disgruntled employee could retrieve the passwords for a user. Countermeasures: o Use other flows that do not rely on the client's cooperation for secure resource owner credential handling. o Use digest authentication instead of plaintext credential processing. Lodderstedt, et al. Informational [Page 41] RFC 6819 OAuth 2.0 Security January 2013 o Obfuscate passwords in logs. 4.4.3.2. Threat: Client Obtains Scopes without End-User Authorization All interaction with the resource owner is performed by the client. Thus it might, intentionally or unintentionally, happen that the client obtains a token with scope unknown for, or unintended by, the resource owner. For example, the resource owner might think the client needs and acquires read-only access to its media storage only but the client tries to acquire an access token with full access permissions. Countermeasures: o Use other flows that do not rely on the client's cooperation for resource owner interaction. o The authorization server may generally restrict the scope of access tokens (Section 5.1.5.1) issued by this flow. If the particular client is trustworthy and can be authenticated in a reliable way, the authorization server could relax that restriction. Resource owners may prescribe (e.g., in their preferences) what the maximum scope is for clients using this flow. o The authorization server could notify the resource owner by an appropriate medium, e.g., email, of the grant issued (see Section 5.1.3). 4.4.3.3. Threat: Client Obtains Refresh Token through Automatic Authorization All interaction with the resource owner is performed by the client. Thus it might, intentionally or unintentionally, happen that the client obtains a long-term authorization represented by a refresh token even if the resource owner did not intend so. Countermeasures: o Use other flows that do not rely on the client's cooperation for resource owner interaction. o The authorization server may generally refuse to issue refresh tokens in this flow (see Section 5.2.2.1). If the particular client is trustworthy and can be authenticated in a reliable way (see client authentication), the authorization server could relax Lodderstedt, et al. Informational [Page 42] RFC 6819 OAuth 2.0 Security January 2013 that restriction. Resource owners may allow or deny (e.g., in their preferences) the issuing of refresh tokens using this flow as well. o The authorization server could notify the resource owner by an appropriate medium, e.g., email, of the refresh token issued (see Section 5.1.3). 4.4.3.4. Threat: Obtaining User Passwords on Transport An attacker could attempt to eavesdrop the transmission of end-user credentials with the grant type "password" between the client and server. Impact: Disclosure of a single end-user's password. Countermeasures: o Ensure confidentiality of requests (Section 5.1.1). o Use alternative authentication means that do not require the sending of plaintext credentials over the wire (e.g., Hash-based Message Authentication Code). 4.4.3.5. Threat: Obtaining User Passwords from Authorization Server Database An attacker may obtain valid username/password combinations from the authorization server's database by gaining access to the database or launching a SQL injection attack. Impact: Disclosure of all username/password combinations. The impact may exceed the domain of the authorization server, since many users tend to use the same credentials on different services. Countermeasures: o Enforce credential storage protection best practices (Section 5.1.4.1). 4.4.3.6. Threat: Online Guessing An attacker may try to guess valid username/password combinations using the grant type "password". Impact: Revelation of a single username/password combination. Lodderstedt, et al. Informational [Page 43] RFC 6819 OAuth 2.0 Security January 2013 Countermeasures: o Utilize secure password policy (Section 5.1.4.2.1). o Lock accounts (Section 5.1.4.2.3). o Use tar pit (Section 5.1.4.2.4). o Use CAPTCHAs (Section 5.1.4.2.5). o Consider not using the grant type "password". o Client authentication (see Section 5.2.3) will provide another authentication factor and thus hinder the attack. 4.4.4. Client Credentials Client credentials (see [RFC6749], Section 3) consist of an identifier (not secret) combined with an additional means (such as a matching client secret) of authenticating a client. The threats to this grant type are similar to those described in Section 4.4.3. 4.5. Refreshing an Access Token 4.5.1. Threat: Eavesdropping Refresh Tokens from Authorization Server An attacker may eavesdrop refresh tokens when they are transmitted from the authorization server to the client. Countermeasures: o 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). o If end-to-end confidentiality cannot be guaranteed, reducing scope (see Section 5.1.5.1) and expiry time (see Section 5.1.5.3) for issued access tokens can be used to reduce the damage in case of leaks. 4.5.2. Threat: Obtaining Refresh Token from Authorization Server Database This threat is applicable if the authorization server stores refresh tokens as handles in a database. An attacker may obtain refresh tokens from the authorization server's database by gaining access to the database or launching a SQL injection attack. Lodderstedt, et al. Informational [Page 44] RFC 6819 OAuth 2.0 Security January 2013 Impact: Disclosure of all refresh tokens. Countermeasures: o Enforce credential storage protection best practices (Section 5.1.4.1). o Bind token to client id, if the attacker cannot obtain the required id and secret (Section 5.1.5.8). 4.5.3. Threat: Obtaining Refresh Token by Online Guessing An attacker may try to guess valid refresh token values and send it using the grant type "refresh_token" in order to obtain a valid access token. Impact: Exposure of a single refresh token and derivable access tokens. Countermeasures: o For handle-based designs (Section 5.1.4.2.2). o For assertion-based designs (Section 5.1.5.9). o Bind token to client id, because the attacker would guess the matching client id, too (see Section 5.1.5.8). o Authenticate the client; this adds another element that the attacker has to guess (see Section 5.2.3.4). 4.5.4. Threat: Refresh Token Phishing by Counterfeit Authorization Server An attacker could try to obtain valid refresh tokens by proxying requests to the authorization server. Given the assumption that the authorization server URL is well-known at development time or can at least be obtained from a well-known resource server, the attacker must utilize some kind of spoofing in order to succeed. Countermeasures: o Utilize server authentication (as described in Section 5.1.2). Lodderstedt, et al. Informational [Page 45] RFC 6819 OAuth 2.0 Security January 2013 4.6. Accessing Protected Resources 4.6.1. Threat: Eavesdropping Access Tokens on Transport An attacker could try to obtain a valid access token on transport between the client and resource server. As access tokens are shared secrets between the authorization server and resource server, they should be treated with the same care as other credentials (e.g., end- user passwords). Countermeasures: o Access tokens sent as bearer tokens should not be sent in the clear over an insecure channel. As per the core OAuth spec, transmission of access tokens must be protected using transport- layer mechanisms such as TLS (see Section 5.1.1). o A short lifetime reduces impact in case tokens are compromised (see Section 5.1.5.3). o The access token can be bound to a client's identifier and require the client to prove legitimate ownership of the token to the resource server (see Section 5.4.2). 4.6.2. Threat: Replay of Authorized Resource Server Requests An attacker could attempt to replay valid requests in order to obtain or to modify/destroy user data. Countermeasures: o The resource server should utilize transport security measures (e.g., TLS) in order to prevent such attacks (see Section 5.1.1). This would prevent the attacker from capturing valid requests. o Alternatively, the resource server could employ signed requests (see Section 5.4.3) along with nonces and timestamps in order to uniquely identify requests. The resource server should detect and refuse every replayed request. 4.6.3. Threat: Guessing Access Tokens Where the token is a handle, the attacker may attempt to guess the access token values based on knowledge they have from other access tokens. Impact: Access to a single user's data. Lodderstedt, et al. Informational [Page 46] RFC 6819 OAuth 2.0 Security January 2013 Countermeasures: o Handle tokens should have a reasonable level of entropy (see Section 5.1.4.2.2) in order to make guessing a valid token value infeasible. o Assertion (or self-contained token) token contents should be protected by a digital signature (see Section 5.1.5.9). o Security can be further strengthened by using a short access token duration (see Sections 5.1.5.2 and 5.1.5.3). 4.6.4. Threat: Access Token Phishing by Counterfeit Resource Server An attacker may pretend to be a particular resource server and to accept tokens from a particular authorization server. If the client sends a valid access token to this counterfeit resource server, the server in turn may use that token to access other services on behalf of the resource owner. Countermeasures: o Clients should not make authenticated requests with an access token to unfamiliar resource servers, regardless of the presence of a secure channel. If the resource server URL is well-known to the client, it may authenticate the resource servers (see Section 5.1.2). o Associate the endpoint URL of the resource server the client talked to with the access token (e.g., in an audience field) and validate the association at a legitimate resource server. The endpoint URL validation policy may be strict (exact match) or more relaxed (e.g., same host). This would require telling the authorization server about the resource server endpoint URL in the authorization process. o Associate an access token with a client and authenticate the client with resource server requests (typically via a signature, in order to not disclose a secret to a potential attacker). This prevents the attack because the counterfeit server is assumed to lack the capability to correctly authenticate on behalf of the legitimate client to the resource server (Section 5.4.2). o Restrict the token scope (see Section 5.1.5.1) and/or limit the token to a certain resource server (Section 5.1.5.5). Lodderstedt, et al. Informational [Page 47] RFC 6819 OAuth 2.0 Security January 2013 4.6.5. Threat: Abuse of Token by Legitimate Resource Server or Client A legitimate resource server could attempt to use an access token to access another resource server. Similarly, a client could try to use a token obtained for one server on another resource server. Countermeasures: o Tokens should be restricted to particular resource servers (see Section 5.1.5.5). 4.6.6. Threat: Leak of Confidential Data in HTTP Proxies An OAuth HTTP authentication scheme as discussed in [RFC6749] is optional. However, [RFC2616] relies on the Authorization and WWW-Authenticate headers to distinguish authenticated content so that it can be protected. Proxies and caches, in particular, may fail to adequately protect requests not using these headers. For example, private authenticated content may be stored in (and thus be retrievable from) publicly accessible caches. Countermeasures: o Clients and resource servers not using an OAuth HTTP authentication scheme (see Section 5.4.1) should take care to use Cache-Control headers to minimize the risk that authenticated content is not protected. Such clients should send a Cache-Control header containing the "no-store" option [RFC2616]. Resource server success (2XX status) responses to these requests should contain a Cache-Control header with the "private" option [RFC2616]. o Reducing scope (see Section 5.1.5.1) and expiry time (Section 5.1.5.3) for access tokens can be used to reduce the damage in case of leaks. 4.6.7. Threat: Token Leakage via Log Files and HTTP Referrers If access tokens are sent via URI query parameters, such tokens may leak to log files and the HTTP "referer". Countermeasures: o Use Authorization headers or POST parameters instead of URI request parameters (see Section 5.4.1). o Set logging configuration appropriately. Lodderstedt, et al. Informational [Page 48] RFC 6819 OAuth 2.0 Security January 2013 o Prevent unauthorized persons from access to system log files (see Section 5.1.4.1.1). o Abuse of leaked access tokens can be prevented by enforcing authenticated requests (see Section 5.4.2). o The impact of token leakage may be reduced by limiting scope (see Section 5.1.5.1) and duration (see Section 5.1.5.3) and by enforcing one-time token usage (see Section 5.1.5.4). 5. Security Considerations This section describes the countermeasures as recommended to mitigate the threats described in Section 4. 5.1. General This section covers considerations that apply generally across all OAuth components (client, resource server, token server, and user agents). 5.1.1. Ensure Confidentiality of Requests 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 Lodderstedt, et al. Informational [Page 49] RFC 6819 OAuth 2.0 Security January 2013 o Replay of authorization "codes" obtained on the token's endpoint (redirect?) o Replay of user passwords and client secrets 5.1.2. Utilize Server Authentication 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 5.1.3. Always Keep the Resource Owner Informed Transparency to the resource owner is a key element of the OAuth protocol. The user should always be in control of the authorization processes and get the necessary information to make informed decisions. Moreover, user involvement is a further security countermeasure. The user can probably recognize certain kinds of attacks better than the authorization server. Information can be presented/exchanged during the authorization process, after the authorization process, and every time the user wishes to get informed by using techniques such as: o User consent forms. o Notification messages (e.g., email, SMS, ...). Note that notifications can be a phishing vector. Messages should be such that look-alike phishing messages cannot be derived from them. Lodderstedt, et al. Informational [Page 50] RFC 6819 OAuth 2.0 Security January 2013 o Activity/event logs. o User self-care applications or portals. 5.1.4. Credentials This section describes countermeasures used to protect all kinds of credentials from unauthorized access and abuse. Credentials are long-term secrets, such as client secrets and user passwords as well as all kinds of tokens (refresh and access tokens) or authorization "codes". 5.1.4.1. 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. 5.1.4.1.1. 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. 5.1.4.1.2. 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. Lodderstedt, et al. Informational [Page 51] RFC 6819 OAuth 2.0 Security January 2013 5.1.4.1.3. No Cleartext Storage of Credentials The authorization server should not store credentials in clear text. Typical approaches are to store hashes instead or to encrypt credentials. If the credential lacks a reasonable entropy level (because it is a user password), an additional salt will harden the storage to make offline dictionary attacks more difficult. Note: Some authentication protocols require the authorization server to have access to the secret in the clear. Those protocols cannot be implemented if the server only has access to hashes. Credentials should be strongly encrypted in those cases. 5.1.4.1.4. Encryption of Credentials For client applications, insecurely persisted client credentials are easy targets for attackers to obtain. Store client credentials using an encrypted persistence mechanism such as a keystore or database. Note that compiling client credentials directly into client code makes client applications vulnerable to scanning as well as difficult to administer should client credentials change over time. 5.1.4.1.5. Use of Asymmetric Cryptography Usage of asymmetric cryptography will free the authorization server of the obligation to manage credentials. 5.1.4.2. Online Attacks on Secrets 5.1.4.2.1. Utilize Secure Password Policy The authorization server may decide to enforce a complex user password policy in order to increase the user passwords' entropy to hinder online password attacks. Note that too much complexity can increase the likelihood that users re-use passwords or write them down, or otherwise store them insecurely. 5.1.4.2.2. 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. Lodderstedt, et al. Informational [Page 52] RFC 6819 OAuth 2.0 Security January 2013 5.1.4.2.3. 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. 5.1.4.2.4. Use Tar Pit The authorization server may react on failed attempts to authenticate by username/password by temporarily locking the respective account and delaying the response for a certain duration. This duration may increase with the number of failed attempts. The objective is to slow the attacker's attempts on a certain username down. Note: This may require a more complex and stateful design of the authorization server. 5.1.4.2.5. Use CAPTCHAs The idea is to prevent programs from automatically checking a huge number of passwords, by requiring human interaction. Note: This has a negative impact on user experience. 5.1.5. Tokens (Access, Refresh, Code) 5.1.5.1. 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. Lodderstedt, et al. Informational [Page 53] RFC 6819 OAuth 2.0 Security January 2013 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 5.1.5.2. Determine Expiration Time Tokens should generally expire after a reasonable duration. This complements and strengthens other security measures (such as signatures) and reduces the impact of all kinds of token leaks. Depending on the risk associated with token leakage, tokens may expire after a few minutes (e.g., for payment transactions) or stay valid for hours (e.g., read access to contacts). The expiration time is determined by several factors, including: o risk associated with token leakage, o duration of the underlying access grant, o duration until the modification of an access grant should take effect, and o time required for an attacker to guess or produce a valid token. 5.1.5.3. 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) Lodderstedt, et al. Informational [Page 54] RFC 6819 OAuth 2.0 Security January 2013 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). 5.1.5.4. 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. 5.1.5.5. Bind Tokens to a Particular Resource Server (Audience) Authorization servers in multi-service environments may consider issuing tokens with different content to different resource servers and to explicitly indicate in the token the target server to which a token is intended to be sent. SAML assertions (see [OASIS.saml-core-2.0-os]) use the Audience element for this purpose. This countermeasure can be used in the following situations: o It reduces the impact of a successful replay attempt, since the token is applicable to a single resource server only. o It prevents abuse of a token by a rogue resource server or client, since the token can only be used on that server. It is rejected by other servers. o It reduces the impact of leakage of a valid token to a counterfeit resource server. Lodderstedt, et al. Informational [Page 55] RFC 6819 OAuth 2.0 Security January 2013 5.1.5.6. Use Endpoint Address as Token Audience This may be used to indicate to a resource server which endpoint URL has been used to obtain the token. This measure will allow the detection of requests from a counterfeit resource server, since such a token will contain the endpoint URL of that server. 5.1.5.7. Use Explicitly Defined Scopes for Audience and Tokens Deployments may consider only using tokens with explicitly defined scopes, where every scope is associated with a particular resource server. This approach can be used to mitigate attacks where a resource server or client uses a token for a different purpose than the one intended. 5.1.5.8. Bind Token to Client id An authorization server may bind a token to a certain client identifier. This identifier should be validated for every request with that token. This technique can be used to o detect token leakage and o prevent token abuse. Note: Validating the client identifier may require the target server to authenticate the client's identifier. This authentication can be based on secrets managed independently of the token (e.g., pre-registered client id/secret on authorization server) or sent with the token itself (e.g., as part of the encrypted token content). 5.1.5.9. 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). 5.1.5.10. Encrypt Token Content Self-contained tokens may be encrypted for confidentiality reasons or to protect system internal data. Depending on token format, keys (e.g., symmetric keys) may have to be distributed between server nodes. The method of distribution should be defined by the token and the encryption used. Lodderstedt, et al. Informational [Page 56] RFC 6819 OAuth 2.0 Security January 2013 5.1.5.11. Adopt a Standard Assertion Format For service providers intending to implement an assertion-based token design, it is highly recommended to adopt a standard assertion format (such as SAML [OASIS.saml-core-2.0-os] or the JavaScript Object Notation Web Token (JWT) [OAuth-JWT]). 5.1.6. Access Tokens The following measures should be used to protect access tokens: o Keep them in transient memory (accessible by the client application only). o Pass tokens securely using secure transport (TLS). o Ensure that client applications do not share tokens with 3rd parties. 5.2. Authorization Server This section describes considerations related to the OAuth authorization server endpoint. 5.2.1. Authorization "codes" 5.2.1.1. 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. 5.2.2. Refresh Tokens 5.2.2.1. Restricted Issuance of Refresh Tokens The authorization server may decide, based on an appropriate policy, not to issue refresh tokens. Since refresh tokens are long-term credentials, they may be subject to theft. For example, if the authorization server does not trust a client to securely store such tokens, it may refuse to issue such a client a refresh token. Lodderstedt, et al. Informational [Page 57] RFC 6819 OAuth 2.0 Security January 2013 5.2.2.2. Binding of Refresh Token to "client_id" The authorization server should match every refresh token to the identifier of the client to whom it was issued. The authorization server should check that the same "client_id" is present for every request to refresh the access token. If possible (e.g., confidential clients), the authorization server should authenticate the respective client. This is a countermeasure against refresh token theft or leakage. Note: This binding should be protected from unauthorized modifications. 5.2.2.3. Refresh Token Rotation Refresh token rotation is intended to automatically detect and prevent attempts to use the same refresh token in parallel from different apps/devices. This happens if a token gets stolen from the client and is subsequently used by both the attacker and the legitimate client. The basic idea is to change the refresh token value with every refresh request in order to detect attempts to obtain access tokens using old refresh tokens. Since the authorization server cannot determine whether the attacker or the legitimate client is trying to access, in case of such an access attempt the valid refresh token and the access authorization associated with it are both revoked. The OAuth specification supports this measure in that the token's response allows the authorization server to return a new refresh token even for requests with grant type "refresh_token". Note: This measure may cause problems in clustered environments, since usage of the currently valid refresh token must be ensured. In such an environment, other measures might be more appropriate. 5.2.2.4. Revocation of Refresh Tokens The authorization server may allow clients or end users to explicitly request the invalidation of refresh tokens. A mechanism to revoke tokens is specified in [OAuth-REVOCATION]. Lodderstedt, et al. Informational [Page 58] RFC 6819 OAuth 2.0 Security January 2013 This is a countermeasure against: o device theft, o impersonation of a resource owner, or o suspected compromised client applications. 5.2.2.5. Device Identification The authorization server may require the binding of authentication credentials to a device identifier. The International Mobile Station Equipment Identity [IMEI] is one example of such an identifier; there are also operating system-specific identifiers. The authorization server could include such an identifier when authenticating user credentials in order to detect token theft from a particular device. Note: Any implementation should consider potential privacy implications of using device identifiers. 5.2.2.6. X-FRAME-OPTIONS Header 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 5.2.3. Client Authentication and Authorization As described in Section 3 (Security Features), clients are identified, authenticated, and authorized for several purposes, such as to: o Collate requests to the same client, o Indicate to the user that the client is recognized by the authorization server, o Authorize access of clients to certain features on the authorization server or resource server, and o Log a client identifier to log files for analysis or statistics. Lodderstedt, et al. Informational [Page 59] RFC 6819 OAuth 2.0 Security January 2013 Due to the different capabilities and characteristics of the different client types, there are different ways to support these objectives, which will be described in this section. Authorization server providers should be aware of the security policy and deployment of a particular client and adapt its treatment accordingly. For example, one approach could be to treat all clients as less trustworthy and unsecure. On the other extreme, a service provider could activate every client installation individually by an administrator and in that way gain confidence in the identity of the software package and the security of the environment in which the client is installed. There are several approaches in between. 5.2.3.1. Don't Issue Secrets to Clients with Inappropriate Security Policy Authorization servers should not issue secrets to clients that cannot protect secrets ("public" clients). This reduces the probability of the server treating the client as strongly authenticated. For example, it is of limited benefit to create a single client id and secret that are shared by all installations of a native application. Such a scenario requires that this secret must be transmitted from the developer via the respective distribution channel, e.g., an application market, to all installations of the application on end-user devices. A secret, burned into the source code of the application or an associated resource bundle, is not protected from reverse engineering. Secondly, such secrets cannot be revoked, since this would immediately put all installations out of work. Moreover, since the authorization server cannot really trust the client's identifier, it would be dangerous to indicate to end users the trustworthiness of the client. There are other ways to achieve a reasonable security level, as described in the following sections. 5.2.3.2. 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: o Impersonation of public client applications. Lodderstedt, et al. Informational [Page 60] RFC 6819 OAuth 2.0 Security January 2013 5.2.3.3. 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: o Cross-site scripting attacks o Impersonation of public client applications 5.2.3.4. 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 Lodderstedt, et al. Informational [Page 61] RFC 6819 OAuth 2.0 Security January 2013 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. 5.2.3.5. 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. Lodderstedt, et al. Informational [Page 62] RFC 6819 OAuth 2.0 Security January 2013 5.2.3.6. Revoke Client Secrets An authorization server may revoke a client's secret in order to prevent abuse of a revealed secret. Note: This measure will immediately invalidate any authorization "code" or refresh token issued to the respective client. This might unintentionally impact client identifiers and secrets used across multiple deployments of a particular native or web application. This a countermeasure against: o Abuse of revealed client secrets for private clients 5.2.3.7. Use Strong Client Authentication (e.g., client_assertion/ client_token) 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. 5.2.4. End-User Authorization This section includes considerations for authorization flows involving the end user. 5.2.4.1. 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). 5.2.4.2. Informed Decisions Based on Transparency The authorization server should clearly explain to the end user what happens in the authorization process and what the consequences are. For example, the user should understand what access he is about to grant to which client for what duration. It should also be obvious to the user whether the server is able to reliably certify certain client properties (web site URL, security policy). Lodderstedt, et al. Informational [Page 63] RFC 6819 OAuth 2.0 Security January 2013 5.2.4.3. 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 5.2.4.4. 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). 5.2.4.5. 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. Lodderstedt, et al. Informational [Page 64] RFC 6819 OAuth 2.0 Security January 2013 5.3. Client App Security This section deals with considerations for client applications. 5.3.1. Don't Store Credentials in Code or Resources Bundled with Software Packages Because of the number of copies of client software, there is limited benefit in creating a single client id and secret that is shared by all installations of an application. Such an application by itself would be considered a "public" client, as it cannot be presumed to be able to keep client secrets. A secret, burned into the source code of the application or an associated resource bundle, cannot be protected from reverse engineering. Secondly, such secrets cannot be revoked, since this would immediately put all installations out of work. Moreover, since the authorization server cannot really trust the client's identifier, it would be dangerous to indicate to end users the trustworthiness of the client. 5.3.2. Use Standard Web Server Protection Measures (for Config Files and Databases) Use standard web server protection and configuration measures to protect the integrity of the server, databases, configuration files, and other operational components of the server. 5.3.3. Store Secrets in Secure Storage There are different ways to store secrets of all kinds (tokens, client secrets) securely on a device or server. Most multi-user operating systems segregate the personal storage of different system users. Moreover, most modern smartphone operating systems even support the storage of application-specific data in separate areas of file systems and protect the data from access by other applications. Additionally, applications can implement confidential data by using a user-supplied secret, such as a PIN or password. Another option is to swap refresh token storage to a trusted backend server. This option in turn requires a resilient authentication mechanism between the client and backend server. Note: Applications should ensure that confidential data is kept confidential even after reading from secure storage, which typically means keeping this data in the local memory of the application. Lodderstedt, et al. Informational [Page 65] RFC 6819 OAuth 2.0 Security January 2013 5.3.4. Utilize Device Lock to Prevent Unauthorized Device Access On a typical modern phone, there are many "device lock" options that can be utilized to provide additional protection when a device is stolen or misplaced. These include PINs, passwords, and other biometric features such as "face recognition". These are not equal in the level of security they provide. 5.3.5. Link the "state" Parameter to User Agent Session 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. 5.4. Resource Servers The following section details security considerations for resource servers. 5.4.1. Authorization Headers Authorization headers are recognized and specially treated by HTTP proxies and servers. Thus, the usage of such headers for sending access tokens to resource servers reduces the likelihood of leakage or unintended storage of authenticated requests in general, and especially Authorization headers. Lodderstedt, et al. Informational [Page 66] RFC 6819 OAuth 2.0 Security January 2013 5.4.2. Authenticated Requests An authorization server may bind tokens to a certain client identifier and enable resource servers to validate that association on resource access. This will require the resource server to authenticate the originator of a request as the legitimate owner of a particular token. There are several options to implement this countermeasure: o The authorization server may associate the client identifier with the token (either internally or in the payload of a self-contained token). The client then uses client certificate-based HTTP authentication on the resource server's endpoint to authenticate its identity, and the resource server validates the name with the name referenced by the token. o Same as the option above, but the client uses his private key to sign the request to the resource server (the public key is either contained in the token or sent along with the request). o Alternatively, the authorization server may issue a token-bound key, which the client uses in a Holder-of-Key proof to authenticate the client's use of the token. The resource server obtains the secret directly from the authorization server, or the secret is contained in an encrypted section of the token. In that way, the resource server does not "know" the client but is able to validate whether the authorization server issued the token to that client. Authenticated requests are a countermeasure against abuse of tokens by counterfeit resource servers. 5.4.3. Signed Requests A resource server may decide to accept signed requests only, either to replace transport-level security measures or to complement such measures. Every signed request should be uniquely identifiable and should not be processed twice by the resource server. This countermeasure helps to mitigate: o modifications of the message and o replay attempts Lodderstedt, et al. Informational [Page 67] RFC 6819 OAuth 2.0 Security January 2013 5.5. A Word on User Interaction and User-Installed Apps OAuth, as a security protocol, is distinctive in that its flow usually involves significant user interaction, making the end user a part of the security model. This creates some important difficulties in defending against some of the threats discussed above. Some of these points have already been made, but it's worth repeating and highlighting them here. o End users must understand what they are being asked to approve (see Section 5.2.4.2). Users often do not have the expertise to understand the ramifications of saying "yes" to an authorization request and are likely not to be able to see subtle differences in the wording of requests. Malicious software can confuse the user, tricking the user into approving almost anything. o End-user devices are prone to software compromise. This has been a long-standing problem, with frequent attacks on web browsers and other parts of the user's system. But with the increasing popularity of user-installed "apps", the threat posed by compromised or malicious end-user software is very strong and is one that is very difficult to mitigate. o Be aware that users will demand to install and run such apps, and that compromised or malicious ones can steal credentials at many points in the data flow. They can intercept the very user login credentials that OAuth is designed to protect. They can request authorization far beyond what they have led the user to understand and approve. They can automate a response on behalf of the user, hiding the whole process. No solution is offered here, because none is known; this remains in the space between better security and better usability. o Addressing these issues by restricting the use of user-installed software may be practical in some limited environments and can be used as a countermeasure in those cases. Such restrictions are not practical in the general case, and mechanisms for after-the- fact recovery should be in place. o While end users are mostly incapable of properly vetting applications they load onto their devices, those who deploy authorization servers might have tools at their disposal to mitigate malicious clients. For example, a well-run authorization server must only assert client properties to the end user it is effectively capable of validating, explicitly point out which properties it cannot validate, and indicate to the end user the risk associated with granting access to the particular client. Lodderstedt, et al. Informational [Page 68] RFC 6819 OAuth 2.0 Security January 2013 6. Acknowledgements We would like to thank Stephen Farrell, Barry Leiba, Hui-Lan Lu, Francisco Corella, Peifung E. Lam, Shane B. Weeden, Skylar Woodward, Niv Steingarten, Tim Bray, and James H. Manger for their comments and contributions. 7. References 7.1. Normative References [RFC6749] Hardt, D., "The OAuth 2.0 Authorization Framework", RFC 6749, October 2012. [RFC6750] Jones, M. and D. Hardt, "The OAuth 2.0 Authorization Framework: Bearer Token Usage", RFC 6750, October 2012. 7.2. Informative References [Framebusting] Rydstedt, G., Bursztein, Boneh, D., and C. Jackson, "Busting Frame Busting: a Study of Clickjacking Vulnerabilities on Popular Sites", IEEE 3rd Web 2.0 Security and Privacy Workshop, May 2010, <http://elie.im/ publication/busting-frame-busting-a-study-of- clickjacking-vulnerabilities-on-popular-sites>. [IMEI] 3GPP, "International Mobile station Equipment Identities (IMEI)", 3GPP TS 22.016 11.0.0, September 2012, <http://www.3gpp.org/ftp/Specs/html-info/22016.htm>. [OASIS.saml-core-2.0-os] Cantor, S., Ed., Kemp, J., Ed., Philpott, R., Ed., and E. Maler, Ed., "Assertions and Protocols for the OASIS Security Assertion Markup Language (SAML) V2.0", OASIS Standard saml-core-2.0-os, March 2005, <http://docs.oasis-open.org/security/saml/ v2.0/saml-core-2.0-os.pdf>. [OASIS.sstc-saml-bindings-1.1] Maler, E., Ed., Mishra, P., Ed., and R. Philpott, Ed., "Bindings and Profiles for the OASIS Security Assertion Markup Language (SAML) V1.1", September 2003, <http://www.oasis-open.org/committees/download.php/3405/ oasis-sstc-saml-bindings-1.1.pdf>. Lodderstedt, et al. Informational [Page 69] RFC 6819 OAuth 2.0 Security January 2013 [OASIS.sstc-sec-analysis-response-01] Linn, J., Ed., and P. Mishra, Ed., "SSTC Response to "Security Analysis of the SAML Single Sign-on Browser/ Artifact Profile"", January 2005, <http://www.oasis-open.org/committees/download.php/ 11191/sstc-gross-sec-analysis-response-01.pdf>. [OAuth-ASSERTIONS] Campbell, B., Mortimore, C., Jones, M., and Y. Goland, "Assertion Framework for OAuth 2.0", Work in Progress, December 2012. [OAuth-HTTP-MAC] Richer, J., Ed., Mills, W., Ed., and H. Tschofenig, Ed., "OAuth 2.0 Message Authentication Code (MAC) Tokens", Work in Progress, November 2012. [OAuth-JWT] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token (JWT)", Work in Progress, December 2012. [OAuth-REVOCATION] Lodderstedt, T., Ed., Dronia, S., and M. Scurtescu, "Token Revocation", Work in Progress, November 2012. [OPENID] "OpenID Foundation Home Page", <http://openid.net/>. [OWASP] "Open Web Application Security Project Home Page", <https://www.owasp.org/>. [Portable-Contacts] Smarr, J., "Portable Contacts 1.0 Draft C", August 2008, <http://portablecontacts.net/>. [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005. [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The Kerberos Network Authentication Service (V5)", RFC 4120, July 2005. Lodderstedt, et al. Informational [Page 70] RFC 6819 OAuth 2.0 Security January 2013 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005. [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008. [SSL-Latency] Sissel, J., Ed., "SSL handshake latency and HTTPS optimizations", June 2010. [Sec-Analysis] Gross, T., "Security Analysis of the SAML Single Sign-on Browser/Artifact Profile", 19th Annual Computer Security Applications Conference, Las Vegas, December 2003. [X-Frame-Options] Ross, D. and T. Gondrom, "HTTP Header X-Frame-Options", Work in Progress, October 2012. [iFrame] World Wide Web Consortium, "Frames in HTML documents", W3C HTML 4.01, December 1999, <http://www.w3.org/TR/html4/present/frames.html#h-16.5>. Authors' Addresses Torsten Lodderstedt (editor) Deutsche Telekom AG EMail: torsten@lodderstedt.net Mark McGloin IBM EMail: mark.mcgloin@ie.ibm.com Phil Hunt Oracle Corporation EMail: phil.hunt@yahoo.com Lodderstedt, et al. Informational [Page 71]