draft-ietf-oauth-security-topics-06.txt   draft-ietf-oauth-security-topics-07.txt 
Open Authentication Protocol T. Lodderstedt, Ed. Open Authentication Protocol T. Lodderstedt, Ed.
Internet-Draft YES.com AG Internet-Draft YES.com AG
Intended status: Best Current Practice J. Bradley Intended status: Best Current Practice J. Bradley
Expires: November 21, 2018 Yubico Expires: February 25, 2019 Yubico
A. Labunets A. Labunets
Facebook Facebook
D. Fett D. Fett
University of Stuttgart YES.com AG
May 20, 2018 August 24, 2018
OAuth 2.0 Security Best Current Practice OAuth 2.0 Security Best Current Practice
draft-ietf-oauth-security-topics-06 draft-ietf-oauth-security-topics-07
Abstract Abstract
This document describes best current security practices for OAuth This document describes best current security practices for OAuth
2.0. It updates and extends the OAuth 2.0 Security Threat Model to 2.0. 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 November 21, 2018. This Internet-Draft will expire on February 25, 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 16 skipping to change at page 2, line 16
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
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.2. Token Replay Prevention . . . . . . . . . . . . . . . . . 5 2.2. Token Replay Prevention . . . . . . . . . . . . . . . . . 5
3. Attacks and Mitigations . . . . . . . . . . . . . . . . . . . 5 2.3. Access Token Privilege Restriction . . . . . . . . . . . 5
3.1. Insufficient redirect URI validation . . . . . . . . . . 5 3. Attacks and Mitigations . . . . . . . . . . . . . . . . . . . 6
3.1. Insufficient redirect URI validation . . . . . . . . . . 6
3.1.1. Attacks on Authorization Code Grant . . . . . . . . . 6 3.1.1. Attacks on Authorization Code Grant . . . . . . . . . 6
3.1.2. Attacks on Implicit Grant . . . . . . . . . . . . . . 7 3.1.2. Attacks on Implicit Grant . . . . . . . . . . . . . . 7
3.1.3. Proposed Countermeasures . . . . . . . . . . . . . . 8 3.1.3. Proposed Countermeasures . . . . . . . . . . . . . . 9
3.2. Code or State Leakage from Client or AS via Referrer 3.2. Code or State Leakage from Client or AS via Referrer
Headers . . . . . . . . . . . . . . . . . . . . . . . . . 9 Headers . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.2.1. Proposed Countermeasures . . . . . . . . . . . . . . 9 3.2.1. Proposed Countermeasures . . . . . . . . . . . . . . 10
3.3. Attacks through the Browser History . . . . . . . . . . . 10 3.3. Attacks through the Browser History . . . . . . . . . . . 11
3.3.1. Code in Browser History . . . . . . . . . . . . . . . 10 3.3.1. Code in Browser History . . . . . . . . . . . . . . . 11
3.3.2. Access Token in Browser History . . . . . . . . . . . 10 3.3.2. Access Token in Browser History . . . . . . . . . . . 11
3.4. Mix-Up . . . . . . . . . . . . . . . . . . . . . . . . . 11 3.4. Mix-Up . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.4.1. Attack Description . . . . . . . . . . . . . . . . . 11 3.4.1. Attack Description . . . . . . . . . . . . . . . . . 12
3.4.2. Countermeasures . . . . . . . . . . . . . . . . . . . 13 3.4.2. Countermeasures . . . . . . . . . . . . . . . . . . . 14
3.5. Code Injection . . . . . . . . . . . . . . . . . . . . . 14 3.5. Code Injection . . . . . . . . . . . . . . . . . . . . . 14
3.5.1. Proposed Countermeasures . . . . . . . . . . . . . . 16 3.5.1. Proposed Countermeasures . . . . . . . . . . . . . . 16
3.6. Cross Site Request Forgery . . . . . . . . . . . . . . . 17 3.6. Cross Site Request Forgery . . . . . . . . . . . . . . . 18
3.6.1. Proposed Countermeasures . . . . . . . . . . . . . . 17 3.6.1. Proposed Countermeasures . . . . . . . . . . . . . . 18
3.7. Access Token Leakage at the Resource Server . . . . . . . 18 3.7. Access Token Leakage at the Resource Server . . . . . . . 18
3.7.1. Access Token Phishing by Counterfeit Resource Server 18 3.7.1. Access Token Phishing by Counterfeit Resource Server 18
3.7.1.1. Metadata . . . . . . . . . . . . . . . . . . . . 18 3.7.1.1. Metadata . . . . . . . . . . . . . . . . . . . . 19
3.7.1.2. Sender Constrained Access Tokens . . . . . . . . 19 3.7.1.2. Sender Constrained Access Tokens . . . . . . . . 20
3.7.1.3. Audience Restricted Access Tokens . . . . . . . . 22 3.7.1.3. Audience Restricted Access Tokens . . . . . . . . 23
3.7.2. Compromised Resource Server . . . . . . . . . . . . . 23 3.7.2. Compromised Resource Server . . . . . . . . . . . . . 24
3.8. Open Redirection . . . . . . . . . . . . . . . . . . . . 24 3.8. Open Redirection . . . . . . . . . . . . . . . . . . . . 25
3.8.1. Authorization Server as Open Redirector . . . . . . . 24 3.8.1. Authorization Server as Open Redirector . . . . . . . 25
3.8.2. Clients as Open Redirector . . . . . . . . . . . . . 24 3.8.2. Clients as Open Redirector . . . . . . . . . . . . . 25
3.9. TLS Terminating Reverse Proxies . . . . . . . . . . . . . 25 3.9. 307 Redirect . . . . . . . . . . . . . . . . . . . . . . 25
4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 25 3.10. TLS Terminating Reverse Proxies . . . . . . . . . . . . . 26
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 27
6. Security Considerations . . . . . . . . . . . . . . . . . . . 26 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 26 6. Security Considerations . . . . . . . . . . . . . . . . . . . 27
7.1. Normative References . . . . . . . . . . . . . . . . . . 26 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 27
7.2. Informative References . . . . . . . . . . . . . . . . . 26 7.1. Normative References . . . . . . . . . . . . . . . . . . 27
Appendix A. Document History . . . . . . . . . . . . . . . . . . 29 7.2. Informative References . . . . . . . . . . . . . . . . . 28
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31
Appendix A. Document History . . . . . . . . . . . . . . . . . . 31
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 33
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 3, line 45 skipping to change at page 3, line 48
the trust relationship among those parties. The validation whether the trust relationship among those parties. The validation whether
the client talks to a legitimate server was based on TLS server the client talks to a legitimate server was based on TLS server
authentication (see [RFC6819], Section 4.5.4). With the increasing authentication (see [RFC6819], Section 4.5.4). With the increasing
adoption of OAuth, this simple model dissolved and, in several adoption of OAuth, this simple model dissolved and, in several
scenarios, was replaced by a dynamic establishment of the scenarios, was replaced by a dynamic establishment of the
relationship between clients on one side and the authorization and relationship between clients on one side and the authorization and
resource servers of a particular deployment on the other side. This resource servers of a particular deployment on the other side. This
way the same client could be used to access services of different way the same client could be used to access services of different
providers (in case of standard APIs, such as e-Mail or OpenID providers (in case of standard APIs, such as e-Mail or OpenID
Connect) or serves as a frontend to a particular tenant in a multi- Connect) or serves as a frontend to a particular tenant in a multi-
tenancy. Extensions of OAuth, such as [RFC7591] and tenancy. Extensions of OAuth, such as [RFC7591] and [RFC8414] were
[I-D.ietf-oauth-discovery] were developed in order to support the developed in order to support the usage of OAuth in dynamic
usage of OAuth in dynamic scenarios. As a challenge to the scenarios. As a challenge to the community, such usage scenarios
community, such usage scenarios open up new attack angles, which are open up new attack angles, which are discussed in this document.
discussed in this document.
The remainder of the document is organized as follows: The next The remainder of the document is organized as follows: The next
section summarizes the most important recommendations of the OAuth section summarizes the most important recommendations of the OAuth
working group for every OAuth implementor. Afterwards, a detailed working group for every OAuth implementor. Afterwards, a detailed
analysis of the threats and implementation issues which can be found analysis of the threats and implementation issues which can be found
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
skipping to change at page 5, line 17 skipping to change at page 5, line 19
Note: although PKCE so far was recommended as mechanism to protect Note: although PKCE so far was recommended as 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 shall consider the recommendations given in
[RFC6819], Section 4.4.1.1, on authorization code replay prevention. [RFC6819], Section 4.4.1.1, on authorization code replay prevention.
2.2. Token Replay Prevention 2.2. Token Replay Prevention
Authorization servers shall use TLS-based methods for sender Authorization servers SHOULD use TLS-based methods for sender
constrained access tokens as described in Section 3.7.1.2, such as constrained access tokens as described in Section 3.7.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 recommend to use end-to-end TLS whenever possible. also recommend to use end-to-end TLS whenever possible.
2.3. Access Token Privilege Restriction
The privileges associated with an access token SHOULD be restricted
to the minimum required for the particular application or use case.
This prevents clients from exceeding the privileges authorized by the
resource owner. It also prevents users from exceeding their
privileges authorized by the respective security policy. Privilege
restrictions also limit the impact of token leakage although more
effective counter-measures are described in Section 2.2.
In particular, access tokens SHOULD be restricted to certain resource
servers, preferably to a single resource server. To put this into
effect, the authorization server associates the access token with
certain resource servers and every resource server is obliged to
verify for every request, whether the access token sent with that
request was meant to be used for that particular resource server. If
not, the resource server MUST refuse to serve the respective request.
Clients and authorization servers MAY utilize the parameters "scope"
or "resource" as specified in [RFC6749] and
[I-D.ietf-oauth-resource-indicators], respectively, to determine the
resource server they want to access.
Additionally, access tokens SHOULD be restricted to certain resources
and actions on resource servers or resources. To put this into
effect, the authorization server associates the access token with the
respective resource and actions and every resource server is obliged
to verify for every request, whether the access token sent with that
request was meant to be used for that particular action on the
particular resource. If not, the resource server must refuse to
serve the respective request. Clients and authorization servers MAY
utilize the parameter "scope" as specified in [RFC6749] to determine
those resources and/or actions.
3. Attacks and Mitigations 3. Attacks and Mitigations
This section gives a detailed description of attacks on OAuth This section gives a detailed description of attacks on OAuth
implementations, along with potential countermeasures. This section implementations, along with potential countermeasures. This section
complements and enhances the description given in [RFC6819]. complements and enhances the description given in [RFC6819].
3.1. Insufficient redirect URI validation 3.1. Insufficient redirect URI validation
Some authorization servers allow clients to register redirect URI Some authorization servers allow clients to register redirect URI
patterns instead of complete redirect URIs. In those cases, the patterns instead of complete redirect URIs. In those cases, the
skipping to change at page 6, line 48 skipping to change at page 7, line 35
even easier. even easier.
(4) If the user does not recognize the attack, the code is issued (4) If the user does not recognize the attack, the code is issued
and directly sent to the attacker's client. and directly sent to the attacker's client.
(5) Since the attacker impersonated a public client, it can directly (5) Since the attacker impersonated a public client, it can directly
exchange the code for tokens at the respective token endpoint. exchange the code for tokens at the respective token endpoint.
Note: This attack will not directly work for confidential clients, Note: This attack will not directly work for confidential clients,
since the code exchange requires authentication with the legitimate since the code exchange requires authentication with the legitimate
client's secret. The attacker will need to utilize the legitimate client's secret. The attacker will need to impersonate or utilize
client to redeem the code (e.g., by performing a code injection the legitimate client to redeem the code (e.g., by performing a code
attack). This kind of injections is covered in injection attack). This kind of injections is covered in
Section Code Injection. Section Code Injection.
3.1.2. Attacks on Implicit Grant 3.1.2. Attacks on Implicit Grant
The attack described above works for the implicit grant as well. If The attack described above works for the implicit grant as well. If
the attacker is able to send the authorization response to a URI the attacker is able to send the authorization response to a URI
under his control, he will directly get access to the fragment under his control, he will directly get access to the fragment
carrying the access token. carrying the access token.
Additionally, implicit clients can be subject to a further kind of Additionally, implicit clients can be subject to a further kind of
skipping to change at page 7, line 27 skipping to change at page 8, line 13
redirector in order to get access to access tokens. This allows redirector in order to get access to access tokens. This allows
circumvention even of strict redirect URI patterns (but not strict circumvention even of strict redirect URI patterns (but not strict
URL matching!). URL matching!).
Assume the pattern for client "s6BhdRkqt3" is Assume the pattern for client "s6BhdRkqt3" is
"https://client.somesite.example/cb?*", i.e., any parameter is "https://client.somesite.example/cb?*", i.e., any parameter is
allowed for redirects to "https://client.somesite.example/cb". allowed for redirects to "https://client.somesite.example/cb".
Unfortunately, the client exposes an open redirector. This endpoint Unfortunately, the client exposes an open redirector. This endpoint
supports a parameter "redirect_to" which takes a target URL and will supports a parameter "redirect_to" which takes a target URL and will
send the browser to this URL using an HTTP Location header redirect send the browser to this URL using an HTTP Location header redirect
302. 303.
(1) Same as above, the attacker needs to trick the user into opening (1) Same as above, the attacker needs to trick the user into opening
a tampered URL in his browser, which launches a page under the a tampered URL in his browser, which launches a page under the
attacker's control, say "https://www.evil.example". attacker's control, say "https://www.evil.example".
(2) The URL initiates an authorization request, which is very (2) The URL initiates an authorization request, which is very
similar to the attack on the code flow. As differences, it similar to the attack on the code flow. As differences, it
utilizes the open redirector by encoding utilizes the open redirector by encoding
"redirect_to=https://client.evil.example" into the redirect URI "redirect_to=https://client.evil.example" into the redirect URI
and it uses the response type "token" (line breaks are for and it uses the response type "token" (line breaks are for
display purposes only): display purposes only):
GET /authorize?response_type=token&client_id=s6BhdRkqt3&state=xyz GET /authorize?response_type=token&client_id=s6BhdRkqt3&state=xyz
&redirect_uri=https%3A%2F%2Fclient.somesite.example%2Fcb%26redirect_to &redirect_uri=https%3A%2F%2Fclient.somesite.example%2Fcb%26redirect_to
%253Dhttps%253A%252F%252Fclient.evil.example%252Fcb HTTP/1.1 %253Dhttps%253A%252F%252Fclient.evil.example%252Fcb HTTP/1.1
Host: server.somesite.example Host: server.somesite.example
(3) Since the redirect URI matches the registered pattern, the (3) Since the redirect URI matches the registered pattern, the
authorization server allows the request and sends the resulting authorization server allows the request and sends the resulting
access token with a 302 redirect (some response parameters are access token with a 303 redirect (some response parameters are
omitted for better readability) omitted for better readability)
HTTP/1.1 302 Found HTTP/1.1 303 See Other
Location: https://client.somesite.example/cb? Location: https://client.somesite.example/cb?
redirect_to%3Dhttps%3A%2F%2Fclient.evil.example%2Fcb redirect_to%3Dhttps%3A%2F%2Fclient.evil.example%2Fcb
#access_token=2YotnFZFEjr1zCsicMWpAA&... #access_token=2YotnFZFEjr1zCsicMWpAA&...
(4) At the example.com, the request arrives at the open redirector. (4) At example.com, the request arrives at the open redirector. It
It will read the redirect parameter and will issue an HTTP 302 will read the redirect parameter and will issue an HTTP 303
Location header redirect to the URL "https://evil.example.com/ Location header redirect to the URL
cb". "https://client.evil.example/cb".
HTTP/1.1 302 Found HTTP/1.1 303 See Other
Location: https://client.evil.example/cb Location: https://client.evil.example/cb
(5) Since the redirector at client.somesite.example does not include (5) Since the redirector at client.somesite.example does not include
a fragment in the Location header, the user agent will re-attach a fragment in the Location header, the user agent will re-attach
the original fragment the original fragment
"#access_token=2YotnFZFEjr1zCsicMWpAA&..." to the URL and will "#access_token=2YotnFZFEjr1zCsicMWpAA&..." to the URL and will
navigate to the following URL: navigate to the following URL:
https://client.evil.example/cb#access_token=2YotnFZFEjr1zCsicMWpAA&... https://client.evil.example/cb#access_token=2YotnFZFEjr1zCsicMWpAA&...
skipping to change at page 10, line 31 skipping to change at page 11, line 13
response (see [oauth-v2-form-post-response-mode]). response (see [oauth-v2-form-post-response-mode]).
3.3. Attacks through the Browser History 3.3. Attacks through the Browser History
Authorization codes and access tokens can end up in the browser's Authorization codes and access tokens can end up in the browser's
history of visited URLs, enabling the attacks described in the history of visited URLs, enabling the attacks described in the
following. following.
3.3.1. Code in Browser History 3.3.1. Code in Browser History
When a browser navigates to "client.com/ When a browser navigates to "client.example/
redirection_endpoint?code=abcd" as a result of a redirect from a redirection_endpoint?code=abcd" as a result of a redirect from a
provider's authorization endpoint, the URL including the provider's authorization endpoint, the URL including the
authorization code may end up in the browser's history. An attacker authorization code may end up in the browser's history. An attacker
with access to the device could obtain the code and try to replay it. with access to the device could obtain the code and try to replay it.
Proposed countermeasures: Proposed countermeasures:
o Authorization code replay prevention as described in [RFC6819], o Authorization code replay prevention as described in [RFC6819],
Section 4.4.1.1, and Section 3.5 Section 4.4.1.1, and Section 3.5
o Use form post response mode instead of redirect for authorization o Use form post response mode instead of redirect for authorization
response (see [oauth-v2-form-post-response-mode]) response (see [oauth-v2-form-post-response-mode])
3.3.2. Access Token in Browser History 3.3.2. Access Token in Browser History
An access token may end up in the browser history if a a client or An access token may end up in the browser history if a a client or
just a web site, which already has a token, deliberately navigates to just a web site, which already has a token, deliberately navigates to
a page like "provider.com/get_user_profile?access_token=abcdef.". a page like "provider.com/get_user_profile?access_token=abcdef.".
Actually [RFC6750]discourages this practice and asks to transfer Actually [RFC6750] discourages this practice and asks to transfer
tokens via a header, but in practice web sites often just pass access tokens via a header, but in practice web sites often just pass access
token in query parameters. token in query parameters.
In case of implicit grant, a URL like "client.com/ In case of implicit grant, a URL like "client.example/
redirection_endpoint#access_token=abcdef" may also end up in the redirection_endpoint#access_token=abcdef" may also end up in the
browser history as a result of a redirect from a provider's browser history as a result of a redirect from a provider's
authorization endpoint. authorization endpoint.
Proposed countermeasures: Proposed countermeasures:
o Replace implicit flow with postmessage communication or the o Replace implicit flow with postmessage communication or the
authorization code grant authorization code grant
o Never pass access tokens in URL query parameters o Never pass access tokens in URL query parameters
skipping to change at page 12, line 21 skipping to change at page 12, line 48
(1) The user selects to start the grant using H-AS (e.g., by (1) The user selects to start the grant using H-AS (e.g., by
clicking on a button at the client's website). clicking on a button at the client's website).
(2) The attacker intercepts this request and changes the user's (2) The attacker intercepts this request and changes the user's
selection to "A-AS". selection to "A-AS".
(3) The client stores in the user's session that the user selected (3) The client stores in the user's session that the user selected
"A-AS" and redirects the user to A-AS's authorization endpoint "A-AS" and redirects the user to A-AS's authorization endpoint
by sending the following response: by sending the following response:
HTTP/1.1 302 Found HTTP/1.1 303 See Other
Location: https://attacker.example/authorize?response_type=code&client_id=666RVZJTA Location: https://attacker.example/authorize?response_type=code&client_id=666RVZJTA
(4) Now the attacker intercepts this response and changes the (4) Now the attacker intercepts this response and changes the
redirection such that the user is being redirected to H-AS. The redirection such that the user is being redirected to H-AS. The
attacker also replaces the client id of the client at A-AS with attacker also replaces the client id of the client at A-AS with
the client's id at H-AS, resulting in the following response the client's id at H-AS, resulting in the following response
being sent to the browser: being sent to the browser:
HTTP/1.1 302 Found HTTP/1.1 303 See Other
Location: https://honest.as.example/authorize?response_type=code&client_id=7ZGZldHQ Location: https://honest.as.example/authorize?response_type=code&client_id=7ZGZldHQ
(5) Now, the user authorizes the client to access her resources at (5) Now, the user authorizes the client to access her resources at
H-AS. H-AS issues a code and sends it (via the browser) back to H-AS. H-AS issues a code and sends it (via the browser) back to
the client. the client.
(6) Since the client still assumes that the code was issued by A-AS, (6) Since the client still assumes that the code was issued by A-AS,
it will try to redeem the code at A-AS's token endpoint. it will try to redeem the code at A-AS's token endpoint.
(7) The attacker therefore obtains code and can either exchange the (7) The attacker therefore obtains code and can either exchange the
skipping to change at page 19, line 5 skipping to change at page 19, line 26
3.7.1.1. Metadata 3.7.1.1. Metadata
An authorization server could provide the client with additional An authorization server could provide the client with additional
information about the location where it is safe to use its access information about the location where it is safe to use its access
tokens. tokens.
In the simplest form, this would require the AS to publish a list of In the simplest form, this would require the AS to publish a list of
its known resource servers, illustrated in the following example its known resource servers, illustrated in the following example
using a metadata parameter "resource_servers": using a metadata parameter "resource_servers":
HTTP/1.1 200 OK HTTP/1.1 200 OK
Content-Type: application/json Content-Type: application/json
{ {
"issuer":"https://server.somesite.example", "issuer":"https://server.somesite.example",
"authorization_endpoint":"https://server.somesite.example/authorize", "authorization_endpoint":
"resource_servers":[ "https://server.somesite.example/authorize",
"email.somesite.example", "resource_servers":[
"storage.somesite.example", "email.somesite.example",
"video.somesite.example"] "storage.somesite.example",
... "video.somesite.example"]
} ...
}
The AS could also return the URL(s) an access token is good for in The AS could also return the URL(s) an access token is good for in
the token response, illustrated by the example return parameter the token response, illustrated by the example return parameter
"access_token_resource_server": "access_token_resource_server":
HTTP/1.1 200 OK HTTP/1.1 200 OK
Content-Type: application/json;charset=UTF-8 Content-Type: application/json;charset=UTF-8
Cache-Control: no-store Cache-Control: no-store
Pragma: no-cache Pragma: no-cache
{ {
"access_token":"2YotnFZFEjr1zCsicMWpAA", "access_token":"2YotnFZFEjr1zCsicMWpAA",
"access_token_resource_server":"https://hostedresource.somesite.example/path1", "access_token_resource_server":
... "https://hostedresource.somesite.example/path1",
} ...
}
This mitigation strategy would rely on the client to enforce the This mitigation strategy would rely on the client to enforce the
security policy and to only send access tokens to legitimate security policy and to only send access tokens to legitimate
destinations. Results of OAuth related security research (see for destinations. Results of OAuth related security research (see for
example [oauth_security_ubc] and [oauth_security_cmu]) indicate a example [oauth_security_ubc] and [oauth_security_cmu]) indicate a
large portion of client implementations do not or fail to properly large portion of client implementations do not or fail to properly
implement security controls, like "state" checks. So relying on implement security controls, like "state" checks. So relying on
clients to prevent access token phishing is likely to fail as well. clients to prevent access token phishing is likely to fail as well.
Moreover given the ratio of clients to authorization and resource Moreover given the ratio of clients to authorization and resource
servers, it is considered the more viable approach to move as much as servers, it is considered the more viable approach to move as much as
skipping to change at page 22, line 44 skipping to change at page 23, line 34
legitimate resource server (which has a different URL), the resource legitimate resource server (which has a different URL), the resource
server will detect the mismatch (wrong audience) and refuse to serve server will detect the mismatch (wrong audience) and refuse to serve
the request. the request.
In deployments where the authorization server knows the URLs of all In deployments where the authorization server knows the URLs of all
resource servers, the authorization server may just refuse to issue resource servers, the authorization server may just refuse to issue
access tokens for unknown resource server URLs. access tokens for unknown resource server URLs.
The client needs to tell the authorization server, at which URL it The client needs to tell the authorization server, at which URL it
will use the access token it is requesting. It could use the will use the access token it is requesting. It could use the
mechanism proposed [I-D.campbell-oauth-resource-indicators] or encode mechanism proposed [I-D.ietf-oauth-resource-indicators] or encode the
the information in the scope value. information in the scope value.
Instead of the URL, it is also possible to utilize the fingerprint of Instead of the URL, it is also possible to utilize the fingerprint of
the resource server's X.509 certificate as audience value. This the resource server's X.509 certificate as audience value. This
variant would also allow to detect an attempt to spoof the legit variant would also allow to detect an attempt to spoof the legit
resource server's URL by using a valid TLS certificate obtained from resource server's URL by using a valid TLS certificate obtained from
a different CA. It might also be considered a privacy benefit to a different CA. It might also be considered a privacy benefit to
hide the resource server URL from the authorization server. hide the resource server URL from the authorization server.
Audience restriction seems easy to use since it does not require any Audience restriction seems easy to use since it does not require any
crypto on the client side. But since every access token is bound to crypto on the client side. But since every access token is bound to
skipping to change at page 24, line 47 skipping to change at page 25, line 37
The AS MUST take precautions to prevent this threat. Based on its The AS MUST take precautions to prevent this threat. Based on its
risk assessment the AS needs to decide whether it can trust the risk assessment the AS needs to decide whether it can trust the
redirect URI or not and SHOULD only automatically redirect the user redirect URI or not and SHOULD only automatically redirect the user
agent, if it trusts the redirect URI. If not, it MAY inform the user agent, if it trusts the redirect URI. If not, it MAY inform the user
that it is about to redirect her to the another site and rely on the that it is about to redirect her to the another site and rely on the
user to decide or MAY just inform the user about the error. user to decide or MAY just inform the user about the error.
3.8.2. Clients as Open Redirector 3.8.2. Clients as Open Redirector
Client MUST not expose URLs which could be utilized as open Client MUST NOT expose URLs which could be utilized as open
redirector. Attackers may use an open redirector to produce URLs redirector. Attackers may use an open redirector to produce URLs
which appear to point to the client, which might trick users to trust which appear to point to the client, which might trick users to trust
the URL and follow it in her browser. Another abuse case is to the URL and follow it in her browser. Another abuse case is to
produce URLs pointing to the client and utilize them to impersonate a produce URLs pointing to the client and utilize them to impersonate a
client with an authorization server. client with an authorization server.
In order to prevent open redirection, clients should only expose such In order to prevent open redirection, clients should only expose such
a function, if the target URLs are whitelisted or if the origin of a a function, if the target URLs are whitelisted or if the origin of a
request can be authenticated. request can be authenticated.
3.9. TLS Terminating Reverse Proxies 3.9. 307 Redirect
At the authorization endpoint, a typical protocol flow is that the AS
prompts the user to enter her credentials in a form that is then
submitted (using the HTTP POST method) back to the authorization
server. The AS checks the credentials and, if successful, redirects
the user agent to the client's redirection endpoint.
In [RFC6749], the HTTP status code 302 is used for this purpose, but
"any other method available via the user-agent to accomplish this
redirection is allowed". However, when the status code 307 is used
for redirection, the user agent will send the form data (user
credentials) via HTTP POST to the client since this status code does
not require the user agent to rewrite the POST request to a GET
request (and thereby dropping the form data in the POST request
body). If the relying party is malicious, it can use the credentials
to impersonate the user at the AS.
In the HTTP standard [RFC6749], only the status code 303
unambigiously enforces rewriting the HTTP POST request to an HTTP GET
request. For all other status codes, including the popular 302, user
agents can opt not to rewrite POST to GET requests and therefore to
reveal the user credentials to the client. (In practice, however,
most user agents will only show this behaviour for 307 redirects.)
AS which redirect a request that potentially contains user
credentials therefore MUST not use the HTTP 307 status code for
redirection. If an HTTP redirection (and not, for example,
JavaScript) is used for such a request, AS SHOULD use HTTP status
code 303 "See Other".
3.10. TLS Terminating Reverse Proxies
A common deployment architecture for HTTP applications is to have the A common deployment architecture for HTTP applications is to have the
application server sitting behind a reverse proxy, which terminates application server sitting behind a reverse proxy, which terminates
the TLS connection and dispatches the incoming requests to the the TLS connection and dispatches the incoming requests to the
respective application server nodes. respective application server nodes.
This section highlights some attack angles of this deployment This section highlights some attack angles of this deployment
architecture, which are relevant to OAuth, and give recommendations architecture, which are relevant to OAuth, and give recommendations
for security controls. for security controls.
skipping to change at page 25, line 49 skipping to change at page 27, line 23
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).
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, and Brian Campbell for their valuable Mainka, Doug McDorman, Johan Peeters, and Brian Campbell for their
feedback. 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.
7. References 7. References
7.1. Normative References 7.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66, Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, DOI 10.17487/RFC3986, January 2005, RFC 3986, DOI 10.17487/RFC3986, January 2005,
<https://www.rfc-editor.org/info/rfc3986>. <https://www.rfc-editor.org/info/rfc3986>.
[RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework",
RFC 6749, DOI 10.17487/RFC6749, October 2012, RFC 6749, DOI 10.17487/RFC6749, October 2012,
<https://www.rfc-editor.org/info/rfc6749>. <https://www.rfc-editor.org/info/rfc6749>.
[RFC6750] Jones, M. and D. Hardt, "The OAuth 2.0 Authorization [RFC6750] Jones, M. and D. Hardt, "The OAuth 2.0 Authorization
skipping to change at page 27, line 32 skipping to change at page 29, line 5
[fb_fragments] [fb_fragments]
"Facebook Developer Blog", "Facebook Developer Blog",
<https://developers.facebook.com/blog/post/552/>. <https://developers.facebook.com/blog/post/552/>.
[I-D.bradley-oauth-jwt-encoded-state] [I-D.bradley-oauth-jwt-encoded-state]
Bradley, J., Lodderstedt, T., and H. Zandbelt, "Encoding Bradley, J., Lodderstedt, T., and H. Zandbelt, "Encoding
claims in the OAuth 2 state parameter using a JWT", draft- claims in the OAuth 2 state parameter using a JWT", draft-
bradley-oauth-jwt-encoded-state-08 (work in progress), bradley-oauth-jwt-encoded-state-08 (work in progress),
January 2018. January 2018.
[I-D.campbell-oauth-resource-indicators]
Campbell, B., Bradley, J., and H. Tschofenig, "Resource
Indicators for OAuth 2.0", draft-campbell-oauth-resource-
indicators-02 (work in progress), November 2016.
[I-D.ietf-oauth-closing-redirectors] [I-D.ietf-oauth-closing-redirectors]
Bradley, J., Sanso, A., and H. Tschofenig, "OAuth 2.0 Bradley, J., Sanso, A., and H. Tschofenig, "OAuth 2.0
Security: Closing Open Redirectors in OAuth", draft-ietf- Security: Closing Open Redirectors in OAuth", draft-ietf-
oauth-closing-redirectors-00 (work in progress), February oauth-closing-redirectors-00 (work in progress), February
2016. 2016.
[I-D.ietf-oauth-discovery]
Jones, M., Sakimura, N., and J. Bradley, "OAuth 2.0
Authorization Server Metadata", draft-ietf-oauth-
discovery-10 (work in progress), March 2018.
[I-D.ietf-oauth-jwsreq] [I-D.ietf-oauth-jwsreq]
Sakimura, N. and J. Bradley, "The OAuth 2.0 Authorization Sakimura, N. and J. Bradley, "The OAuth 2.0 Authorization
Framework: JWT Secured Authorization Request (JAR)", Framework: JWT Secured Authorization Request (JAR)",
draft-ietf-oauth-jwsreq-16 (work in progress), April 2018. draft-ietf-oauth-jwsreq-16 (work in progress), April 2018.
[I-D.ietf-oauth-mix-up-mitigation] [I-D.ietf-oauth-mix-up-mitigation]
Jones, M., Bradley, J., and N. Sakimura, "OAuth 2.0 Mix-Up Jones, M., Bradley, J., and N. Sakimura, "OAuth 2.0 Mix-Up
Mitigation", draft-ietf-oauth-mix-up-mitigation-01 (work Mitigation", draft-ietf-oauth-mix-up-mitigation-01 (work
in progress), July 2016. in progress), July 2016.
[I-D.ietf-oauth-mtls] [I-D.ietf-oauth-mtls]
Campbell, B., Bradley, J., Sakimura, N., and T. Campbell, B., Bradley, J., Sakimura, N., and T.
Lodderstedt, "OAuth 2.0 Mutual TLS Client Authentication Lodderstedt, "OAuth 2.0 Mutual TLS Client Authentication
and Certificate Bound Access Tokens", draft-ietf-oauth- and Certificate Bound Access Tokens", draft-ietf-oauth-
mtls-08 (work in progress), May 2018. mtls-10 (work in progress), July 2018.
[I-D.ietf-oauth-pop-key-distribution] [I-D.ietf-oauth-pop-key-distribution]
Bradley, J., Hunt, P., Jones, M., and H. Tschofenig, Bradley, J., Hunt, P., Jones, M., and H. Tschofenig,
"OAuth 2.0 Proof-of-Possession: Authorization Server to "OAuth 2.0 Proof-of-Possession: Authorization Server to
Client Key Distribution", draft-ietf-oauth-pop-key- Client Key Distribution", draft-ietf-oauth-pop-key-
distribution-03 (work in progress), February 2017. distribution-03 (work in progress), February 2017.
[I-D.ietf-oauth-resource-indicators]
Campbell, B., Bradley, J., and H. Tschofenig, "Resource
Indicators for OAuth 2.0", draft-ietf-oauth-resource-
indicators-00 (work in progress), August 2018.
[I-D.ietf-oauth-signed-http-request] [I-D.ietf-oauth-signed-http-request]
Richer, J., Bradley, J., and H. Tschofenig, "A Method for Richer, J., Bradley, J., and H. Tschofenig, "A Method for
Signing HTTP Requests for OAuth", draft-ietf-oauth-signed- Signing HTTP Requests for OAuth", draft-ietf-oauth-signed-
http-request-03 (work in progress), August 2016. http-request-03 (work in progress), August 2016.
[I-D.ietf-oauth-token-binding] [I-D.ietf-oauth-token-binding]
Jones, M., Campbell, B., Bradley, J., and W. Denniss, Jones, M., Campbell, B., Bradley, J., and W. Denniss,
"OAuth 2.0 Token Binding", draft-ietf-oauth-token- "OAuth 2.0 Token Binding", draft-ietf-oauth-token-
binding-06 (work in progress), March 2018. binding-07 (work in progress), June 2018.
[I-D.ietf-tokbind-https] [I-D.ietf-tokbind-https]
Popov, A., Nystrom, M., Balfanz, D., Langley, A., Harper, Popov, A., Nystrom, M., Balfanz, D., Langley, A., Harper,
N., and J. Hodges, "Token Binding over HTTP", draft-ietf- N., and J. Hodges, "Token Binding over HTTP", draft-ietf-
tokbind-https-14 (work in progress), May 2018. tokbind-https-18 (work in progress), June 2018.
[I-D.sakimura-oauth-jpop] [I-D.sakimura-oauth-jpop]
Sakimura, N., Li, K., and J. Bradley, "The OAuth 2.0 Sakimura, N., Li, K., and J. Bradley, "The OAuth 2.0
Authorization Framework: JWT Pop Token Usage", draft- Authorization Framework: JWT Pop Token Usage", draft-
sakimura-oauth-jpop-04 (work in progress), March 2017. sakimura-oauth-jpop-04 (work in progress), March 2017.
[oauth-v2-form-post-response-mode] [oauth-v2-form-post-response-mode]
Microsoft and Ping Identity, "OAuth 2.0 Form Post Response Microsoft and Ping Identity, "OAuth 2.0 Form Post Response
Mode", April 2015, <http://openid.net/specs/ Mode", April 2015, <http://openid.net/specs/
oauth-v2-form-post-response-mode-1_0.html>. oauth-v2-form-post-response-mode-1_0.html>.
skipping to change at page 29, line 39 skipping to change at page 31, line 10
[RFC7636] Sakimura, N., Ed., Bradley, J., and N. Agarwal, "Proof Key [RFC7636] Sakimura, N., Ed., Bradley, J., and N. Agarwal, "Proof Key
for Code Exchange by OAuth Public Clients", RFC 7636, for Code Exchange by OAuth Public Clients", RFC 7636,
DOI 10.17487/RFC7636, September 2015, DOI 10.17487/RFC7636, September 2015,
<https://www.rfc-editor.org/info/rfc7636>. <https://www.rfc-editor.org/info/rfc7636>.
[RFC7800] Jones, M., Bradley, J., and H. Tschofenig, "Proof-of- [RFC7800] Jones, M., Bradley, J., and H. Tschofenig, "Proof-of-
Possession Key Semantics for JSON Web Tokens (JWTs)", Possession Key Semantics for JSON Web Tokens (JWTs)",
RFC 7800, DOI 10.17487/RFC7800, April 2016, RFC 7800, DOI 10.17487/RFC7800, April 2016,
<https://www.rfc-editor.org/info/rfc7800>. <https://www.rfc-editor.org/info/rfc7800>.
[RFC8414] Jones, M., Sakimura, N., and J. Bradley, "OAuth 2.0
Authorization Server Metadata", RFC 8414,
DOI 10.17487/RFC8414, June 2018,
<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 ]]
-07
o incorporated findings of Doug McDorman
o added section on HTTP status codes for redirects
o added new section on access token privilege restriction based on
comments from Johan Peeters
-06 -06
o reworked section 3.8.1 o reworked section 3.8.1
o incorporated Phil Hunt's feedback o incorporated Phil Hunt's feedback
o reworked section on mix-up o reworked section on mix-up
o extended section on code leakage via referrer header to also cover o extended section on code leakage via referrer header to also cover
state leakage state leakage
o added Daniel Fett as author o added Daniel Fett as author
o replaced text intended to inform WG discussion by recommendations o replaced text intended to inform WG discussion by recommendations
to implementors to implementors
skipping to change at page 31, line 36 skipping to change at page 33, line 23
Yubico Yubico
Email: ve7jtb@ve7jtb.com Email: ve7jtb@ve7jtb.com
Andrey Labunets Andrey Labunets
Facebook Facebook
Email: isciurus@fb.com Email: isciurus@fb.com
Daniel Fett Daniel Fett
University of Stuttgart YES.com AG
Email: daniel.fett@sec.uni-stuttgart.de Email: mail@danielfett.de
 End of changes. 45 change blocks. 
95 lines changed or deleted 177 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/