| Open Authentication Protocol | T. Lodderstedt, Ed. |
| Internet-Draft | Deutsche Telekom AG |
| Intended status: Standards Track | M. McGloin |
| Expires: August 24, 2011 | IBM |
| P. Hunt | |
| Oracle Corporation | |
| February 20, 2011 |
OAuth 2.0 Threat Model and Security Considerations
draft-lodderstedt-oauth-security-00
This document gives security considerations based on a comprehensive threat model for the OAuth 2.0 Protocol.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on August 24, 2011.
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
This document gives security considerations based on a comprehensive threat model for the OAuth 2.0 Protocol [I-D.ietf-oauth-v2]. It contains the following content:
Threats include any intentional attacks on OAuth tokens and resources protected by OAuth tokens as well as security risks introduced if the proper security measures are not put in place. Threats are structured along the lines of the protocol structure to aid development teams implement each part of the protocol securely. For example all threats for granting access or all threats for a particular client profile or all threats for protecting the resource server.
The security considerations document only considers clients bound to a particular deployment as supported by [I-D.ietf-oauth-v2]. Such deployments have the following characteristics:
The following are considered out of scope :
The following assumptions relate to an attacker and resources available to an attacker:
This section documents the assumptions about the features, limitations and design options of the different entities of a OAuth deployment along with the security-sensitive data-elements managed by those entity. These assumptions are the foundation of the treat analysis.
The OAuth protocol leaves deployments with a certain degree of freedom how to implement and apply the standard. The core specification defines the core concepts of an authorization server and an resource server. Both servers can be implemented in the same server entity, or they may also be different entities. The later is typically the case for multi-service providers with a single authentication and authorization system, and are more typical in middleware architectures.
The following data elements MAY be stored or accessible on the authorization server:
The following data elements MAY be stored or accessible on the authorization server:
It is assumed that a resource server has no knowledge of refresh tokens, user passwords, or client secrets.
The following data elements are stored or accessible on the authorization server:
Such clients typically represent a web site with its own user management and login mechanism and have the following characteristics:
Such clients are implemented using the authorization code flow (see
This class of OAuth clients represent apps running on a user-controlled device, such as a notebook, PC, Tablet, Smartphone, or Gaming Console.
Massively distributed applications such as these cannot reliably keep secrets confidential, which are issued per software package. This is because such secrets would need to be transferred to the user device as part of the installation process. An attacker could reverse engineer any secret from the binary or accompanying resources. Native Applications are able to protect per installation/instance secrets (e.g. refresh tokens) to some extent.
Device platforms typically allow users to lock the device with a pin and to segregate different apps or users (multi-user operation systems).
Some devices can be identified/authenticated (to varying degrees of assurance):
Mobile devices, such as handsets or smart phones have the following special characteristics:
For the purposes of this document, the scenario of attackers who control a smartphone device entirely is out of scope.
There are several implementation options for native applications:
Different threats exists for those implementation options, which are discussed in the respective sections of the threat model.
[TBD]
Such client are implemented using the implicite grant flow (Section 4.4.2).
Autonomous clients access service providers using rights grants by client credentials only. Thus the autonomous client becomes the „user“. Authenticating autonomous clients is conceptually similar to end-user authentication since the issued tokens refer to the client's identity. Autonomous clients shall always be required to use a secret or some other form of authentication (e.g. client assertion in the form of a SAML assertion or STS token) acceptable to the authorization/token services. The client must ensure the confidentiality of client_secret or other credential.
These are some of the security features which have been built into the OAuth 2.0 protocol to mitigate attacks and security issues.
OAuth makes extensive use of tokens. Tokens can be implemented in 2 ways as follows:
Tokens can be sent to resource server in two ways:
A Scope represents the access authorization associated with a particular token with respect to resource servers, resources and methods on those resources. Scopes are the OAuth way to explicitly manage the power associated with an access token. A scope can be controlled by the authorization server and/or the end-user in order to limit access to resources for OAuth clients these parties deem less secure or trustworthy. Optionally, the client can request the scope to apply to the token but only for lesser scope than would otherwise be granted, e.g. to reduce the potential impact if this token is sent over non secure channels. A scope is typically complemented by a restriction on a token's lifetime.
Expires_In allows an authorization server (based on its policies or on behalf of the end-user) to limit the lifetime of the access token. This mechanisms can be used to issue short-living tokens to OAuth clients the authorization server deems less secure or where sending tokens over non secure channels.
An Authorization Code represents the intermediary result of a successful end-user authorization process and is used by the client to obtain access and refresh token. Authorization codes are sent to the client's redirect_uri instead of tokens for two purposes.
A Redirect-uri helps to identify clients and prevents phishing attacks from other clients attempting to trick the user into believing the phisher is the client. The redirect URI is pre-registered as requests with authorization code or token will be directed to that URI. Moreover, the value of the actual redirect_uri has to be presented and is verified when an authorization code is exchanged for tokens. This helps to prevent session fixation attacks.
An Access Token is used by a client to access a resource. An access token must be acquired using a HTTP POST operation to ensure no logging or caching of requests. Access tokens typically have short life-spans (minutes or hours) that cover typical session lifetimes. An access token may be refreshed through the use of a Refresh Token.
The short lifespan of an access token enables the possibility of revocation by requiring the client to refresh their access token at regular intervals.
A Refresh Token is coupled with a short access token lifetime, can be used to grant longer access to resources without involving end user authorization. This offers an advantage where resource servers and authorization servers are not the same entity, e.g. in a distributed environment, as the refresh token must always be exchanged at the authorization server. The authorization server can revoke the refresh token at any time causing the granted access to be revoked once the current access token expires. Because of this, a short access token lifetime is important if timely revocation is a high priority.
Authentication protocols have typically not taken into account the identity of the software component acting on behalf of the end-user. OAuth does this in order to increase security level in delegated authorization scenarios and because the client will be able to act without the user's presence. By authenticating a client when requesting an access token, the token service is able to assess whether a given client and authorization code meets appropriate security requirements and binds the authorization code approved by the user to the client making the request.
OAuth uses the client_id to collate associated request to the same originator, such as
The client identity may also be used by the authorization server to display relevant registration information to a user when requesting consent for scope requested by a particular client. The client identity may be used to limit the number of request for a particular client or to charge the client per request. Client Identity may furthermore be useful to differentiate (e.g. in server log files) between accesses by end-user, and delegated accesses by client on behalf of a user.
The client_secret is used to verify the client identifier. This should only be used where the client is capable of keeping its secret confidential. The client identity can also be verified using the redirect_uri or by the end-user.
Clients (and the trustworthiness of its identity) can be classifed by using the following parameters:
Typical client categories are:
Use of the client secret is considered a relatively weak form of credential for the client. Use of stronger mechanisms such as a client assertion (e.g. SAML), key cryptography, are preferred.
This sections gives a comprehensive threat model of OAuth 2.0. Threats are grouped first by attackes directed against an OAuth component, which are client, authorization server, and resource server. Subsequently, they are grouped by flow, e.g. obtain token or access protected resources. Every countermeasure description refers to a detailed description in Section 5.
This section describes possible threats directed to OAuth clients.
The attacker could try to get access to the secret of a particular client in order to:
The resulting impact would be:
Depending on the client category, there are the following approaches an attacker could utilize to obtain the client secret.
Attack: Obtain Secret From Source Code or Binary. This applies for all client profiles and especially for open source projects, where the source code is public accessible. Even if the attacker does not has access to the source code, it could reverse engineer secrets from the binary of native apps.
Countermeasures:
Attack: Obtain a Deployment-Specific Secret. An attacker may try to obtain the secret from a client installation, either from a web site (web server) or a particular devices (native app).
Countermeasures:
Depending on the client type, there are different ways refresh tokens may be revealed to an attacker. The following sub-sections give a more detailed description of the different attacks with respect to different client types and further specialized countermeasures. Some generally applicable countermeasure to mitigate such attacks shall be given in advance:
Attack: Obtain Refresh Token from Web application. An attack may obtain the refresh tokens issued to a web server client. Impact: Exposure of all refresh tokens on that side.
Countermeasures:
Attack: Obtain Refresh Token from Native clients. On native clients, leakage of a refresh token typically affects a single user, only.
Read from local filesystem: The attacker could try get file system access on the device and read the refresh tokens. The attacker could utilize a malicious app for that purpose.
Countermeasures:
Steal device: The host device (e.g. mobile phone) may be stolen. In that case, the attacker gets access to all apps under the identity of the legitimate user.
Countermeasures:
Clone device: All device data and applications are copied to another device. Applications are used as-is on the target device.
Countermeasures:
Obtain refresh tokens from backup: A refresh token could be obtained from the backup of a client application, or device.
Countermeasures:
Depending on the client type, there are different ways access tokens may be revealed to an attacker. Access tokens could be stolen from the device if the app stores them in a storage, which is accessible to other applications.
Impact: Where the token is a bearer token and no additional mechanism is used to identify the client, the attacker can access all resources associated with the token and its.
Countermeasures:
A malicious app could attempt to phish end-user passwords by misusing an embedded browser in the end-user authorization process, or by presenting its own user-interface instead of allowing trusted system browser to render the authorization UI. By doing so, the usual visual trust mechanisms may be bypassed (e.g. TLS confirmation, web site mechanisms). By using an embedded or internal client app UI, the client app has access to additional information it should not have access to (e.g. uid/password).
Impact: If the client app or the communication is compromised, the user would not be aware and all information in the authorization exchange could be captured such as username and password.
Countermeasures:
OAuth makes no attempt to verify the authenticity of the Authorization Server. 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 ARP spoofing. Wide deployment of OAuth and similar protocols may cause Users to become inured to the practice of being redirected to websites where they are asked to enter their passwords. If Users are not careful to verify the authenticity of these websites before entering their credentials, it will be possible for attackers to exploit this practice to steal Users' passwords.
Countermeasures:
When obtaining end user authenticaton, 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 which should not be permitted.
Countermeasures:
Authorization servers may wish to automatically process authorization requests from Clients which 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 Provider.
A malicious client may exploit that feature and try to obtain such an authorization code instead of the legimate client.
Countermeasures:
An attacker could use the end-user authorization endpoint and the redirect_uri parameter to abuse the authorization server as redirector.
Impact?
Countermeasure
The OAuth specification does not describe any mechanism for protecting Tokens from eavesdroppers when they are transmitted from the Service Provider to the Client.
Countermeasures:
This threat is applicable if the authorization server stores access tokens as handles in a database. An attacker may obtain access tokens from the authorization server's database by gaining access to the database or launching a SQL injection attack. Impact: disclosure of all access tokens
Countermeasures:
An attacker could attempt to eavesdrop the transmission of client credentials between client and server during the client authentication process or during Oauth token requests. Impact: Revelation of a client credential enabling the possibility for phishing or immitation of a client service.
Countermeasures:
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.
Countermeasures:
An attacker may try to guess valid client_id/secret pairs. Impact: disclosure of single client_id/secret pair.
Countermeasures:
If a Service Provider includes a nontrivial amount of entropy in client secrets and if the service provider automatically grants them, an attacker could exhaust the pool by repeatedly applying for them.
Countermeasures:
This section covers threats which are specific to certain flows utilized to obtain access tokens. Each flow is characterized by response types and/or grant types on the end-user authorization and tokens endpoint, respectively.
Attacker abuses valid client id
countermeasures
The OAuth specification does not describe any mechanism for protecting authorization codes from eavesdroppers when they are transmitted from the Service Provider to the Client and where the Service Provider Grants an Access Token.
Note: A description of a similar attack on the SAML protocol can be found at http://www.oasis-open.org/committees/download.php/3405/oasis-sstc-saml-bindings-1.1.pdf (§4.1.1.9.1).
Countermeasures:
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.
Countermeasures:
An attacker may try to guess valid authorization code values and send it using the grant type „code“ in order to obtain a valid access token. Impact: disclosure of single access token (+probably refresh token)
Countermeasures:
Authorization codes are passed via the browser which may unintentionally leak those codes to untrusted web sites and attackers by different ways:
Similar attacks on the SAML protocol are discussed in: http://www.thomasgross.net/publications/papers/GroPfi2006-SAML2_Analysis_Janus.WSSS_06.pdf and http://www.oasis-open.org/committees/download.php/11191/sstc-gross-sec-analysis-response-01.pdf.
Countermeasures:
A hostile party could act as the client web server and get access to the authorization code. This could be achieved using DNS or ARP spoofing. Impact: This affects web applications and may lead to a disclosure of authorization codes and, potentially, the corresponding access and refresh tokens.
Countermeasures:
The session fixation attack leverages the 3-legged OAuth flow in an attempt to get another user to log-in and authorize access on behalf of the attacker. 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.
In this attack, the attacker is using a known client application (consumer site), and a target OAuth resource provider. The attack depends on the victim expecting the consumer site to request access to the resource provider.
The attacker utilizes the following flow:
The attacker initiates browser access to the consumer site, and initates access to data from the resource provider. The consumer site, initiates an authorization request and receives a redirect_uri back from the resource provider's authorization server. Instead of following the link, the attacker stops the process and saves the redirect_uri. The attacker modifies the redirect_uri to allow control to be returned to the attacker site.
The attacker tricks another user (the victim) to open that redirect_uri and to authorize access (e.g. an email link, or blog link). The way the attacker achieve that goal is out of scope.
Having clicked, the link, the victim is requested to authenticate and authorize the consumer site to have access.
The authorization server redirects the user agent to the attackers web site instead of the original target web site.
The attacker obtains the authorization code from its web site, constructs a redirect_uri to the target web site (or app) based on the original authorization request's redirect_uri and the newly obtained authorization code and directs its user agent to this URL.
The web 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.
Countermeasures:
If a Service Provider 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 code or access tokens per user, an attacker could exhaust the pool by repeatedly directing user(s) browser to request code or access tokens. This is because more entropy means a larger number of tokens can be issued.
Countermeasures:
Description: the access token is directly returned to the client as part of the redirect URL. This token might be eavesdropped by an attacker. The token is sent from server to client via a URI fragment of the redirect_uri. If the communication is not secured or the end-point 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.
Countermeasures:
An attacker could obtain the token from the browsers history.
Countermeasures:
An malicious client could attempt to obtain a token by fraud. Client secrets are not an effective countermeasure in this case.
The following countermeasures are advisable:
The “password” grant type (see OAuth Core Section 4.3), often used for legacy/migration reasons, allows a client to request an access token using an end-users user-id and password along with its own credential. The “password” 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 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.
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-living tokens and pass them up to a attacker web service for further abuse. The client, eavesdroppers, or end-points could eavesdrop user id and password.
Countermeasures:
If an authorization server does not provide enough protection, an attacker or disgruntled employee could retrieve the passwords for a client
Countermeasures:
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:
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:
An attacker could attempt to eavesdrop the transmission of end-user credentials with the grant type „password“ between client and server.
Impact: disclosure of a single end-users password.
Countermeasures:
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 service providers domain since many users tend to use the same credentials on different services.
Countermeasures:
An attacker may try to guess valid username/password combinations using the grant type „password“.
Impact: Revelation of a single username/password combination.
Countermeasures:
[TBD]
The OAuth specification does not describe any mechanism for protecting Tokens from eavesdroppers when they are transmitted from the Service Provider to the Client.
Countermeasures:
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.
Impact: disclosure of all refresh tokens
Countermeasures:
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 single refresh token and derivable access tokens.
Countermeasures:
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 suceed.
Countermeasures:
An attacker could try to obtain a valid access token on transport between client and resource server. As access tokens are shared secrets between authorization and resource server, they MUST by treated with the same care as other credentials (e.g. end-user passwords).
Countermeasures:
An attacker could attempt to replay valid requests in order to obtain or to modify/destroy user data.
Countermeasures:
Where the token is a handle, the attacker may use attempt to guess the access token values based on knowledge they have from other access tokens.
Impact: Access to a single user's data.
Countermeasures:
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 tokens to this counterfeit resource server, the server in turn may use that token to access other services on behalf of the resource owner.
Countermeasures:
A legitimate resource server could attempt to use an access token to access another resource servers. Similarily, a client could try to use a token obtained for one server on another resource server.
Countermeasures:
The HTTP Authorization scheme (OAuth HTTP Authorization Scheme) is optional. However, [RFC2616](Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, “Hypertext Transfer Protocol -- HTTP/1.1,” .) 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 retrievable from) publicly-accessible caches.
CounterMeasures:
If access tokens are sent via URI query parameters, such tokens may leak to log files and HTTP referrers.
Countermeasures:
This section describes the countermeasures as recommended to mitigate the threats as described in Section 4.
This is applicable to all requests sent from client to 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 attacks through using content of request, e.g. secrets or tokens, or mount replay attacks.
Attacks can be mitigated by using transport-layer mechanisms such as TLS or SSL. VPN may considered as well.
This is a countermeasure against the following threats:
HTTPS server authentication or similar means can be used to authenticate the identity of a server. The goal is to reliably bind the DNS name of the server to the public key presented by the server during connection establishment.
The client MUST validate the binding of the server to its domain name. If the server fails to prove that binding, it is condered a men-in-the-middle. The 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:
Transparency to the resource owner is a key element of the OAuth protocol. The user shall always be in control of the authorization processes and get the necessary information to meet 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:
This sections describes countermeasures used to protect all kind 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 token) or authorization codes.
A server system may be locked down so that no attacker may get access to sensible configuration files and databases.
[TBD]
The authorization server may consider to not store credential in clear text. Typical approaches are to store hashes instead. If the credential lacks a reasonable entropy level (because it is a user password) an additional salt will harden the storage to prevent offline dictionary attacks. 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.
[TBD]
Usage of asymmetric cryptography will free the authorization server of the obligation to manage credentials. Nevertheless, it MUST ensure the integrity of the respective public keys.
The authorization server may decide to enforce a complex user password policy in order to increase the user passwords' entropy. This will hinder online password attacks.
When creating token handles or other secrets not intended for usage by human users, the authorization server MUST include a reasonable level of entropy in order to mitigate the risk of guessing attacks.
The token value MUST be constructed from a cryptographically strong random or pseudo-random number sequence [RFC1750] generated by the Authorization Server. The probability of any two Authorization Code values being identical MUST be less than or equal to 2^(-128) and SHOULD be less than or equal to 2^(-160).
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.
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 attackes attempts on a certain username down.
Note: this may require a more complex and stateful design of the authorization server.
The idea is to prevent programms from automatically checkinga huge number of passwords by requiring human interaction.
Note: this has a negative impact on user experience.
The authorization server may decide to reduce or limit the scope associated with a token. Basis of this decision is out of scope, examples are:
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 gran type username/password. This means will reduce the impact of the following threats:
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.
A short expiration time for tokens is a protection means against the following threats:
Note: Short token duration requires preciser clock synchronisation between authorization server and resource server. Furthermore, shorter duration may require more token refreshments (access token) or repeated end-user authorization processes (authorization code and refresh token).
The authorization server may restrict the number of request, which can be performed with a certain token. This mechanism can be used to mitigate the following threats:
Additionally, If an Authorization Server observes multiple attempts to redeem a authorization code, the Authorization Server may want to revoke all tokens granted based on the authorization code.
Authorization servers in multi-service environments may consider to issue tokens with different content to different resource servers and to explicitely indicate in the token the target server a token is intended to be sent to (cf. Audience in SAML Assertions). This countermeasure can be used in the following situations:
This may be used to indicate to a resource server, which endpoint address has been used to obtain the token. This measure will allow to detect requests from a counterfeit resource server, since such token will contain the endpoint address of that server.
Deployments may consider to use only tokens with explicitely defined scope, 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 then the intended purpose.
An authorization server may bind a token to a certain client identity. This identity match must be validated for every request with that token. This means can be used, to
Note: Validating the client identity may require the target server to authenticate the client's identity. This authentication can be based on secrets managed independent 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).
Self-contained tokens shall be signed in order to detect any attempt to modify or produce faked tokens.
Self-contained may be encrypted for privacy reasons or to protect system internal data.
When creating token handles, the authorization server MUST include a reasonable level of entropy in order to mitigate the risk of guessing attacks. The token value MUST be constructed from a cryptographically strong random or pseudo-random number sequence [RFC1750] generated by the Authorization Server. The probability of any two Authorization Code values being identical MUST be less than or equal to 2^(-128) and SHOULD be less than or equal to 2^(-160).
If an Authorization Server observes multiple attempts to redeem a authorization code, the Authorization Server may want to revoke all tokens granted based on the authorization code.
The authorization server may decide based on an appropriate policy not to issue refresh tokens. Since refresh tokens areo long term credentials, they may be subject 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.
The authorization server MUST bind every refresh token to the id of the client such a token was originally issued to and validate this binding for every request to refresh that token. This measure is a countermeasure against refresh token theft or leakage.
Note: This binding MUST be protected from unauthorized modifications.
Refresh token replacement 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 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 tokens 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.
The authorization server may allow clients or end-users to explicitely request the invalidation of refresh tokens.
This is a countermeasure againts:
The exchange of a refresh token can be bound to the presence of a certain user-provided secret, such as a PIN, a password or a SIM card. This is a kind of multi-factor authentication on the tokens endpoint, since an attacker must possess both factors in order to be able to obtain an access token.
The authorization server may require to bind authentication credentials to a device identifier or token assigned to that device. As the IMEI can be spoofed, that is not suitable, For mobile phones, a registration process can be used to assign a unique token to the device using an sms message. That token or identifer can then be validated with when authenticating user credentials.
This is a countermeasure against the following threats:
As described in Section 3 (Security Features), clients are identified, authenticated and authorized for several purposes, such as a
Due to the different capababilities and characterictics of the different client types, there are different ways to support achieve objectives, which will be described in this section. Generally spoken, authorization server providers should be aware of the security policy and deployment of a particular clients and adapt its treatment accordingly. For example, one approach could be to treat all clients as less trustworthy and unsecure. On the other extrem, a service provider could activate every client installation by hand of an administrator and that way gain confidence in the identity of the software package and the security of the environment the client is installed in. And there are several approaches in between.
Authorization servers should not issue secrets to clients, if these cannot sufficiently protect it. This prevents the server from overestimating the value of a sucessful authentication of the client.
For example, it is of limited benefit to create a single client id and secret which is shared by all installations of a native app. First of all, this secret must be somehow transmitted from the developer via the respective distribution channel, e.g. an app market, to all installations of the app on end-user devices. So the secret is typically burned into the source code of the app or a associated resource bundle, which cannot be entirely protected from reverse engineering. Second, effectively such secrets cannot be revoked since this would immediatly put all installations out of work. Moreover, since the authorization server cannot really trust on the client's identity, 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.
The authorization may issue a client id, but only accept authorization request, which are approved by the end-user. This measure precludes automatic authorization processes. This is a countermeasure for clients without secret against the following threats:
The authorization may issue a client id, but bind this client_id to a certain pre-configured redirect_uri. So any authorization request with another redirect_uri is refused automatically. Alternatively, the authorization server may not accept any dynamic redirect_uri for such a client_id and instead always redirect to the well-known pre-configured redirect_uri. This is a countermeasure for clients of LOA 2 against the following threats:
A authorization server may issue separate client ids and corresponding secrets to the different deployments of a client.
For web applications, this could mean to create one client_id and client_secret per web site a software package is installed on. So the provider of that particular site could request client id and secret from the authorization server during setup of the web site. This would also allow to validate some of the properties of that web site, such as redirect_uri, address, and whatever proofs useful. The web site provider has to ensure the security of the client secret on the site. As a result, such client could reach LOA 7.
For native applications, things are more complicated because every installation of the app on any device is another deployment. Deployment specific secrets will require
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 to achieve LOA 7, whereas the second option does not allow to validate properties of the client thus can achieve at most LOA 6. But this would at least help to prevent several replay attacks. Moreover, deployment-specific client_id and secret allow to selectively revoke all refresh tokens of a specific deployment at once. This is a countermeasure against the following threats:
An authorization server may require clients to register their redirect_uri or a pattern (TBD: make definition more precise) thereof. The way this registration is performed is out of scope of this document. Every actual redirect_uri sent with the respective client_id to the end-user authorization endpoint must comply with that pattern. Otherwise the authorization server must assume the inbound GET request has been sent by an attacker and refuse it.
Note: the authorization server MUST NOT redirect the user agent back to the redirect_uri of the authorization request.
The underlying assumption of this measure is that an attacker must 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 victims device to circumvent this security measure. This is a countermeasure against the following threats:
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, it only works for clients bound to certain deployments at development/configuration time. As soon as dynamic resource server discovery gets involved, that's no longer feasable.
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 be unintentionally for client identifiers and secrets used across multiple deployments of a particular native or web application.
This a countermeasure against:
Assumption: prevents an attacker from obtaining a client secret because this secret is kept in some hardware security module?
Service providers should not automatically process repeat authorizations where the client is not authenticated through a client secret or some other authentication mechanism such as signing with security certs (5.7.2.7. Use strong client authentication (e.g. client_assertion / client_token)) or validation of a pre-registered redirect uri (5.7.2.5. Validation of pre-registered redirect_uri ).
The authorization server shall intelligible explain to the end-user what happens in the authorization process and what the consequences are. For example, the user shall understand what access he is about to grant to which client for what duration. It shall also be obvious to the user, whether the server is able to reliably certify certain client properties (web site address, security policy).
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-users can be involed 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 app the end-user is using. This measure is especially helpful in all situation where the authorization server is unable to authenticate the client. It is a countermeasure against:
The authorization server MUST bind every authorization code to the id of the respective client which initiated the end-user authorization process. This measure is a countermeasure against:
Note: This binding MUST be protected from unauthorized modifications.
The authorization server MAY bind every authorization code to the redirect_uri used as redirect target of the client in the end-user authorization process. This binding MUST be validated when the client attempts to exchange the respective authorization code for an access token. This measure is a countermeasure against session fixation since an attacker cannot use another redirect_uri to exchange an authorization code into a token.
[Anything more to say ? :-)]
The are different way to store secrets of all kinds (tokens, client secrets) securely on a device or server.
Most multi-user operation systems seggregate the personal storage of the different system users. Moreover, most modern smartphone operating systems even support to store app-specific data in separat areas of the file systems and protect it from access by other apps. Additionally, apps can implements confidential data itself using a user-supplied secret, such as PIN or password.
Another option is to swap refresh token storage to a trusted backend server. This mean in turn requires a resilient authentication mechanisms between client and backend server. Note: Applications must ensure that confidential data are kept confidential even after readin from secure storage, which typically means to keep this data in the local memory of the app.
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.
An authorization server may bind tokens to a certain client identitiy and encourage resource servers to validate that binding. This will require the resource server to authenticate the originator of a request as the legitimate owner of a particular token. There are a couple of options to implement this countermeasure:
This mechanisms is a countermeasure against abuse of tokens by counterfeit resource servers.
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 must be uniquly identifiable and must not be processed twice by the resource server. This countermeasure helps to mitigate:
This document makes no request of IANA.
Note to RFC Editor: this section may be removed on publication as an RFC.
[TBD]
| [RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. |
| [I-D.ietf-oauth-v2] | Hammer-Lahav, E, Recordon, D and D Hardt, "The OAuth 2.0 Authorization Protocol", Internet-Draft draft-ietf-oauth-v2-22, September 2011. |
| [I-D.lodderstedt-oauth-revocation] | Lodderstedt, T, Dronia, S and M Scurtescu, "Token Revocation", Internet-Draft draft-lodderstedt-oauth-revocation-03, September 2011. |
| [I-D.ietf-oauth-v2-bearer] | Jones, M, Hardt, D and D Recordon, "The OAuth 2.0 Authorization Protocol: Bearer Tokens", Internet-Draft draft-ietf-oauth-v2-bearer-14, November 2011. |
| [I-D.hammer-oauth-v2-mac-token] | Hammer-Lahav, E, Barth, A and B Adida, "HTTP Authentication: MAC Access Authentication", Internet-Draft draft-hammer-oauth-v2-mac-token-05, May 2011. |
| [portable-contacts] | Smarr, J., "Portable Contacts 1.0 Draft C", August 2008. |