Freigeben über

OAuth 2.0 Part I - In the beginning

  • Artikel

Yes, another OAuth Post…

I never really found the OAuth post that explained it at the level of detail I wanted so I really understood it. I'm attacking this using the actual spec itself as there is a ton of interesting stuff in there. You really should read it, it's actually not that bad to go through. I'm going to break this down into a number of posts to keep things bite-sized. This initial post is just going to level set on what OAuth is and to define a few terms that we are going to use over and over.

 OAuth at 10,000 feet

Before we even start with OAuth 2.0, we should answer the more general question of what is OAuth? Referring to Wikipedia for starters:

OAuth is an open standard for authorization.

It's useful to get right to the heart of a common source of confusion about OAuth. OAuth is about solving authorization problems. Period, end of sentence. Authentication is explicitly not an OAuth concern. Wikipedia goes on:

OAuth provides client applications a 'secure delegated access' to server resources on behalf of a resource owner. It specifies a process for resource owners to authorize third-party access to their server resources without sharing their credentials.

Accurate, but a little terse for my tastes. If we unpack this, what are we really saying here? OAuth is targeted at untangling a very specific but very common problem in authorization on the internet; there is a fundamental difference between me accessing my data and some other program that I want to give access to my data. The reason for wanting to make this distinction makes a lot of sense when you think about it. An example (oft cited at this point), is in order:

 For example…

We all have large libraries of photographs up on the web someplace. From time to time, it's nice to get high quality prints made. Assume that a service exists that can print these for me, I now need to give the service access to the files. How should I do this?

  • I could grant anonymous access to my photographs.
  • I could give the service my credentials to my cloud storage so it can sign in as me.

Both of these approaches work but come along with obvious baggage. Granting anonymous access to the photos works, but I probably don't want them accessible by 7 billion of my closest friends. I also probably don't want to give my credentials to the service.

  • The service would be able to act as me which gives it complete control of my photos. That sounds … really bad.
  • What if I want to prevent the service from accessing my photos anymore? The only way to do that is to change my password.

What I really want is a way to give some of my rights to the service without having to share my credentials. Not coincidentally, that sounds a lot like how Wikipedia defined OAuth.

 The OAuth 2.0 Authorization Dance

In the interest of being precise, the spec has specific names that it assigns to the different roles to make sure there isn't any confusion when describing how things work. Understanding these is pretty important so here they are directly from the spec:

  • Resource Owner - An entity capable of granting access to a protected resource. When the resource owner is a person, it is referred to as an end-user.
  • Resource Server - The server hosting the protected resources, capable of accepting and responding to protected resource requests using access tokens.
  • Client - An application making protected resource requests on behalf of the resource owner and with its authorization. The term "client" does not imply any particular implementation characteristics (e.g., whether the application executes on a server, a desktop, or other devices).
  • Authorization Server - The server issuing access tokens to the client after successfully authenticating the resource owner and obtaining authorization.

 These are combined into the fancy-sounding 'Four Party Diagram' to show the overall idea. The client asks for and obtains permission to access a resource on the resource server from the resource owner, exchanges that permission for an access token issued by the authorization server and then exchanges that access token for the protected resource.

 

 One important observation here: up until now we've spoken of these resources like they were files. For the purposes of OAuth, a resource is anything addressable using a URI. That can obviously be a photo pulled via an HTTP GET or it can be a REST API endpoint which adds a photo to a repository using an HTTP POST. We are definitely talking about authorizing access to more than files here.

 In the next post, we're going to unpack the four party diagram further and what is really happening here.

Comments

  • Anonymous
    May 28, 2015
    The comment has been removed