Section 5.1.1). o If end-to-end confidentiality cannot be guaranteed, reducing scope (see Section 126.96.36.199) and expiry time (see Section 188.8.131.52) for issued access tokens can be used to reduce the damage in case of leaks.
Impact: Disclosure of all refresh tokens. Countermeasures: o Enforce credential storage protection best practices (Section 184.108.40.206). o Bind token to client id, if the attacker cannot obtain the required id and secret (Section 220.127.116.11). Section 18.104.22.168.2). o For assertion-based designs (Section 22.214.171.124). o Bind token to client id, because the attacker would guess the matching client id, too (see Section 126.96.36.199). o Authenticate the client; this adds another element that the attacker has to guess (see Section 188.8.131.52). Section 5.1.2).
Section 5.1.1). o A short lifetime reduces impact in case tokens are compromised (see Section 184.108.40.206). o The access token can be bound to a client's identifier and require the client to prove legitimate ownership of the token to the resource server (see Section 5.4.2). Section 5.1.1). This would prevent the attacker from capturing valid requests. o Alternatively, the resource server could employ signed requests (see Section 5.4.3) along with nonces and timestamps in order to uniquely identify requests. The resource server should detect and refuse every replayed request.
Countermeasures: o Handle tokens should have a reasonable level of entropy (see Section 220.127.116.11.2) in order to make guessing a valid token value infeasible. o Assertion (or self-contained token) token contents should be protected by a digital signature (see Section 18.104.22.168). o Security can be further strengthened by using a short access token duration (see Sections 22.214.171.124 and 126.96.36.199). Section 5.1.2). o Associate the endpoint URL of the resource server the client talked to with the access token (e.g., in an audience field) and validate the association at a legitimate resource server. The endpoint URL validation policy may be strict (exact match) or more relaxed (e.g., same host). This would require telling the authorization server about the resource server endpoint URL in the authorization process. o Associate an access token with a client and authenticate the client with resource server requests (typically via a signature, in order to not disclose a secret to a potential attacker). This prevents the attack because the counterfeit server is assumed to lack the capability to correctly authenticate on behalf of the legitimate client to the resource server (Section 5.4.2). o Restrict the token scope (see Section 188.8.131.52) and/or limit the token to a certain resource server (Section 184.108.40.206).
Section 220.127.116.11). RFC6749] is optional. However, [RFC2616] relies on the Authorization and WWW-Authenticate headers to distinguish authenticated content so that it can be protected. Proxies and caches, in particular, may fail to adequately protect requests not using these headers. For example, private authenticated content may be stored in (and thus be retrievable from) publicly accessible caches. Countermeasures: o Clients and resource servers not using an OAuth HTTP authentication scheme (see Section 5.4.1) should take care to use Cache-Control headers to minimize the risk that authenticated content is not protected. Such clients should send a Cache-Control header containing the "no-store" option [RFC2616]. Resource server success (2XX status) responses to these requests should contain a Cache-Control header with the "private" option [RFC2616]. o Reducing scope (see Section 18.104.22.168) and expiry time (Section 22.214.171.124) for access tokens can be used to reduce the damage in case of leaks. Section 5.4.1). o Set logging configuration appropriately.
o Prevent unauthorized persons from access to system log files (see Section 126.96.36.199.1). o Abuse of leaked access tokens can be prevented by enforcing authenticated requests (see Section 5.4.2). o The impact of token leakage may be reduced by limiting scope (see Section 188.8.131.52) and duration (see Section 184.108.40.206) and by enforcing one-time token usage (see Section 220.127.116.11). Section 4. RFC5246]. A virtual private network (VPN), e.g., based on IPsec VPNs [RFC4301], may be considered as well. Note: This document assumes end-to-end TLS protected connections between the respective protocol entities. Deployments deviating from this assumption by offloading TLS in between (e.g., on the data center edge) must refine this threat model in order to account for the additional (mainly insider) threat this may cause. This is a countermeasure against the following threats: o Replay of access tokens obtained on the token's endpoint or the resource server's endpoint o Replay of refresh tokens obtained on the token's endpoint
o Replay of authorization "codes" obtained on the token's endpoint (redirect?) o Replay of user passwords and client secrets RFC2818]). The client should validate the binding of the server to its domain name. If the server fails to prove that binding, the communication is considered a man-in-the-middle attack. This security measure depends on the certification authorities the client trusts for that purpose. Clients should carefully select those trusted CAs and protect the storage for trusted CA certificates from modifications. This is a countermeasure against the following threats: o Spoofing o Proxying o Phishing by counterfeit servers
o Activity/event logs. o User self-care applications or portals. OWASP]). Such practices may include but are not limited to the following sub-sections.
RFC4086] for best current practice) generated by the authorization server.
The authorization server may allow different scopes dependent on the grant type. For example, end-user authorization via direct interaction with the end user (authorization "code") might be considered more reliable than direct authorization via grant type "username"/"password". This means will reduce the impact of the following threats: o token leakage o token issuance to malicious software o unintended issuance of powerful tokens with resource owner credentials flow
Note: Short token duration requires more precise clock synchronization between the authorization server and resource server. Furthermore, shorter duration may require more token refreshes (access token) or repeated end-user authorization processes (authorization "code" and refresh token). OASIS.saml-core-2.0-os]) use the Audience element for this purpose. This countermeasure can be used in the following situations: o It reduces the impact of a successful replay attempt, since the token is applicable to a single resource server only. o It prevents abuse of a token by a rogue resource server or client, since the token can only be used on that server. It is rejected by other servers. o It reduces the impact of leakage of a valid token to a counterfeit resource server.
This is a countermeasure against: o device theft, o impersonation of a resource owner, or o suspected compromised client applications. IMEI] is one example of such an identifier; there are also operating system-specific identifiers. The authorization server could include such an identifier when authenticating user credentials in order to detect token theft from a particular device. Note: Any implementation should consider potential privacy implications of using device identifiers. X-Frame-Options]). This header can have two values, "DENY" and "SAMEORIGIN", which will block any framing or any framing by sites with a different origin, respectively. The value "ALLOW-FROM" specifies a list of trusted origins that iFrames may originate from. This is a countermeasure against the following threat: o Clickjacking attacks Section 3 (Security Features), clients are identified, authenticated, and authorized for several purposes, such as to: o Collate requests to the same client, o Indicate to the user that the client is recognized by the authorization server, o Authorize access of clients to certain features on the authorization server or resource server, and o Log a client identifier to log files for analysis or statistics.
Due to the different capabilities and characteristics of the different client types, there are different ways to support these objectives, which will be described in this section. Authorization server providers should be aware of the security policy and deployment of a particular client and adapt its treatment accordingly. For example, one approach could be to treat all clients as less trustworthy and unsecure. On the other extreme, a service provider could activate every client installation individually by an administrator and in that way gain confidence in the identity of the software package and the security of the environment in which the client is installed. There are several approaches in between.
to prevent several replay attacks. Moreover, installation-specific "client_ids" and secrets allow the selective revocation of all refresh tokens of a specific installation at once. RFC6749]. The way that this registration is performed is out of scope of this document. As per the core spec, every actual redirect URI sent with the respective "client_id" to the end-user authorization endpoint must match the registered redirect URI. Where it does not match, the authorization server should assume that the inbound GET request has been sent by an attacker and refuse it. Note: The authorization server should not redirect the user agent back to the redirect URI of such an authorization request. Validating the pre-registered "redirect_uri" is a countermeasure against the following threats: o Authorization "code" leakage through counterfeit web site: allows authorization servers to detect attack attempts after the first redirect to an end-user authorization endpoint (Section 18.104.22.168). o Open redirector attack via a client redirection endpoint (Section 4.1.5). o Open redirector phishing attack via an authorization server redirection endpoint (Section 4.2.4). The underlying assumption of this measure is that an attacker will need to use another redirect URI in order to get access to the authorization "code". Deployments might consider the possibility of an attacker using spoofing attacks to a victim's device to circumvent this security measure. Note: Pre-registering clients might not scale in some deployments (manual process) or require dynamic client registration (not specified yet). With the lack of dynamic client registration, a pre-registered "redirect_uri" only works for clients bound to certain deployments at development/configuration time. As soon as dynamic resource server discovery is required, the pre-registered "redirect_uri" may no longer be feasible.
OAuth-ASSERTIONS], the need to distribute a "client_secret" is eliminated. This may require the use of a secure private key store or other supplemental authentication system as specified by the client assertion issuer in its authentication process. Section 22.214.171.124) or validation of a pre-registered redirect URI (Section 126.96.36.199).
Section 188.8.131.52). Users often do not have the expertise to understand the ramifications of saying "yes" to an authorization request and are likely not to be able to see subtle differences in the wording of requests. Malicious software can confuse the user, tricking the user into approving almost anything. o End-user devices are prone to software compromise. This has been a long-standing problem, with frequent attacks on web browsers and other parts of the user's system. But with the increasing popularity of user-installed "apps", the threat posed by compromised or malicious end-user software is very strong and is one that is very difficult to mitigate. o Be aware that users will demand to install and run such apps, and that compromised or malicious ones can steal credentials at many points in the data flow. They can intercept the very user login credentials that OAuth is designed to protect. They can request authorization far beyond what they have led the user to understand and approve. They can automate a response on behalf of the user, hiding the whole process. No solution is offered here, because none is known; this remains in the space between better security and better usability. o Addressing these issues by restricting the use of user-installed software may be practical in some limited environments and can be used as a countermeasure in those cases. Such restrictions are not practical in the general case, and mechanisms for after-the- fact recovery should be in place. o While end users are mostly incapable of properly vetting applications they load onto their devices, those who deploy authorization servers might have tools at their disposal to mitigate malicious clients. For example, a well-run authorization server must only assert client properties to the end user it is effectively capable of validating, explicitly point out which properties it cannot validate, and indicate to the end user the risk associated with granting access to the particular client.
[RFC6749] Hardt, D., "The OAuth 2.0 Authorization Framework", RFC 6749, October 2012. [RFC6750] Jones, M. and D. Hardt, "The OAuth 2.0 Authorization Framework: Bearer Token Usage", RFC 6750, October 2012. [Framebusting] Rydstedt, G., Bursztein, Boneh, D., and C. Jackson, "Busting Frame Busting: a Study of Clickjacking Vulnerabilities on Popular Sites", IEEE 3rd Web 2.0 Security and Privacy Workshop, May 2010, <http://elie.im/ publication/busting-frame-busting-a-study-of- clickjacking-vulnerabilities-on-popular-sites>. [IMEI] 3GPP, "International Mobile station Equipment Identities (IMEI)", 3GPP TS 22.016 11.0.0, September 2012, <http://www.3gpp.org/ftp/Specs/html-info/22016.htm>. [OASIS.saml-core-2.0-os] Cantor, S., Ed., Kemp, J., Ed., Philpott, R., Ed., and E. Maler, Ed., "Assertions and Protocols for the OASIS Security Assertion Markup Language (SAML) V2.0", OASIS Standard saml-core-2.0-os, March 2005, <http://docs.oasis-open.org/security/saml/ v2.0/saml-core-2.0-os.pdf>. [OASIS.sstc-saml-bindings-1.1] Maler, E., Ed., Mishra, P., Ed., and R. Philpott, Ed., "Bindings and Profiles for the OASIS Security Assertion Markup Language (SAML) V1.1", September 2003, <http://www.oasis-open.org/committees/download.php/3405/ oasis-sstc-saml-bindings-1.1.pdf>.
[OASIS.sstc-sec-analysis-response-01] Linn, J., Ed., and P. Mishra, Ed., "SSTC Response to "Security Analysis of the SAML Single Sign-on Browser/ Artifact Profile"", January 2005, <http://www.oasis-open.org/committees/download.php/ 11191/sstc-gross-sec-analysis-response-01.pdf>. [OAuth-ASSERTIONS] Campbell, B., Mortimore, C., Jones, M., and Y. Goland, "Assertion Framework for OAuth 2.0", Work in Progress, December 2012. [OAuth-HTTP-MAC] Richer, J., Ed., Mills, W., Ed., and H. Tschofenig, Ed., "OAuth 2.0 Message Authentication Code (MAC) Tokens", Work in Progress, November 2012. [OAuth-JWT] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token (JWT)", Work in Progress, December 2012. [OAuth-REVOCATION] Lodderstedt, T., Ed., Dronia, S., and M. Scurtescu, "Token Revocation", Work in Progress, November 2012. [OPENID] "OpenID Foundation Home Page", <http://openid.net/>. [OWASP] "Open Web Application Security Project Home Page", <https://www.owasp.org/>. [Portable-Contacts] Smarr, J., "Portable Contacts 1.0 Draft C", August 2008, <http://portablecontacts.net/>. [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005. [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The Kerberos Network Authentication Service (V5)", RFC 4120, July 2005.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005. [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008. [SSL-Latency] Sissel, J., Ed., "SSL handshake latency and HTTPS optimizations", June 2010. [Sec-Analysis] Gross, T., "Security Analysis of the SAML Single Sign-on Browser/Artifact Profile", 19th Annual Computer Security Applications Conference, Las Vegas, December 2003. [X-Frame-Options] Ross, D. and T. Gondrom, "HTTP Header X-Frame-Options", Work in Progress, October 2012. [iFrame] World Wide Web Consortium, "Frames in HTML documents", W3C HTML 4.01, December 1999, <http://www.w3.org/TR/html4/present/frames.html#h-16.5>.