draft-ietf-oauth-security-topics-08.txt   draft-ietf-oauth-security-topics-09.txt 
Open Authentication Protocol T. Lodderstedt, Ed. Open Authentication Protocol T. Lodderstedt, Ed.
Internet-Draft YES.com AG Internet-Draft yes.com
Intended status: Best Current Practice J. Bradley Intended status: Best Current Practice J. Bradley
Expires: April 18, 2019 Yubico Expires: May 13, 2019 Yubico
A. Labunets A. Labunets
Facebook Facebook
D. Fett D. Fett
YES.com AG yes.com
October 15, 2018 November 09, 2018
OAuth 2.0 Security Best Current Practice OAuth 2.0 Security Best Current Practice
draft-ietf-oauth-security-topics-08 draft-ietf-oauth-security-topics-09
Abstract Abstract
This document describes best current security practices for OAuth This document describes best current security practice for OAuth 2.0.
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
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 April 18, 2019. This Internet-Draft will expire on May 13, 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 18 skipping to change at page 2, line 18
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 . . . . . . . . . . . . . . . . . 5
2.3. Access Token Privilege Restriction . . . . . . . . . . . 5 2.3. Access Token Privilege Restriction . . . . . . . . . . . 6
3. Attacks and Mitigations . . . . . . . . . . . . . . . . . . . 6 3. Attacks and Mitigations . . . . . . . . . . . . . . . . . . . 6
3.1. Insufficient Redirect URI Validation . . . . . . . . . . 6 3.1. Insufficient Redirect URI Validation . . . . . . . . . . 6
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 . . . . . . . . . . . . . . 9
3.2. Code or State Leakage from Client or AS via Referrer 3.2. Credential Leakage via Referrer Headers . . . . . . . . . 10
Headers . . . . . . . . . . . . . . . . . . . . . . . . . 10 3.2.1. Leakage from the OAuth client . . . . . . . . . . . . 10
3.2.1. Proposed Countermeasures . . . . . . . . . . . . . . 10 3.2.2. Leakage from the Authorization Server . . . . . . . . 10
3.3. Attacks through the Browser History . . . . . . . . . . . 11 3.2.3. Consequences . . . . . . . . . . . . . . . . . . . . 11
3.3.1. Code in Browser History . . . . . . . . . . . . . . . 11 3.2.4. Proposed Countermeasures . . . . . . . . . . . . . . 11
3.3. Attacks through the 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 . . . . . . . . . . . . . . . . . . . . . . . . . 12 3.4. Mix-Up . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.4.1. Attack Description . . . . . . . . . . . . . . . . . 12 3.4.1. Attack Description . . . . . . . . . . . . . . . . . 13
3.4.2. Countermeasures . . . . . . . . . . . . . . . . . . . 14 3.4.2. Countermeasures . . . . . . . . . . . . . . . . . . . 15
3.5. Code Injection . . . . . . . . . . . . . . . . . . . . . 15 3.5. Authorization Code Injection . . . . . . . . . . . . . . 15
3.5.1. Proposed Countermeasures . . . . . . . . . . . . . . 17 3.5.1. Proposed Countermeasures . . . . . . . . . . . . . . 17
3.6. Cross Site Request Forgery . . . . . . . . . . . . . . . 18 3.6. Access Token Injection . . . . . . . . . . . . . . . . . 19
3.6.1. Proposed Countermeasures . . . . . . . . . . . . . . 18 3.6.1. Proposed Countermeasures . . . . . . . . . . . . . . 19
3.7. Access Token Leakage at the Resource Server . . . . . . . 19 3.7. Cross Site Request Forgery . . . . . . . . . . . . . . . 19
3.7.1. Access Token Phishing by Counterfeit Resource Server 19 3.7.1. Proposed Countermeasures . . . . . . . . . . . . . . 20
3.7.1.1. Metadata . . . . . . . . . . . . . . . . . . . . 19 3.8. Access Token Leakage at the Resource Server . . . . . . . 20
3.7.1.2. Sender Constrained Access Tokens . . . . . . . . 21 3.8.1. Access Token Phishing by Counterfeit Resource Server 20
3.7.1.3. Audience Restricted Access Tokens . . . . . . . . 23 3.8.1.1. Metadata . . . . . . . . . . . . . . . . . . . . 20
3.7.2. Compromised Resource Server . . . . . . . . . . . . . 24 3.8.1.2. Sender Constrained Access Tokens . . . . . . . . 22
3.8. Open Redirection . . . . . . . . . . . . . . . . . . . . 25 3.8.1.3. Audience Restricted Access Tokens . . . . . . . . 24
3.8.1. Authorization Server as Open Redirector . . . . . . . 25 3.8.2. Compromised Resource Server . . . . . . . . . . . . . 25
3.8.2. Clients as Open Redirector . . . . . . . . . . . . . 26 3.9. Open Redirection . . . . . . . . . . . . . . . . . . . . 26
3.9. 307 Redirect . . . . . . . . . . . . . . . . . . . . . . 26 3.9.1. Authorization Server as Open Redirector . . . . . . . 26
3.10. TLS Terminating Reverse Proxies . . . . . . . . . . . . . 27 3.9.2. Clients as Open Redirector . . . . . . . . . . . . . 27
4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 27 3.10. 307 Redirect . . . . . . . . . . . . . . . . . . . . . . 27
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 3.11. TLS Terminating Reverse Proxies . . . . . . . . . . . . . 28
6. Security Considerations . . . . . . . . . . . . . . . . . . . 28
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 28 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 28
7.1. Normative References . . . . . . . . . . . . . . . . . . 28 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28
7.2. Informative References . . . . . . . . . . . . . . . . . 28 6. Security Considerations . . . . . . . . . . . . . . . . . . . 29
Appendix A. Document History . . . . . . . . . . . . . . . . . . 31 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 29
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 33 7.1. Normative References . . . . . . . . . . . . . . . . . . 29
7.2. Informative References . . . . . . . . . . . . . . . . . 29
Appendix A. Document History . . . . . . . . . . . . . . . . . . 33
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 35
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 5, line 26 skipping to change at page 5, line 30
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 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.1.2. Implicit Grant 2.1.2. Implicit Grant
Clients utilizing the implicit grant SHALL either use The implicit grant (response type "token") and other response types
[I-D.ietf-oauth-token-binding] in order to allow the RS to detect and causing the authorization server to issue access tokens in the
prevent attempts to inject (replay) access tokens or consider use of authorization response are vulnerable to access token leakage and
alternative grant types supporting injection detection, such as access token replay as described in Section 3.1, Section 3.2,
Section 3.3, and Section 3.6.
o Authorization code grant type in conjunction with PKCE as In order to avoid these issues, Clients SHOULD NOT use the implicit
specified above grant and any other response type causing the authorization server to
issue an access token in the authorization response.
o OpenID Connect with response type "token id_token" and the "nonce" Clients SHOULD instead use the response type "code" (aka
parameter authorization code grant type) as specified in Section 2.1.1 or any
other response type that does not cause the authorization server to
issue access tokens in the authorization response.
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.7.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
The privileges associated with an access token SHOULD be restricted The privileges associated with an access token SHOULD be restricted
to the minimum required for the particular application or use case. to the minimum required for the particular application or use case.
This prevents clients from exceeding the privileges authorized by the This prevents clients from exceeding the privileges authorized by the
resource owner. It also prevents users from exceeding their resource owner. It also prevents users from exceeding their
skipping to change at page 8, line 10 skipping to change at page 8, line 18
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 impersonate or utilize client's secret. The attacker will need to impersonate or utilize
the legitimate client to redeem the code (e.g., by performing a code the legitimate client to redeem the code (e.g., by performing a code
injection attack). This kind of injections is covered in injection attack). This kind of injections is covered in
Section Code Injection. Section Authorization 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
attacks. It utilizes the fact that user agents re-attach fragments attacks. It utilizes the fact that user agents re-attach fragments
skipping to change at page 9, line 45 skipping to change at page 10, line 6
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 shall 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.8). 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.
o Clients SHOULD use the authorization code response type instead of
response types causing access token issuance at the authorization
endpoint. This offers countermeasures against reuse of leaked
credentials through the exchange process with the authorization
server and token replay through certificate binding of the access
tokens.
As an alternative to exact redirect URI matching, the AS could also As an alternative to exact redirect URI matching, the AS could also
authenticate clients, e.g., using [I-D.ietf-oauth-jwsreq]. authenticate clients, e.g., using [I-D.ietf-oauth-jwsreq].
3.2. Code or State Leakage from Client or AS via Referrer Headers 3.2. Credential Leakage via Referrer Headers
Authorization codes or values of "state" can unintentionally be Authorization codes or values of "state" can unintentionally be
disclosed to attackers through the referrer header, by leaking either disclosed to attackers through the referrer header, by leaking either
from a client's web site or from an AS's web site. from a client's web site or from an AS's web site. Note: even if
specified otherwise in [RFC2616], section 14.36, the same may happen
to access tokens conveyed in URI fragments due to browser
implementation issues as illustrated by Chromium Issue 168213
[bug.chromium].
Leakage from OAuth client: This requires that the client, as a result 3.2.1. Leakage from the OAuth client
of a successful authorization request, renders a page that
This requires that the client, as a result of a successful
authorization request, renders a page that
o contains links to other pages under the attacker's control (ads, o contains links to other pages under the attacker's control (ads,
faq, ...) and a user clicks on such a link, or faq, ...) and a user clicks on such a link, or
o includes third-party content (iframes, images, etc.) for example o includes third-party content (iframes, images, etc.) for example
if the page contains user-generated content (blog). if the page contains user-generated content (blog).
As soon as the browser navigates to the attacker's page or loads the As soon as the browser navigates to the attacker's page or loads the
third-party content, the attacker receives the authorization response third-party content, the attacker receives the authorization response
URL and can extract "code" or "state". URL and can extract "code", "access token", or "state".
Leakage from AS: In a similar way, an attacker can learn "state" if 3.2.2. Leakage from the Authorization Server
the authorization endpoint at the authorization server contains links
or third-party content as above.
Consequences: An attacker that learns a valid code through a referrer In a similar way, an attacker can learn "state" if the authorization
header can perform the same attacks as described in endpoint at the authorization server contains links or third-party
Section Section 3.1.1. If the attacker learns "state", the CSRF content as above.
protection achieved by using "state" is lost, resulting in CSRF
attacks as described in [RFC6819], Section 4.4.1.8..
3.2.1. Proposed Countermeasures 3.2.3. Consequences
An attacker that learns a valid code or access token through a
referrer header can perform the attacks as described in
Section 3.1.1, Section 3.5, and Section 3.6. If the attacker learns
"state", the CSRF protection achieved by using "state" is lost,
resulting in CSRF attacks as described in [RFC6819],
Section 4.4.1.8..
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 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
skipping to change at page 11, line 24 skipping to change at page 11, line 49
o Bind authorization code to a confidential client or PKCE o Bind authorization code to a confidential client or PKCE
challenge. In this case, the attacker lacks the secret to request challenge. In this case, the attacker lacks the secret to request
the code exchange. 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 form post response mode instead of redirect for authorization o Use authorization code instead of response types causing access
response (see [oauth-v2-form-post-response-mode]). token issuance from the authorization endpoint. This provides
countermeasures against leakage on the OAuth protocol level
through the code exchange process with the authorization server.
o Additionally, one might use the form post response mode instead of
redirect for authorization 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.example/ When a browser navigates to "client.example/
skipping to change at page 13, line 49 skipping to change at page 14, line 26
(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
code for an access token (for public clients) or perform a code code for an access token (for public clients) or perform a code
injection attack as described in Section Section 3.5. injection attack as described in Section 3.5.
Variants: Variants:
Implicit Grant In the implicit grant, the attacker receives an Implicit Grant In the implicit grant, the attacker receives an
access token instead of the code; the rest of the attack access token instead of the code; the rest of the attack
works as above. works as above.
Mix-Up Without Interception A variant of the above attack works even Mix-Up Without Interception A variant of the above attack works even
if the first request/response pair cannot be intercepted (for if the first request/response pair cannot be intercepted (for
example, because TLS is used to protect these messages): example, because TLS is used to protect these messages):
skipping to change at page 15, line 8 skipping to change at page 15, line 34
response, it carries client id and issuer. It can be used for response, it carries client id and issuer. It can be used for
this mitigation. this mitigation.
o As it can be seen in the preconditions of the attacks above, o As it can be seen in the preconditions of the attacks above,
clients can prevent mix-up attack by (1) using AS-specific clients can prevent mix-up attack by (1) using AS-specific
redirect URIs with exact redirect URI matching, (2) storing, for redirect URIs with exact redirect URI matching, (2) storing, for
each authorization request, the intended AS, and (3) comparing the each authorization request, the intended AS, and (3) comparing the
intended AS with the actual redirect URI where the authorization intended AS with the actual redirect URI where the authorization
response was received. response was received.
3.5. Code Injection 3.5. Authorization Code Injection
In such an attack, the adversary attempts to inject a stolen In such an attack, the adversary attempts to inject a stolen
authorization code into a legitimate client on a device under his authorization code into a legitimate client on a device under his
control. In the simplest case, the attacker would want to use the control. In the simplest case, the attacker would want to use the
code in his own client. But there are situations where this might code in his own client. But there are situations where this might
not be possible or intended. Examples are: not be possible or intended. Examples are:
o The attacker wants to access certain functions in this particular o The attacker wants to access certain functions in this particular
client. As an example, the attacker wants to impersonate his client. As an example, the attacker wants to impersonate his
victim in a certain app or on a certain web site. victim in a certain app or on a certain web site.
skipping to change at page 18, line 40 skipping to change at page 19, line 15
control, which is then used in the victim's authorization request. control, which is then used in the victim's authorization request.
Exact redirect URI matching of authorization requests can prevent the Exact redirect URI matching of authorization requests can prevent the
attacker from using the pre-warmed secret in the faked authorization attacker from using the pre-warmed secret in the faked authorization
transaction on the victim's device. transaction on the victim's device.
Unfortunately, it does not work for all kinds of OAuth clients. It Unfortunately, it does not work for all kinds of OAuth clients. It
is effective for web and JS apps and for native apps with claimed is effective for web and JS apps and for native apps with claimed
URLs. Attacks on native apps using custom schemes or redirect URIs URLs. Attacks on native apps using custom schemes or redirect URIs
on localhost cannot be prevented this way, except if the AS enforces on localhost cannot be prevented this way, except if the AS enforces
one-time use for PKCE verifier or "nonce" values. one-time use for PKCE verifier or "nonce" values.
3.6. Cross Site Request Forgery 3.6. Access Token Injection
In such an attack, the adversary attempts to inject a stolen access
token into a legitimate client on a device under his control. This
will typically happen if the attacker wants to utilize a leaked
access token to impersonate a user in a certain client.
To conduct the attack, the adversary starts an OAuth flow with the
client and modifies the authorization response by replacing the
access token issued by the authorization server or directly makes up
an authorization server response including the leaked access token.
Since the response includes the state value generated by the client
for this particular transaction, the client does not treat the
response as a CSRF and will use the access token injected by the
attacker.
3.6.1. Proposed Countermeasures
There is no way to detect such an injection attack on the OAuth
protocol level, since the token is issued without any binding to the
transaction or the particular user agent.
The recommendation is therefore to use the authorization code grant
type instead of relying on response types issuing acess tokens at the
authorization endpoint. Code injection can be detected using one of
the countermeasures discussed in Section 3.5.
3.7. Cross Site Request Forgery
An attacker might attempt to inject a request to the redirect URI of An attacker might attempt to inject a request to the redirect URI of
the legitimate client on the victim's device, e.g., to cause the the legitimate client on the victim's device, e.g., to cause the
client to access resources under the attacker's control. client to access resources under the attacker's control.
3.6.1. Proposed Countermeasures 3.7.1. Proposed Countermeasures
Standard CSRF defenses should be used to protect the redirection Standard CSRF defenses should be used to protect the redirection
endpoint, for example: endpoint, for example:
CSRF Tokens Use of CSRF tokens which are bound to the user agent CSRF Tokens Use of CSRF tokens which are bound to the user agent
and passed in the "state" parameter to the and passed in the "state" parameter to the
authorization server. authorization server.
Origin Header The Origin header can be used to detect and prevent Origin Header The Origin header can be used to detect and prevent
CSRF attacks. Since this feature, at the time of CSRF attacks. Since this feature, at the time of
writing, is not consistently supported by all writing, is not consistently supported by all
browsers, CSRF tokens should be used in addition to browsers, CSRF tokens should be used in addition to
Origin header checking. Origin header checking.
For more details see [owasp_csrf]. For more details see [owasp_csrf].
3.7. Access Token Leakage at the Resource Server 3.8. Access Token Leakage at the Resource Server
Access tokens can leak from a resource server under certain Access tokens can leak from a resource server under certain
circumstances. circumstances.
3.7.1. Access Token Phishing by Counterfeit Resource Server 3.8.1. Access Token Phishing by Counterfeit Resource Server
An attacker may setup his own resource server and trick a client into An attacker may setup his own resource server and trick a client into
sending access tokens to it, which are valid for other resource sending access tokens to it, which are valid for other resource
servers. If the client sends a valid access token to this servers. If the client sends a valid access token to this
counterfeit resource server, the attacker in turn may use that token counterfeit resource server, the attacker in turn may use that token
to access other services on behalf of the resource owner. to access other services on behalf of the resource owner.
This attack assumes the client is not bound to a certain resource This attack assumes the client is not bound to a certain resource
server (and the respective URL) at development time, but client server (and the respective URL) at development time, but client
instances are configured with an resource server's URL at runtime. instances are configured with an resource server's URL at runtime.
This kind of late binding is typical in situations where the client This kind of late binding is typical in situations where the client
uses a standard API, e.g., for e-Mail, calendar, health, or banking uses a standard API, e.g., for e-Mail, calendar, health, or banking
and is configured by an user or administrator for the standard-based and is configured by an user or administrator for the standard-based
service, this particular user or company uses. service, this particular user or company uses.
There are several potential mitigation strategies, which will be There are several potential mitigation strategies, which will be
discussed in the following sections. discussed in the following sections.
3.7.1.1. Metadata 3.8.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
skipping to change at page 21, line 5 skipping to change at page 22, line 5
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
possible security-related logic to those entities. Clearly, the possible security-related logic to those entities. Clearly, the
client has to contribute to the overall security. But there are client has to contribute to the overall security. But there are
alternative countermeasures, as described in the next sections, which alternative countermeasures, as described in the next sections, which
provide a better balance between the involved parties. provide a better balance between the involved parties.
3.7.1.2. Sender Constrained Access Tokens 3.8.1.2. Sender Constrained Access Tokens
As the name suggests, sender constrained access token scope the As the name suggests, sender constrained access token scope the
applicability of an access token to a certain sender. This sender is applicability of an access token to a certain sender. This sender is
obliged to demonstrate knowledge of a certain secret as prerequisite obliged to demonstrate knowledge of a certain secret as prerequisite
for the acceptance of that token at a resource server. for the acceptance of that token at a resource server.
A typical flow looks like this: A typical flow looks like this:
1. The authorization server associates data with the access token 1. The authorization server associates data with the access token
which binds this particular token to a certain client. The which binds this particular token to a certain client. The
skipping to change at page 23, line 22 skipping to change at page 24, line 22
As one advantage, application-level signing allows for end-to-end As one advantage, application-level signing allows for end-to-end
protection including non-repudiation even if the TLS connection is protection including non-repudiation even if the TLS connection is
terminated between client and resource server. But deployment terminated between client and resource server. But deployment
experiences have revealed challenges regarding robustness (e.g., experiences have revealed challenges regarding robustness (e.g.,
reproduction of the signature base string including correct URL) as reproduction of the signature base string including correct URL) as
well as state management (e.g., replay prevention). well as state management (e.g., replay prevention).
This document therefore recommends implementors to consider one of This document therefore recommends implementors to consider one of
TLS-based approaches wherever possible. TLS-based approaches wherever possible.
3.7.1.3. Audience Restricted Access Tokens 3.8.1.3. Audience Restricted Access Tokens
An audience restriction essentially restricts the resource server a An audience restriction essentially restricts the resource server a
particular access token can be used at. The authorization server particular access token can be used at. The authorization server
associates the access token with a certain resource server and every associates the access token with a certain resource server and every
resource server is obliged to verify for every request, whether the resource server is obliged to verify for every request, whether the
access token sent with that request was meant to be used at the access token sent with that request was meant to be used at the
particular resource server. If not, the resource server must refuse particular resource server. If not, the resource server must refuse
to serve the respective request. In the general case, audience to serve the respective request. In the general case, audience
restrictions limit the impact of a token leakage. In the case of a restrictions limit the impact of a token leakage. In the case of a
counterfeit resource server, it may (as described see below) also counterfeit resource server, it may (as described see below) also
skipping to change at page 24, line 32 skipping to change at page 25, line 32
It shall be noted that audience restrictions, or generally speaking It shall be noted that audience restrictions, or generally speaking
an indication by the client to the authorization server where it an indication by the client to the authorization server where it
wants to use the access token, has additional benefits beyond the wants to use the access token, has additional benefits beyond the
scope of token leakage prevention. It allows the authorization scope of token leakage prevention. It allows the authorization
server to create different access token whose format and content is server to create different access token whose format and content is
specifically minted for the respective server. This has huge specifically minted for the respective server. This has huge
functional and privacy advantages in deployments using structured functional and privacy advantages in deployments using structured
access tokens. access tokens.
3.7.2. Compromised Resource Server 3.8.2. Compromised Resource Server
An attacker may compromise a resource server in order to get access An attacker may compromise a resource server in order to get access
to its resources and other resources of the respective deployment. to its resources and other resources of the respective deployment.
Such a compromise may range from partial access to the system, e.g., Such a compromise may range from partial access to the system, e.g.,
its logfiles, to full control of the respective server. its logfiles, to full control of the respective server.
If the attacker was able to take over full control including shell If the attacker was able to take over full control including shell
access it will be able to circumvent all controls in place and access access it will be able to circumvent all controls in place and access
resources without access control. It will also get access to access resources without access control. It will also get access to access
tokens, which are sent to the compromised system and which tokens, which are sent to the compromised system and which
skipping to change at page 25, line 14 skipping to change at page 26, line 14
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 shall be taken into account by implementors in
order to cope with access token replay: 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.7.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.
o Audience restriction as described in Section 3.7.1.3 may be used o Audience restriction as described in Section 3.8.1.3 may be used
to prevent replay of captured access tokens on other resource to prevent replay of captured access tokens on other resource
servers. servers.
3.8. Open Redirection 3.9. Open Redirection
The following attacks can occur when an AS or client has an open The following attacks can occur when an AS or client has an open
redirector, i.e., a URL which causes an HTTP redirect to an attacker- redirector, i.e., a URL which causes an HTTP redirect to an attacker-
controlled web site. controlled web site.
3.8.1. Authorization Server as Open Redirector 3.9.1. Authorization Server as Open Redirector
Attackers could try to utilize a user's trust in the authorization Attackers could try to utilize a user's trust in the authorization
server (and its URL in particular) for performing phishing attacks. server (and its URL in particular) for performing phishing attacks.
[RFC6749], Section 4.1.2.1, already prevents open redirects by [RFC6749], Section 4.1.2.1, already prevents open redirects by
stating the AS MUST NOT automatically redirect the user agent in case stating the AS MUST NOT automatically redirect the user agent in case
of an invalid combination of client_id and redirect_uri. of an invalid combination of client_id and redirect_uri.
However, as described in [I-D.ietf-oauth-closing-redirectors], an However, as described in [I-D.ietf-oauth-closing-redirectors], an
attacker could also utilize a correctly registered redirect URI to attacker could also utilize a correctly registered redirect URI to
skipping to change at page 26, line 7 skipping to change at page 27, line 7
value, to cause the AS to automatically redirect the user agent to value, to cause the AS to automatically redirect the user agent to
its phishing site. its phishing site.
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.9.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. 307 Redirect 3.10. 307 Redirect
At the authorization endpoint, a typical protocol flow is that the AS 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 prompts the user to enter her credentials in a form that is then
submitted (using the HTTP POST method) back to the authorization submitted (using the HTTP POST method) back to the authorization
server. The AS checks the credentials and, if successful, redirects server. The AS checks the credentials and, if successful, redirects
the user agent to the client's redirection endpoint. the user agent to the client's redirection endpoint.
In [RFC6749], the HTTP status code 302 is used for this purpose, but In [RFC6749], the HTTP status code 302 is used for this purpose, but
"any other method available via the user-agent to accomplish this "any other method available via the user-agent to accomplish this
redirection is allowed". However, when the status code 307 is used redirection is allowed". However, when the status code 307 is used
skipping to change at page 27, line 5 skipping to change at page 28, line 5
agents can opt not to rewrite POST to GET requests and therefore to agents can opt not to rewrite POST to GET requests and therefore to
reveal the user credentials to the client. (In practice, however, reveal the user credentials to the client. (In practice, however,
most user agents will only show this behaviour for 307 redirects.) most user agents will only show this behaviour for 307 redirects.)
AS which redirect a request that potentially contains user AS which redirect a request that potentially contains user
credentials therefore MUST not use the HTTP 307 status code for credentials therefore MUST not use the HTTP 307 status code for
redirection. If an HTTP redirection (and not, for example, redirection. If an HTTP redirection (and not, for example,
JavaScript) is used for such a request, AS SHOULD use HTTP status JavaScript) is used for such a request, AS SHOULD use HTTP status
code 303 "See Other". code 303 "See Other".
3.10. TLS Terminating Reverse Proxies 3.11. 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 29, line 22 skipping to change at page 30, line 22
Fett, D., Kuesters, R., and G. Schmitz, "A Comprehensive Fett, D., Kuesters, R., and G. Schmitz, "A Comprehensive
Formal Security Analysis of OAuth 2.0", arXiv 1601.01229, Formal Security Analysis of OAuth 2.0", arXiv 1601.01229,
January 2016, <http://arxiv.org/abs/1601.01229/>. January 2016, <http://arxiv.org/abs/1601.01229/>.
[arXiv.1704.08539] [arXiv.1704.08539]
Fett, D., Kuesters, R., and G. Schmitz, "The Web SSO Fett, D., Kuesters, R., and G. Schmitz, "The Web SSO
Standard OpenID Connect: In-Depth Formal Security Analysis Standard OpenID Connect: In-Depth Formal Security Analysis
and Security Guidelines", arXiv 1704.08539, April 2017, and Security Guidelines", arXiv 1704.08539, April 2017,
<http://arxiv.org/abs/1704.08539/>. <http://arxiv.org/abs/1704.08539/>.
[bug.chromium]
"Referer header includes URL fragment when opening link
using New Tab",
<https://bugs.chromium.org/p/chromium/issues/
detail?id=168213/>.
[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-09 (work in progress),
January 2018. November 2018.
[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-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-17 (work in progress), October
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-11 (work in progress), August 2018. mtls-12 (work in progress), October 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., Tschofenig, H., and M.
"OAuth 2.0 Proof-of-Possession: Authorization Server to Mihaly, "OAuth 2.0 Proof-of-Possession: Authorization
Client Key Distribution", draft-ietf-oauth-pop-key- Server to Client Key Distribution", draft-ietf-oauth-pop-
distribution-03 (work in progress), February 2017. key-distribution-04 (work in progress), October 2018.
[I-D.ietf-oauth-resource-indicators] [I-D.ietf-oauth-resource-indicators]
Campbell, B., Bradley, J., and H. Tschofenig, "Resource Campbell, B., Bradley, J., and H. Tschofenig, "Resource
Indicators for OAuth 2.0", draft-ietf-oauth-resource- Indicators for OAuth 2.0", draft-ietf-oauth-resource-
indicators-00 (work in progress), August 2018. indicators-01 (work in progress), October 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-07 (work in progress), June 2018. binding-08 (work in progress), October 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-18 (work in progress), June 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.
skipping to change at page 31, line 24 skipping to change at page 32, line 36
<http://openid.net/specs/openid-connect-core-1_0.html>. <http://openid.net/specs/openid-connect-core-1_0.html>.
[owasp] "Open Web Application Security Project Home Page", [owasp] "Open Web Application Security Project Home Page",
<https://www.owasp.org/>. <https://www.owasp.org/>.
[owasp_csrf] [owasp_csrf]
"Cross-Site Request Forgery (CSRF) Prevention Cheat "Cross-Site Request Forgery (CSRF) Prevention Cheat
Sheet", <https://www.owasp.org/index.php/ Sheet", <https://www.owasp.org/index.php/
Cross-Site_Request_Forgery_(CSRF)_Prevention_Cheat_Sheet>. Cross-Site_Request_Forgery_(CSRF)_Prevention_Cheat_Sheet>.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616,
DOI 10.17487/RFC2616, June 1999,
<https://www.rfc-editor.org/info/rfc2616>.
[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>.
skipping to change at page 31, line 47 skipping to change at page 33, line 18
<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 ]]
-09
o changed text to recommend not to use implicit but code
o added section on access token injection
o reworked sections 3.1 through 3.3 to be more specific on implicit
grant issues
-08 -08
o added recommendations re implicit and token injection o added recommendations re implicit and token injection
o uppercased key words in Section 2 according to RFC 2119 o uppercased key words in Section 2 according to RFC 2119
-07 -07
o incorporated findings of Doug McDorman o incorporated findings of Doug McDorman
o added section on HTTP status codes for redirects o added section on HTTP status codes for redirects
o added new section on access token privilege restriction based on o added new section on access token privilege restriction based on
comments from Johan Peeters comments from Johan Peeters
-06 -06
skipping to change at page 33, line 36 skipping to change at page 35, line 17
-00 (WG document) -00 (WG document)
o turned the ID into a WG document and a BCP o turned the ID into a WG document and a BCP
o Added federated app login as topic in Other Topics o Added federated app login as topic in Other Topics
Authors' Addresses Authors' Addresses
Torsten Lodderstedt (editor) Torsten Lodderstedt (editor)
YES.com AG yes.com
Email: torsten@lodderstedt.net Email: torsten@lodderstedt.net
John Bradley John Bradley
Yubico Yubico
Email: ve7jtb@ve7jtb.com Email: ve7jtb@ve7jtb.com
Andrey Labunets Andrey Labunets
Facebook Facebook
skipping to change at page 34, line 4 skipping to change at page 35, line 30
John Bradley John Bradley
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
YES.com AG yes.com
Email: mail@danielfett.de Email: mail@danielfett.de
 End of changes. 56 change blocks. 
96 lines changed or deleted 180 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/