draft-ietf-oauth-security-topics-09.txt   draft-ietf-oauth-security-topics-10.txt 
Open Authentication Protocol T. Lodderstedt, Ed. Open Authentication Protocol T. Lodderstedt, Ed.
Internet-Draft yes.com Internet-Draft yes.com
Intended status: Best Current Practice J. Bradley Intended status: Best Current Practice J. Bradley
Expires: May 13, 2019 Yubico Expires: May 23, 2019 Yubico
A. Labunets A. Labunets
Facebook Facebook
D. Fett D. Fett
yes.com yes.com
November 09, 2018 November 19, 2018
OAuth 2.0 Security Best Current Practice OAuth 2.0 Security Best Current Practice
draft-ietf-oauth-security-topics-09 draft-ietf-oauth-security-topics-10
Abstract Abstract
This document describes best current security practice for OAuth 2.0. This document describes best current security practice for OAuth 2.0.
It updates and extends the OAuth 2.0 Security Threat Model to It updates and extends the OAuth 2.0 Security Threat Model to
incorporate practical experiences gathered since OAuth 2.0 was incorporate practical experiences gathered since OAuth 2.0 was
published and covers new threats relevant due to the broader published and covers new threats relevant due to the broader
application of OAuth 2.0. application of OAuth 2.0.
Status of This Memo Status of This Memo
skipping to change at page 1, line 39 skipping to change at page 1, line 39
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on May 13, 2019. This Internet-Draft will expire on May 23, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 17 skipping to change at page 2, line 17
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 4 2. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Protecting Redirect-Based Flows . . . . . . . . . . . . . 4 2.1. Protecting Redirect-Based Flows . . . . . . . . . . . . . 4
2.1.1. Authorization Code Grant . . . . . . . . . . . . . . 5 2.1.1. Authorization Code Grant . . . . . . . . . . . . . . 5
2.1.2. Implicit Grant . . . . . . . . . . . . . . . . . . . 5 2.1.2. Implicit Grant . . . . . . . . . . . . . . . . . . . 5
2.2. Token Replay Prevention . . . . . . . . . . . . . . . . . 5 2.2. Token Replay Prevention . . . . . . . . . . . . . . . . . 6
2.3. Access Token Privilege Restriction . . . . . . . . . . . 6 2.3. Access Token Privilege Restriction . . . . . . . . . . . 6
3. Attacks and Mitigations . . . . . . . . . . . . . . . . . . . 6 3. Attacks and Mitigations . . . . . . . . . . . . . . . . . . . 7
3.1. Insufficient Redirect URI Validation . . . . . . . . . . 6 3.1. Insufficient Redirect URI Validation . . . . . . . . . . 7
3.1.1. Attacks on Authorization Code Grant . . . . . . . . . 7 3.1.1. Attacks on Authorization Code Grant . . . . . . . . . 7
3.1.2. Attacks on Implicit Grant . . . . . . . . . . . . . . 8 3.1.2. Attacks on Implicit Grant . . . . . . . . . . . . . . 8
3.1.3. Proposed Countermeasures . . . . . . . . . . . . . . 9 3.1.3. Proposed Countermeasures . . . . . . . . . . . . . . 10
3.2. Credential Leakage via Referrer Headers . . . . . . . . . 10 3.2. Credential Leakage via Referrer Headers . . . . . . . . . 10
3.2.1. Leakage from the OAuth client . . . . . . . . . . . . 10 3.2.1. Leakage from the OAuth client . . . . . . . . . . . . 10
3.2.2. Leakage from the Authorization Server . . . . . . . . 10 3.2.2. Leakage from the Authorization Server . . . . . . . . 11
3.2.3. Consequences . . . . . . . . . . . . . . . . . . . . 11 3.2.3. Consequences . . . . . . . . . . . . . . . . . . . . 11
3.2.4. Proposed Countermeasures . . . . . . . . . . . . . . 11 3.2.4. Proposed Countermeasures . . . . . . . . . . . . . . 11
3.3. Attacks through the Browser History . . . . . . . . . . . 12 3.3. Attacks through the Browser History . . . . . . . . . . . 12
3.3.1. Code in Browser History . . . . . . . . . . . . . . . 12 3.3.1. Code in Browser History . . . . . . . . . . . . . . . 12
3.3.2. Access Token in Browser History . . . . . . . . . . . 12 3.3.2. Access Token in Browser History . . . . . . . . . . . 12
3.4. Mix-Up . . . . . . . . . . . . . . . . . . . . . . . . . 13 3.4. Mix-Up . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.4.1. Attack Description . . . . . . . . . . . . . . . . . 13 3.4.1. Attack Description . . . . . . . . . . . . . . . . . 13
3.4.2. Countermeasures . . . . . . . . . . . . . . . . . . . 15 3.4.2. Countermeasures . . . . . . . . . . . . . . . . . . . 15
3.5. Authorization Code Injection . . . . . . . . . . . . . . 15 3.5. Authorization Code Injection . . . . . . . . . . . . . . 16
3.5.1. Proposed Countermeasures . . . . . . . . . . . . . . 17 3.5.1. Proposed Countermeasures . . . . . . . . . . . . . . 18
3.6. Access Token Injection . . . . . . . . . . . . . . . . . 19 3.6. Access Token Injection . . . . . . . . . . . . . . . . . 19
3.6.1. Proposed Countermeasures . . . . . . . . . . . . . . 19 3.6.1. Proposed Countermeasures . . . . . . . . . . . . . . 20
3.7. Cross Site Request Forgery . . . . . . . . . . . . . . . 19 3.7. Cross Site Request Forgery . . . . . . . . . . . . . . . 20
3.7.1. Proposed Countermeasures . . . . . . . . . . . . . . 20 3.7.1. Proposed Countermeasures . . . . . . . . . . . . . . 20
3.8. Access Token Leakage at the Resource Server . . . . . . . 20 3.8. Access Token Leakage at the Resource Server . . . . . . . 20
3.8.1. Access Token Phishing by Counterfeit Resource Server 20 3.8.1. Access Token Phishing by Counterfeit Resource Server 20
3.8.1.1. Metadata . . . . . . . . . . . . . . . . . . . . 20 3.8.1.1. Metadata . . . . . . . . . . . . . . . . . . . . 21
3.8.1.2. Sender Constrained Access Tokens . . . . . . . . 22 3.8.1.2. Sender Constrained Access Tokens . . . . . . . . 22
3.8.1.3. Audience Restricted Access Tokens . . . . . . . . 24 3.8.1.3. Audience Restricted Access Tokens . . . . . . . . 25
3.8.2. Compromised Resource Server . . . . . . . . . . . . . 25 3.8.2. Compromised Resource Server . . . . . . . . . . . . . 26
3.9. Open Redirection . . . . . . . . . . . . . . . . . . . . 26 3.9. Open Redirection . . . . . . . . . . . . . . . . . . . . 27
3.9.1. Authorization Server as Open Redirector . . . . . . . 26 3.9.1. Authorization Server as Open Redirector . . . . . . . 27
3.9.2. Clients as Open Redirector . . . . . . . . . . . . . 27 3.9.2. Clients as Open Redirector . . . . . . . . . . . . . 27
3.10. 307 Redirect . . . . . . . . . . . . . . . . . . . . . . 27 3.10. 307 Redirect . . . . . . . . . . . . . . . . . . . . . . 27
3.11. TLS Terminating Reverse Proxies . . . . . . . . . . . . . 28 3.11. TLS Terminating Reverse Proxies . . . . . . . . . . . . . 28
3.12. Refresh Token Protection . . . . . . . . . . . . . . . . 29
4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 28 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 31
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31
6. Security Considerations . . . . . . . . . . . . . . . . . . . 29 6. Security Considerations . . . . . . . . . . . . . . . . . . . 31
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 29 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 31
7.1. Normative References . . . . . . . . . . . . . . . . . . 29 7.1. Normative References . . . . . . . . . . . . . . . . . . 31
7.2. Informative References . . . . . . . . . . . . . . . . . 29 7.2. Informative References . . . . . . . . . . . . . . . . . 32
Appendix A. Document History . . . . . . . . . . . . . . . . . . 33 Appendix A. Document History . . . . . . . . . . . . . . . . . . 35
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 35 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 37
1. Introduction 1. Introduction
It's been a while since OAuth has been published in RFC 6749 It's been a while since OAuth has been published in RFC 6749
[RFC6749] and RFC 6750 [RFC6750]. Since publication, OAuth 2.0 has [RFC6749] and RFC 6750 [RFC6750]. Since publication, OAuth 2.0 has
gotten massive traction in the market and became the standard for API gotten massive traction in the market and became the standard for API
protection and, as foundation of OpenID Connect [OpenID], identity protection and, as foundation of OpenID Connect [OpenID], identity
providing. While OAuth was used in a variety of scenarios and providing. While OAuth was used in a variety of scenarios and
different kinds of deployments, the following challenges could be different kinds of deployments, the following challenges could be
observed: observed:
skipping to change at page 4, line 24 skipping to change at page 4, line 25
in the wild today is given along with a discussion of potential in the wild today is given along with a discussion of potential
countermeasures. countermeasures.
2. Recommendations 2. Recommendations
This section describes the set of security mechanisms the OAuth This section describes the set of security mechanisms the OAuth
working group recommendeds to OAuth implementers. working group recommendeds to OAuth implementers.
2.1. Protecting Redirect-Based Flows 2.1. Protecting Redirect-Based Flows
Authorization servers SHALL utilize exact matching of client redirect Authorization servers MUST utilize exact matching of client redirect
URIs against pre-registered URIs. This measure contributes to the URIs against pre-registered URIs. This measure contributes to the
prevention of leakage of authorization codes and access tokens prevention of leakage of authorization codes and access tokens
(depending on the grant type). It also helps to detect mix-up (depending on the grant type). It also helps to detect mix-up
attacks. attacks.
Clients SHALL avoid any redirects or forwards which can be Clients SHOULD avoid forwarding the user's browser to a URI obtained
parameterized by URI query parameters, in order to provide a further from a query parameter since such a function could be utilized to
layer of defence against token leakage. If there is a need for this exfiltrate authorization codes and access tokens. If there is a
kind of redirects, clients are advised to implement appropriate strong need for this kind of redirects, clients are advised to
countermeasures against open redirection, e.g., as described by the implement appropriate countermeasures against open redirection, e.g.,
OWASP [owasp]. as described by the OWASP [owasp].
Clients SHALL ensure to only process redirect responses of the OAuth Clients MUST prevent CSRF and ensure that each authorization response
authorization server they send the respective request to and in the is only accepted once. One-time use CSRF tokens carried in the
same user agent this request was initiated in. In particular, "state" parameter, which are securely bound to the user agent, SHOULD
clients SHALL implement appropriate CSRF prevention by utilizing one- be used for that purpose.
time use CSRF tokens carried in the "state" parameter, which are
securely bound to the user agent. Moreover, the client SHALL In order to prevent mix-up attacks, clients MUST only process
memorize which authorization server it sent an authorization request redirect responses of the OAuth authorization server they send the
to and bind this information to the user agent and ensure any sub- respective request to and from the same user agent this authorization
sequent messages are sent to the same authorization server. request was initiated with. Clients MUST memorize which
Furthermore, clients SHOULD use AS-specific redirect URIs as a means authorization server they sent an authorization request to and bind
to identify the AS a particular response came from. Matching this this information to the user agent and ensure any sub-sequent
with the before mentioned information regarding the AS the client messages are sent to the same authorization server. Clients SHOULD
sent the request to helps to detect mix-up attacks. use AS-specific redirect URIs as a means to identify the AS a
particular response came from.
Note: [I-D.bradley-oauth-jwt-encoded-state] gives advice on how to Note: [I-D.bradley-oauth-jwt-encoded-state] gives advice on how to
implement CSRF prevention and AS matching using signed JWTs in the implement CSRF prevention and AS matching using signed JWTs in the
"state" parameter. "state" parameter.
2.1.1. Authorization Code Grant 2.1.1. Authorization Code Grant
Clients utilizing the authorization grant type SHALL use PKCE Clients utilizing the authorization grant type MUST use PKCE
[RFC7636] in order to (with the help of the authorization server) [RFC7636] in order to (with the help of the authorization server)
detect and prevent attempts to inject (replay) authorization codes detect and prevent attempts to inject (replay) authorization codes
into the authorization response. The PKCE challenges must be into the authorization response. The PKCE challenges must be
transaction-specific and securely bound to the user agent in which transaction-specific and securely bound to the user agent in which
the transaction was started. OpenID Connect clients MAY use the the transaction was started. OpenID Connect clients MAY use the
"nonce" parameter of the OpenID Connect authentication request as "nonce" parameter of the OpenID Connect authentication request as
specified in [OpenID] in conjunction with the corresponding ID Token specified in [OpenID] in conjunction with the corresponding ID Token
claim for the same purpose. claim for the same purpose.
Note: although PKCE so far was recommended as a mechanism to protect Note: although PKCE so far was recommended as a mechanism to protect
native apps, this advice applies to all kinds of OAuth clients, native apps, this advice applies to all kinds of OAuth clients,
including web applications. including web applications.
Authorization servers SHALL consider the recommendations given in Authorization servers MUST bind authorization codes to a certain
[RFC6819], Section 4.4.1.1, on authorization code replay prevention. client and authenticate it using an appropriate mechanism (e.g.
client credentials or PKCE).
Authorization servers SHOULD furthermore consider the recommendations
given in [RFC6819], Section 4.4.1.1, on authorization code replay
prevention.
2.1.2. Implicit Grant 2.1.2. Implicit Grant
The implicit grant (response type "token") and other response types The implicit grant (response type "token") and other response types
causing the authorization server to issue access tokens in the causing the authorization server to issue access tokens in the
authorization response are vulnerable to access token leakage and authorization response are vulnerable to access token leakage and
access token replay as described in Section 3.1, Section 3.2, access token replay as described in Section 3.1, Section 3.2,
Section 3.3, and Section 3.6. Section 3.3, and Section 3.6.
Moreover, no viable mechanism exists to cryptographically bind access
tokens issued in the authorization response to a certain client as it
is recommended in Section 2.2. This makes replay detection for such
access tokens at resource servers impossible.
In order to avoid these issues, Clients SHOULD NOT use the implicit In order to avoid these issues, Clients SHOULD NOT use the implicit
grant and any other response type causing the authorization server to grant or any other response type causing the authorization server to
issue an access token in the authorization response. issue an access token in the authorization response.
Clients SHOULD instead use the response type "code" (aka Clients SHOULD instead use the response type "code" (aka
authorization code grant type) as specified in Section 2.1.1 or any authorization code grant type) as specified in Section 2.1.1 or any
other response type that does not cause the authorization server to other response type that causes the authorization server to issue
issue access tokens in the authorization response. access tokens in the token response. This allows the authorization
server to detect replay attempts and generally reduces the attack
surface since access tokens are not exposed in URLs. It also allows
the authorization server to sender-constrain the issued tokens.
2.2. Token Replay Prevention 2.2. Token Replay Prevention
Authorization servers SHOULD use TLS-based methods for sender Authorization servers SHOULD use TLS-based methods for sender
constrained access tokens as described in Section 3.8.1.2, such as constrained access tokens as described in Section 3.8.1.2, such as
token binding [I-D.ietf-oauth-token-binding] or Mutual TLS for OAuth token binding [I-D.ietf-oauth-token-binding] or Mutual TLS for OAuth
2.0 [I-D.ietf-oauth-mtls] in order to prevent token replay. It is 2.0 [I-D.ietf-oauth-mtls] in order to prevent token replay. It is
also recommended to use end-to-end TLS whenever possible. also recommended to use end-to-end TLS whenever possible.
2.3. Access Token Privilege Restriction 2.3. Access Token Privilege Restriction
skipping to change at page 9, line 47 skipping to change at page 10, line 16
(6) The attacker's page at client.evil.example can access the (6) The attacker's page at client.evil.example can access the
fragment and obtain the access token. fragment and obtain the access token.
3.1.3. Proposed Countermeasures 3.1.3. Proposed Countermeasures
The complexity of implementing and managing pattern matching The complexity of implementing and managing pattern matching
correctly obviously causes security issues. This document therefore correctly obviously causes security issues. This document therefore
proposes to simplify the required logic and configuration by using proposes to simplify the required logic and configuration by using
exact redirect URI matching only. This means the authorization exact redirect URI matching only. This means the authorization
server shall compare the two URIs using simple string comparison as server must compare the two URIs using simple string comparison as
defined in [RFC3986], Section 6.2.1.. defined in [RFC3986], Section 6.2.1..
Additional recommendations: Additional recommendations:
o Servers on which callbacks are hosted must not expose open o Servers on which callbacks are hosted must not expose open
redirectors (see Section 3.9). redirectors (see Section 3.9).
o Clients MAY drop fragments via intermediary URLs with "fix o Clients MAY drop fragments via intermediary URLs with "fix
fragments" (see [fb_fragments]) to prevent the user agent from fragments" (see [fb_fragments]) to prevent the user agent from
appending any unintended fragments. appending any unintended fragments.
skipping to change at page 11, line 23 skipping to change at page 11, line 38
3.2.4. Proposed Countermeasures 3.2.4. Proposed Countermeasures
The page rendered as a result of the OAuth authorization response and The page rendered as a result of the OAuth authorization response and
the authorization endpoint SHOULD not include third-party resources the authorization endpoint SHOULD not include third-party resources
or links to external sites. or links to external sites.
The following measures further reduce the chances of a successful The following measures further reduce the chances of a successful
attack: attack:
o Bind authorization code to a confidential client or PKCE
challenge. In this case, the attacker lacks the secret to request
the code exchange.
o Authorization codes SHOULD be invalidated by the AS after their o Authorization codes SHOULD be invalidated by the AS after their
first use at the token endpoint. For example, if an AS first use at the token endpoint. For example, if an AS
invalidated the code after the legitimate client redeemed it, the invalidated the code after the legitimate client redeemed it, the
attacker would fail exchanging this code later. (This does not attacker would fail exchanging this code later. (This does not
mitigate the attack if the attacker manages to exchange the code mitigate the attack if the attacker manages to exchange the code
for a token before the legitimate client does so.) for a token before the legitimate client does so.)
o The "state" value SHOULD be invalidated by the client after its o The "state" value SHOULD be invalidated by the client after its
first use at the redirection endpoint. If this is implemented, first use at the redirection endpoint. If this is implemented,
and an attacker receives a token through the referrer header from and an attacker receives a token through the referrer header from
the client's web site, the "state" was already used, invalidated the client's web site, the "state" was already used, invalidated
by the client and cannot be used again by the attacker. (This by the client and cannot be used again by the attacker. (This
does not help if the "state" leaks from the AS's web site, since does not help if the "state" leaks from the AS's web site, since
then the "state" has not been used at the redirection endpoint at then the "state" has not been used at the redirection endpoint at
the client yet.) the client yet.)
o Bind authorization code to a confidential client or PKCE
challenge. In this case, the attacker lacks the secret to request
the code exchange.
o Suppress the referrer header by adding the attribute o Suppress the referrer header by adding the attribute
"rel="noreferrer"" to HTML links or by applying an appropriate "rel="noreferrer"" to HTML links or by applying an appropriate
Referrer Policy [webappsec-referrer-policy] to the document Referrer Policy [webappsec-referrer-policy] to the document
(either as part of the "referrer" meta attribute or by setting a (either as part of the "referrer" meta attribute or by setting a
Referrer-Policy header). Referrer-Policy header).
o Use authorization code instead of response types causing access o Use authorization code instead of response types causing access
token issuance from the authorization endpoint. This provides token issuance from the authorization endpoint. This provides
countermeasures against leakage on the OAuth protocol level countermeasures against leakage on the OAuth protocol level
through the code exchange process with the authorization server. through the code exchange process with the authorization server.
skipping to change at page 26, line 7 skipping to change at page 26, line 36
Even if the attacker "only" is able to access logfiles or databases Even if the attacker "only" is able to access logfiles or databases
of the server system, it may get access to valid access tokens. of the server system, it may get access to valid access tokens.
Preventing server breaches by way of hardening and monitoring server Preventing server breaches by way of hardening and monitoring server
systems is considered a standard operational procedure and therefore systems is considered a standard operational procedure and therefore
out of scope of this document. This section will focus on the impact out of scope of this document. This section will focus on the impact
of such breaches on OAuth-related parts of the ecosystem, which is of such breaches on OAuth-related parts of the ecosystem, which is
the replay of captured access tokens on the compromised resource the replay of captured access tokens on the compromised resource
server and other resource servers of the respective deployment. server and other resource servers of the respective deployment.
The following measures shall be taken into account by implementors in The following measures should be taken into account by implementors
order to cope with access token replay: in order to cope with access token replay:
o The resource server must treat access tokens like any other o The resource server must treat access tokens like any other
credentials. It is considered good practice to not log them and credentials. It is considered good practice to not log them and
not to store them in plain text. not to store them in plain text.
o Sender constraint access tokens as described in Section 3.8.1.2 o Sender constraint access tokens as described in Section 3.8.1.2
will prevent the attacker from replaying the access tokens on will prevent the attacker from replaying the access tokens on
other resource servers. Depending on the severity of the other resource servers. Depending on the severity of the
penetration, it will also prevent replay on the compromised penetration, it will also prevent replay on the compromised
system. system.
skipping to change at page 28, line 42 skipping to change at page 29, line 20
application servers. application servers.
If an attacker would be able to get access to the internal network If an attacker would be able to get access to the internal network
between proxy and application server, it could also try to circumvent between proxy and application server, it could also try to circumvent
security controls in place. It is therefore important to ensure the security controls in place. It is therefore important to ensure the
authenticity of the communicating entities. Furthermore, the authenticity of the communicating entities. Furthermore, the
communication link between reverse proxy and application server must communication link between reverse proxy and application server must
therefore be protected against tapping and injection (including therefore be protected against tapping and injection (including
replay prevention). replay prevention).
3.12. Refresh Token Protection
Refresh tokens are a convenient and UX-friendly way to obtain new
access tokens after the expiration of older access tokens. Refresh
tokens also add to the security of OAuth since they allow the
authorization server to issue access tokens with a short lifetime and
reduced scope thus reducing the potential impact of access token
leakage.
Refresh tokens themself are an attractive target for attackers since
they represent the overall grant a resource owner delegated to a
certain client. If an attacker is able to exfiltrate and
successfully replay a refresh token, it will be able to mint access
tokens and use them to access resource servers on behalf of the
resource server.
[RFC6749] already provides robust base protection by requiring
o confidentiality of the refresh tokens in transit and storage,
o the transmission of refresh tokens over TLS-protected connections
between authorization server and client,
o the authorization server to maintain and check the binding of a
refresh token to a certain client_id,
o authentication of this client_id during token refresh, if
possible, and
o that refresh tokens cannot be generated, modified, or guessed.
[RFC6749] also lays the foundation for further (implementation
specific) security measures, such as refresh token expiration and
revocation as well as refresh token rotation by defining respective
error codes and response behavior.
This draft gives recommendations beyond the scope of [RFC6749] and
clarifications.
Authorization servers SHALL determine based on their risk assessment
whether to issue refresh tokens to a certain client. If the
authorization server decides not to issue refresh tokens, the client
may refresh access tokens by utilizing other grant types, such as the
authorization code grant type. In such a case, the authorization
server may utilize cookies and persistents grants to optimize the
user experience.
If refresh tokens are issued, those refresh tokens MUST be bound to
the scope and resource servers as consented by the resource owner.
This is to prevent privilege escalation by the legit client and
reduce the impact of refresh tokens leakage.
Authorization server SHALL utilize one of the methods listed below to
detect refresh token replay for public clients:
o Refresh token rotation: the authorization issues a new refresh
token with every access token refresh response. The previous
refresh token is invalidated but information about the
relationship is retained by the authorization server. If a
refresh token is compromised and subsequently used by both the
attacker and the legitimate client, one of them will present an
invalidated refresh token, which will inform the authorization
server of the breach. The authorization server cannot determine
which party submitted the invalid refresh token, but it can revoke
the active refresh token. This stops the attack at the cost of
forcing the legit client to obtain a fresh authorization grant.
o Sender constrained refresh tokens: the authorization server
cryptographically binds the refresh token to a certain client
instance by utilizing [I-D.ietf-oauth-token-binding] or
[I-D.ietf-oauth-mtls].
Authorization servers may revoke refresh tokens automatically in case
of a security event, such as:
o password change
o logout at the authorization server
Refresh tokens should expire if the client has been inactive for some
time.
4. Acknowledgements 4. Acknowledgements
We would like to thank Jim Manico, Phil Hunt, Nat Sakimura, Christian We would like to thank Jim Manico, Phil Hunt, Nat Sakimura, Christian
Mainka, Doug McDorman, Johan Peeters, and Brian Campbell for their Mainka, Doug McDorman, Johan Peeters, Joseph Heenan, Brock Allen, and
valuable feedback. Brian Campbell for their valuable feedback.
5. IANA Considerations 5. IANA Considerations
This draft includes no request to IANA. This draft includes no request to IANA.
6. Security Considerations 6. Security Considerations
All relevant security considerations have been given in the All relevant security considerations have been given in the
functional specification. functional specification.
skipping to change at page 33, line 18 skipping to change at page 35, line 23
<https://www.rfc-editor.org/info/rfc8414>. <https://www.rfc-editor.org/info/rfc8414>.
[webappsec-referrer-policy] [webappsec-referrer-policy]
Google Inc. and Google Inc., "Referrer Policy", April Google Inc. and Google Inc., "Referrer Policy", April
2017, <https://w3c.github.io/webappsec-referrer-policy>. 2017, <https://w3c.github.io/webappsec-referrer-policy>.
Appendix A. Document History Appendix A. Document History
[[ To be removed from the final specification ]] [[ To be removed from the final specification ]]
-10
o incorporated feedback by Joseph Heenan
o changed occurrences of SHALL to MUST
o added text on lack of token/cert binding support tokens issued in
the authorization response as justification to not recommend
issuing tokens there at all
o added requirement to authenticate clients during code exchange
(PKCE or client credential) to 2.1.1.
o added section on refresh tokens
o editorial enhancements to 2.1.2 based on feedback
-09 -09
o changed text to recommend not to use implicit but code o changed text to recommend not to use implicit but code
o added section on access token injection o added section on access token injection
o reworked sections 3.1 through 3.3 to be more specific on implicit o reworked sections 3.1 through 3.3 to be more specific on implicit
grant issues grant issues
-08 -08
 End of changes. 28 change blocks. 
62 lines changed or deleted 175 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/