Skip to main content
Information Security

Return to Answer

added 17 characters in body
Source Link
Pace
Pace
  • 241
  • 2
  • 4

This was an earlier protocol that allowed an identity provider (like Google) to pass user information to a service (like StackOverflow). However, it used another method (not OAuth) for Google to authorize that StackOverflow is allowed to access the user's identity. OpenID had some security flaws (which I believe were addressed) but in my opinion the real killer was simply the fact that OAuth had better support and thus tended to be less work than learning OpenID's custom protocol.

This was an earlier protocol that allowed an identity provider (like Google) to pass user information to StackOverflow. However, it used another method (not OAuth) for Google to authorize that StackOverflow is allowed to access the user's identity. OpenID had some security flaws (which I believe were addressed) but in my opinion the real killer was simply the fact that OAuth had better support and thus tended to be less work than learning OpenID's custom protocol.

This was an earlier protocol that allowed an identity provider (like Google) to pass user information to a service (like StackOverflow). However, it used another method (not OAuth) for Google to authorize that StackOverflow is allowed to access the user's identity. OpenID had some security flaws (which I believe were addressed) but in my opinion the real killer was simply the fact that OAuth had better support and thus tended to be less work than learning OpenID's custom protocol.

Source Link
Pace
Pace
  • 241
  • 2
  • 4

We already have a diagram and a lot of good data so here is an example in case that helps.

Let's say I want to post a comment to StackOverflow. StackOverflow only allows comments if a user has 50 reputation.

StackOverflow must authorize this request (e.g. only allow it if the user has >= 50 rep). StackOverflow would not use OAuth to do this because StackOverflow owns the protected resource. If StackOverflow were trying to post a comment to Facebook on the user's behalf then it would use OAuth. Instead, StackOverflow will use local authorization (e.g. if (user.reputation < 50) throw InsufficientReputationError();)

In order to do this StackOverflow must first know who is making the request. In other words, in order to authorize the request it must first authenticate the request.

StackOverflow first checks the session and the HTTP headers to see if the user can be quickly authenticated (e.g. this is not their first request) but that fails.

Let's pretend StackOverflow has decided to use OpenID Connect. This means that StackOverflow trusts an identity provider. This is a service that StackOverflow trusts which can tell StackOverflow who the current user is. In this example we will assume that is Google.

StackOverflow now asks Google who the current user is. However, Google must first ensure that StackOverflow is allowed to know who the current user is. In other words, Google must authorize StackOverflow. Since Google is the owner of the protected resource and StackOverflow is the one accessing it we can use OAuth here. In fact, OpenID Connect mandates it.

This means that StackOverflow has to authenticate with an authorization server that Google trusts (in reality, this would also be Google, but that doesn't have to be the case) and get an access token. It takes that access token to Google and asks for the user's identity. Google then returns the user's identity (signing the identity on the way) and StackOverflow then authorizes the request now that it knows the user's identity.

In case you missed it there were multiple authentication and authorization steps each.

  • StackOverflow attempted to authenticate the request using session cookies but that failed.
  • StackOverflow then authenticated the request by using OpenID Connect
  • Google authorized SO's request for identity by using OAuth
  • The Authorization Server authenticated StackOverflow (probably using a client id & client secret).
  • In addition, as part of the OAuth workflow, the Authorization Server may have authenticated the request by asking the user for her username & password.
  • Furthermore, the user herself may have authorized SO's request for identity by responding to a grant screen (e.g. "do you want to allow StackOverflow to have access to your email?")
  • StackOverflow authorized the request by ensuring the user had >50 reputation.

What is OpenID (without the connect)?

This was an earlier protocol that allowed an identity provider (like Google) to pass user information to StackOverflow. However, it used another method (not OAuth) for Google to authorize that StackOverflow is allowed to access the user's identity. OpenID had some security flaws (which I believe were addressed) but in my opinion the real killer was simply the fact that OAuth had better support and thus tended to be less work than learning OpenID's custom protocol.

As of today everyone is abandoning it. Don't use it. Use OpenID Connect.

"Abusing" OAuth

In the scenario I described above OAuth is being used exactly as intended for authorization. However, there is another workflow which can often confuse people. This arose because in many situations (most?) the server providing the user's identity and the OAuth authorization server are the same server.

In this case it seems a bit excessive that an HTTP request is first made to the authorization server to get an access token and then again made to the same server to get an identity token. So an extension was created for the OAuth spec to allow the authorization server to bundle user identity information with the access token.

This allows authentication to happen entirely in the browser (e.g. StackOverflow's servers need not be involved). However, that sort of authentication is less useful and (I think?) is less commonly used.