1

I recently discovered that the applications in our system used plain Oauth2 instead of OpenID Connect to authenticate users. The original use-case was to use OAuth to allow our users to authenticate on the applications using the main application's account, all of which are under our control.

There are a lot of posts around pressing on the fact OAuth is an authorization protocol and as such should not be used for authentication. While I understand the difference between the two notions, I'm having trouble finding information about what actually is the risk of doing so, and what kind of attacks could be made on the system and lead in a user being impersonated.

All I could find were either attacks that weren't specific to the authentication use-case (CSRF during the authorization procedure for example) or implied a malicious client application reusing the user's authorization. But these threats seemed only pertinent when using public services such as Google or Facebook as identity providers. In my use-case, both identity provider and clients are under control, effectively denying the threat of a malicious third-party client.

As such, what are the risks associated with using OAuth to authenticate users when all clients are under control?

Hyruu
  • 13
  • 2

1 Answers1

3

The problem with OAuth2 is that the authorization_code given out by the OAuth2 Provider, is not bound to the client_id of the OAuth2 Client.

This means that if a user authorizes a malicious service to access its OAuth2 resources, the malicious service could use the authorization_code it received to 'impersonate' the user on another service, if the other service mistakes authorisation for authentication.

enter image description here

To answer the question:

IF you can guarantee that you control ALL clients ALL the time, you are probably fine. However, you are still using a OAuth2 outside of its intended scope. Using a security protocol outside of its intended scope is generally considered very bad practice.

For example, there is a real risk that somebody, at a later date, decides to alter the scope of the project; it happens all the time.
If this happens, you might suddenly find that the assumptions you made earlier, are no longer true. If these are the very assumptions that made you feel confident enough to go ahead an build your authentication on bad practice, your authentication is suddenly vulnerable to impersonation attacks. Chances are, you will only find out when people start reporting strange incidents.

In summary: if you want Authentication, you should use OpenID Connect instead. OpenID Connect is the authentication layer build on top of OAuth2.

Jacco
  • 7,402
  • 4
  • 32
  • 53
  • +1 for the nice picture. Did you make that yourself? Otherwise a source might be interesting, if it is an article describing OAuth2. – Nico Nov 21 '18 at 12:12
  • I made the diagram myself, I reused it from [one of my previous answers](https://security.stackexchange.com/a/133073/2113). – Jacco Nov 21 '18 at 12:46
  • This answer is good on the generic case but not in the case I described. Since I own both the OAuth Provider and the services, there's no _"malicious service"_ involved. – Hyruu Nov 21 '18 at 14:07
  • @Hyruu I've extended the answer. – Jacco Nov 21 '18 at 14:20
  • That's indeed better. I'm waiting some more time before accepting in case other answers are made. I kind of was hoping there was an actual security breach even in that case, it's making it hard to justify the cost of reworking the authentication to implement OpenID Connect on the existing clients – Hyruu Nov 21 '18 at 17:56
  • @Hyruu maybe you can reduce the cost of rework by picking an [existing, certified, implementation](https://openid.net/developers/certified/). – Jacco Nov 22 '18 at 07:51
  • I commented this elsewhere too, but I'm still confused about this one - the OAuth2 spec _does_ state the authorization code should be bound to a specific client (and redirect URI): https://tools.ietf.org/html/rfc6749#section-4.1.2 - is this a later addition to the spec? – Seer May 28 '20 at 08:36