Udostępnij za pośrednictwem

OAuth 2.0 Part 2 - The Four Party Diagram

  • Artykuł

Understanding the Four Party Diagram

In the last post, we made it through defining the four roles represented in the four party diagram. Now we're going to dig into the arrows that represent information flowing between the parties.

 

 

Authorization Request

This is conceptually straightforward. The client needs to ask the resource owner for permission to access a resource. This needs to be explicit in terms of the type of access the client wants to get. For example, the client could present the resource owner with a request for read-only access to a repository of photos. How exactly does the client do this? The spec is opinionated but not demanding here. The client can communicate directly with the resource owner and still be compliant with the spec, but the preference is to use the authorization server as an intermediary. This makes sense if you think about it. The authorization server is going need to trust the authorization grant in order to issue the access token. It sure is easier to sort that out if the authorization server is actually the party issuing the authorization grant on behalf of the resource owner.

 

Those Authorization Grant arrows look like they're hiding something…

The rest of the arrows are simple in concept; a request and a token that gives access to a resource. Once I have a valid authorization grant, I'm getting access to that protected resource, so you're probably thinking something pretty special has to happen in that arrow. That turns out to be correct. It's very important to understand what an authorization grant really is. Authorization grants are really credentials. The authorization server is going to inspect the credential the client sends, determines if it trusts it and, if it does, issue an access token to the client in response. If you are thinking "Hmmm, that sounds like authentication to me. I thought OAuth didn't do authentication…" you are correct on both counts. Hold that thought for a moment.

 

This is why it's very helpful to have the authorization server issue the authorization grant on behalf of the resource owner in the first place. The authorization server needs to authenticate the credential to make sure it's valid and then issue the right sort of token to give the client the subset of rights the resource owner approved. If the authorization server issued the credential in the first place, it's easy for the authorization server to validate it.

 

I think this is where the confusion of OAuth and authentication comes from because we see it happening right here. How can we say that OAuth only addresses authorization? The important thing to remember here is, the OAuth spec doesn't say much beyond generalities about the nature of the credentials and their format and it says nothing about how authentication should take place, how to keep it secure, etc. It just recognizes that some form of authentication must take place here in order to then proceed with the authorization part. There are a number of valid, secure ways to define and then authenticate the authorization grant and OAuth really doesn't have an opinion on which you use.

 

There are a few grant types defined in the spec. These are:

  • Authorization Code - This is probably the most common OAuth scenario. The client realizes that it needs an authorization grant and redirects the user to the authorization server. The authorization server authenticates the user and redirects back to the client. When this redirect happens, the authorization server sends a special, short lived authorization code to the client.

  • Implicit - This is a simplified version of the Authorization Code grant that is optimized for browser-based (think JavaScript/SPA) clients. The client redirects to the authorization server and the resource owner authenticates as before. This time, instead of sending an authorization code in the redirect it simply sends the access token. This simplification introduces some significant security implications here, so care needs to be taken. This actually has less to do with OAuth and more to do with the nature of JavaScript-based clients and their inability to keep secrets. We'll discuss this more in a future post.

  • Resource Owner Password Credentials - This is exactly what it sounds like, the username and password of the resource owner. It's arguably here for backward compatibility. The Authorization Code approach would be better if you were starting from scratch.

  • Client Credentials - This is an interesting one. In this case, the client itself, independent of any user, has its own credentials that it can pass to the authorization server and act on its own behalf. Assuming the authorization server recognizes those credentials, the client would be given an access token to the protected resource.

  • TBD - The spec also allows for extension. If these four grant types don't fit the bill, it doesn't mean OAuth 2.0 doesn't help you. You can plug in a different credential type and still conform to the OAuth spec. For example, a common scenario is using a SAML 2.0 token as an authorization grant.

 

Access Tokens

This is the thing that the client is going to present to the resource server. The actual format of the token is irrelevant to the spec. As long as the resource server understands and trusts it, it works. The client, on the other hand, never needs to understand it. It just needs to send it along when it requests the resource.

 

Usually this is going to be a string of some sort. It probably will not contain any information from the original access grant itself. For example, the grant might have been the username and password of the resource owner but the requested permission was read only. The token isn't going to have the resource owner's password anymore, it's just going to have some way of specifying which resources the token applies to, what rights the client has over those resources and for how long. For obvious reasons, these should be cryptographically secured somehow. However all of this is beyond the scope of the spec itself.

 

Refresh Tokens

Once the client has an access token, the client has access to the protected resource. If it never expires, the client can never lose access to the resource. So, obviously, we want these to expire and we probably want them to expire frequently to make sure we are checking back with the resource owner to ensure that the client should still have access. However we don't want to pester the resource owner every couple of hours with an authentication request. So the authorization server can issue something else called a refresh token with the access token.

 

The refresh token is essentially a record of the approved grant. When the access token expires, the client can send the refresh token to the authorization server to request a fresh access token. The authorization server can take the refresh token, verify that the resource owner hasn't revoked the client's authorization grant, and issue the new access token. If the grant has been revoked, that's it. The client can't access the protected resource anymore. The spec has a more extensive description, but you get the idea.

 

At this point, we've covered the conceptual flow in the four party diagram. Hopefully it all makes sense now. Next up we are going to delve into the client role further.