37

I am developing a Web API which will back several applications: a website, a companion mobile application(s) and possibly several third-party applications. Every application is expected to get an access token from auth server and then feed it to the API, user will enter their credentials either on auth server web interface (for third-party applications) or directly in the website or app (for "trusted" applications). The client apps themselves are not expected to require user identity.

I've started implementing it via OAuth 2, and it matches my use cases exactly. But later I found several discussions in the 'net that sent me thinking whether my scenario really requires OpenID Connect, and now, after a few thousands of words read I still cannot grok which one is better for my case.

(For example, GitHub, which roughly matches my use cases, uses OAuth 2)

I'd like to hear some guidelines on how does one choose whether one's API requires OAuth 2 or OpenID Connect.

Update

What confuses me is the following: there is a valid point in not using OAuth for authentication. But consider this case (assume that there's a simple business rule: each user can see only their own documents):

  • app goes to auth server for token
  • user authorizes the app, so the token is granted
  • app goes to api with the token for data
  • api returns documents for user that authorized the token (so somehow the token can be traced back to user)

Is this an authentication scenario or authorization scenario?

PS. I am aware of this question, but the best answer there doesn't address my doubts.

Sergei Rogovtcev
  • 423
  • 1
  • 4
  • 8
  • Do you have references to some of the `several discussions` that made you question OAuth 2? – Neil Smithline Jul 28 '15 at 03:50
  • @NeilSmithline [this](http://oauth.net/articles/authentication/) is one, and later there was [a discussion on Russian programmer site](http://habrahabr.ru/post/263525/#comment_8515235). These two I remember. – Sergei Rogovtcev Jul 28 '15 at 08:38

2 Answers2

21

From what you have explained it seems that OAuth 2.0 would better suit your needs. OpenID Connect was developed to add secure authentication to OAuth 2.0. Large providers i.e. Google, Facebook, Yahoo, etc began using OAuth 2.0 as a way to authenticate users with "login with" services so users could use their credentials to authenticate to a variety of third-party services. Standard OAuth 2.0 cannot securely satisfy this requirement because of deficiencies within the protocol. OpenID Connect solves these deficiencies and allows providers to securely use OAuth 2.0 as an authentication framework. OAuth 2.0 was originally developed as an authorization framework which allows a user to grant a third party service access to their data stored on the provider. The scenario you described seems like exactly what OAuth 2.0 was developed to do. If you do not plan to offer a "login with" mechanism use OAuth 2.0.

If a user will have their own credentials for the third-party services and not use your providers credentials to log into the service, you won't need OpenID Connect.

This was the most useful resource I found. It's a blog post by one of the designers of OpenID Connect that addresses Facebook's different uses for OAuth 2.0.

Justin Moore
  • 769
  • 4
  • 9
  • Any sources to back that up? (I'd like to find the definition that separates need for authentication from the need of authorization) – Sergei Rogovtcev Jul 30 '15 at 09:16
  • 1
    Added the blog post I got most of the information from. The post you linked was also very helpful. – Justin Moore Jul 30 '15 at 14:45
  • 2
    The blog post you're pointing at drives forth the same point that OAuth should not be used for authentication. I already got that. The question is, is my scenario (see update to the question) authentication or authorization? – Sergei Rogovtcev Jul 30 '15 at 15:24
  • 3
    You answered your own question in the edit. The user authorizes the app so it's an authorization scenario. Although the user does authenticate to your OAuth 2.0 endpoint the third party doesn't use the granted token as proof of authentication just proof of authorization to access their data stored on your service through the API. – Justin Moore Jul 30 '15 at 16:19
  • 3
    But my API receives user information by means of that token, isn't that a proof of authentication too? – Sergei Rogovtcev Jul 30 '15 at 20:06
  • 4
    Nope. It's proof that the user authorized the third party application to access their data. Using the token as a means of authentication is the problem solved by OpenID Connect. – Justin Moore Jul 30 '15 at 21:54
  • 2
    But how we define "their data" without knowing who "they" are? – Sergei Rogovtcev Jul 31 '15 at 08:46
  • 7
    During the OAuth flow the third party application redirects the user to your OAuth 2.0 endpoint were they authenticate to your application and grant the third party access to their data stored by you. You associate the OAuth token you gave the user with the user on your service. The big difference between authentication and authorization here is that the third party doesn't trust the access token from your service as proof that user authenticated to your service, only that the user has authorized the third party service to access their data. – Justin Moore Jul 31 '15 at 20:01
  • @JustinMoore Great point! Even though I could authenticate the user in teh OAuth flow, does not necessarily mean the user is authenticated from by the OAuth Provider. The authentication is just a poof that user authorized the third party to access their data. Most folks (including me before this post) dont get this. – Ashish Gupta Jun 09 '16 at 03:17
  • @JustinMoore "The big difference between authentication and authorization here is that the third party doesn't trust the access token from your service as proof that user authenticated to your service." Why not? The user can't authorize the third party without being logged in to my service, right? – Eric Eskildsen Sep 27 '17 at 18:41
11

First off, as you probably know, OpenID Connect is just an authentication layer built on top of OAuth2. So regardless of which on you pick, you will need to implement OAuth2 (as the common denominator).

OAuth2 itself is an authorization mechanism (i.e. allows you to check that a token is valid and has a specific set of scopes granted). It does not provide authentication out of the box (you can't immediately tell "who" the user is).

However in many cases, you might be looking to have both authorization and authentication. In this case you need a layer on top of OAuth2 to provide that. That is most commonly done by have the resource server expose some sort of "Who am I?" endpoint that returns the identity of the user associated with the access token.

OpenID Connect does that and provides a standard way to obtain and represent the user identity (that's the object returned by the UserInfo endpoint) as a set of claims.

It also enables the client app to receive the user info along with the access token (that's the id_token returned by the token endpoint or included alongside the authorization code as a signed JWT token, depending on your flow), which saves an HTTP request.

OpenID Connect provides also a bunch of other things that IMO are of lesser interest (dynamic registration, etc.).

So to answer your question about OAuth2 vs. OpenID Connect: if you need authentication for your APIs, you will have to implement it on top of OAuth2. You can do something custom or you can implement OpenID Connect. OpenID Connect is very complex if you want to implement the whole spec, but relatively easy if you just want to implement the MVP to authenticate a user (implement the user info endpoint and use the standard representation, and maybe issue id_tokens).

For more info see the OpenID Connect spec.

Christophe L
  • 241
  • 1
  • 2
  • 3
    Every OAuth 2 implementation I've seen included user information in the token. Why isn't that sufficient for my API? – Sergei Rogovtcev Jul 30 '15 at 20:09
  • 1
    If you get enough information from the access token (I'm assuming it's encoded as a JWT?), then you most likely don't need OpenID Connect. The only reason why you would still consider it is if there are 3rd party devs integrating with your APIs who already have implemented OpenID Connect from a consumer side (to integrate with Google for example). If so, it might be easier for these devs to integrate with your platform if you had some level of compatibility with OpenID Connect (code reuse). – Christophe L Jul 30 '15 at 20:19