If I misuse OAuth 2.0 to do authentication, am I at risk?

Question

I understand that OAuth is not an authentication protocol, but an authorization one (even if the first paragraph on Google's OAuth 2.0 page disagrees), as well as that:

[...] authorization can be abused into some pseudo-authentication, on the basis that if entity A obtains from B an access key through OAuth, and shows it to server S, then server S may infer that B authenticated A before granting the access key.

and that I should use OpenID when I need to authenticate a user.

However, does it mean that if I actually use OAuth (not OpenID Connect, but OAuth 2.0) with Google, does it mean that my web application is not secure? Can it be compromised to gain access to an account or do something wrong? Can a user forge something to pass for another user?

To make the question a bit less abstract, let's assume that:

• The libraries I use, such as Flask-OAuth for Python and similar libraries for other languages, are secure.

• I trust Google,

• Google account of a user is not compromised (if user's Google account is compromised, an attacker is indeed expected to have access to the user's account on my web application),

• The FAI/hosting service/other man in the middle should not be trusted,

• Anyone who has a Google account can login/register/whatever,

• I don't need the user's e-mail address, first/last name or other personal information to be true; all I need is to keep data of one user protected from other users.

Answer 1

The main issue is making sure that you protect against the confused deputy problem.

Imagine you are using OAuth to authenticate users within your application.

However, an evil developer has their own application which also uses OAuth. Say their application is a Solitaire game, which uses Google's OAuth API. A user authenticates for Solitaire using their Google account.

However, the evil developer takes the authorisation they got from Google from the user and plays it to your app instead. Because you are using OAuth for authentication, you are taking the authorisation token as an authoritative statement that the user is in fact your user that you wanted to authenticate, but it is not - it is the attacker using the authorisation token to authenticate as that user. Therefore, the attacker has abused your authorisation in order to trick your application that the user is in fact authenticating with you.

This blog explains it well. Note that they use the phrase "cross site scripting" when I think they mean "cross site request forgery".

You can mitigate this by properly validating the audience parameter. You should also set a state and validate this on the callback because this can prevent a CSRF attack from performing a "login CSRF" attack on a user of your application (e.g. if your application synced data to Google, an attacker making another user appear to be logged in as them could steal the synced data to their Google account).

Also see this answer.