What is going on with OAuth 2.0? And why you should not use it for authentication. - Securing

The justification for that statement was the existence of multiple threats, like Insufficient Redirect URI Validation, Credential Leakage via Referrer Headers, Attacks through the Browser History or Access Token Injection and “no viable mechanism to cryptographically bind access tokens issued in the authorization response to a certain client”. To put it in simple words, there are two main threats for *implicit *type: - the leakage of access token transmitted in the URL (also as fragment), - the injection of access token, undetectable by the client. ### Token leakage The leakage threat is covered in RFCs related to OAuth. For example, the open redirect vulnerability was mentioned many times, even in the first OAuth 2.0 RFC [6749]. So basically, … Futhermore, the history shows that bugs in software beyond the reach of OAuth server’s and client’s developers (like the one in Chromium) introduce new vectors for token leakage such as beforementioned leakage via referer header or browser history. That is another motivation to adjust standards to the current situation. … This threat is also related to the fact that **OAuth framework must not be used for authentication**. The OAuth 2.0 RFC stays as follows: Authenticating resource owners to clients is out of scope for this specification. Any specification that uses the authorization process as a form of delegated end-user authentication to the client (e.g., third-party sign-in service) MUST NOT use the implicit flow without additional security mechanisms that would enable the client to determine if the access token was issued for its use (e.g., audience- restricting the access token). … ### Using OAuth 2.0 for authentication is really, really a bad idea… Problems arising from the use of OAuth 2.0 for authentication does not refer only to the *implicit *grant type, but also other types, including *authorization code* type. Lately, I have found an interesting vulnerability in Single Sign-On (SSO) authentication mechanism based on OAuth 2.0. It allowed to log in using accounts from Active Directory. … ## Other good tips and considerations for OAuth During the discussion on Twitter some other threats were mentioned and ideas proposed. The threat worth mentioning, which is actually indepentent form the grant type is the **Cross Site Request Forgery (CSRF)**. If you do not protect your OAuth implementation from CSRF, the attacker can return fake data from API to your users. It is important to **secure OAuth against CSRF attacks with the state parameter**. It should be a pseudo random number generated by the client and verified upon reception of the response from the authorization server, which must reply it unmodified.