Open ID Connect and Oauth 2

Asked

Viewed 1,296 times

6

Last year researching a bit about authentication on API's REST I’ve heard of OAuth and saw many recommendations regarding it. I read a little on the subject, liked the same and started using it with the ASP.NET Web API 2.

Now a little while ago I heard about the Open ID Connect which, from what I understand, extends the OAuth 2, I mean, it’s a superset of Oauth 2. But I’ve always heard that Open ID was for something totally different.

Thus, what are the real differences between the Open ID Connect and the OAuth? How the Open ID Connect extend the OAuth and what are the advantages/disadvantages of each of them?

2 answers

4

The OpenID does not extend the OAuth he uses the OAuth as a basis becoming a layer about Oauth. Oauth is pure delegation without any notion of identity.

Having said that, I simplify the application of both as follows:

  1. Oauth - Application access authorization
  2. Openid - Open identification with digital signature.

While Oauth defines secure ways to authorize applications and access certain contexts and content, it in particular defines how to do it, over HTTP etc. The OpenID defines a structure JSON which identifies users, devices, etc.

Together they produce a token that contains useful standard information that can allow you to know:

  1. Who authenticated himself
  2. Where it was authenticated
  3. When it was authenticated
  4. How it was authenticated
  5. What attributes you have
  6. Why make them available

... this by any application, know accurately if met the rules of both protocols.

To ensure the authenticity of the protocol OpenID still defines concepts as a Identity Provider that generate tokens digitally signed so that its credibility is assured, but at the base is a matter of trust.

4

The purpose of Openid Connect is to add a authentication the functions of authorization oauth (Source). That is, in fact the purpose of Openid and Oauth are different, and the problem is precisely that many people were using Oauth for authentication (i.e. proving that the user is who he says he is) when in reality the same had been designed to provide authorization (i.e. determine what an agent can or cannot do on behalf of a user). Some say that Oauth alone only supports a "pseudo-authentication" (whatever that means).

That question on security.SE (in English) has some additional information (for example, citing that Openid Connect uses JWT, and that standardizes several aspects making the code simpler, as well as the user’s way of choosing his provider, etc.), but from what I understand the main difference is this. I have no practical experience with either protocol, however, so I wouldn’t know the full implications of using one protocol or the other (for example, authentication is assumed ad-hoc Oauth is inferior to a "real" authentication, but I wouldn’t know if that’s true or how much worse it is).

Browser other questions tagged

You are not signed in. Login or sign up in order to post.