The Open Authentication (OAuth) standard is truly becoming the sole standard for authenticated transfer and use of data on the internet. Companies like Google, Facebook, and Twitter are jumping on board. Whether making web sites or desktop applications, developers will need to become more familiar with this protocol. The hope of this series of articles is to not only establish clear terminology, but concisely explain how the protocol works. In this part we will focus specifically on untangling the mess of terminology surrounding OAuth.
First, clear terminology needs to be established because the OAuth protocol is very complicated to learn, though it is based on simple ideas. Let’s look at the terminology from a top down approach. Access control is the umbrella idea under which OAuth exists, and is “a system which enables an authority to control access to areas and resources.” That is, it verifies people’s identities and grants and denies permission to do and access certain things. Bank tellers practice this every day; they must verify people are who they say they are and then allow them access only to their bank account.
Now, let’s look a bit closer. Access control involves two basic tasks: authentication and authorization. The most common misunderstandings involve these two words. The difference between authentication and authorization is that authentication verifies who you are, and authorization verifies what you are allowed to do. The bank teller checking my driver’s license ID is authentication, and the teller allowing me to access my account specifically is authorization. It is very easy to confuse the two because most web applications using the OAuth protocol also handle authentication. So, to make this clear from the start, the OAuth standard handles authorization not authentication.
Third, a common technique in managing authenticated users is to use federated identities. A federated identity is essentially a user account that is linked across multiple web applications. So, for example, you have an account at Bank X, and that bank partners with Bank Y so that you can go to Bank Y and withdrawal from you account even though you don’t have an account with them. That’s federated identity, and though most aren’t familiar with the term, they are likely familiar with the idea of Single Sign-On (SSO). SSO comes from this idea, but refers specifically to mutliple web applications using the same authentication process. The reason this is important is because OAuth does not provide SSO, but is inherently designed to work with it. This will become more clear as we delve more into OAuth.
Finally, let’s make not of some terminology specific to OAuth itself. Hueniverse has a more in depth definitions, but we will be more concise here:
- Service Provider – the website that issues and manages tokens and has the protected resources (i.e. Twitter)
- User – people who are using the service provider’s website (i.e. you and I)
- Consumer – web applications that are accessing a user’s protected resources at the service provider (i.e. FarmVille, the Facebook app)
- Protected Resources – the user data service providers are protecting (i.e. username, email, password, photos, etc)
- Tokens – in essence the “username” and “password” credentials used by consumers to access a service provider’s protected resources, and have the two basic types:
- request token – exchanged by the consumer to the service provider for an access token
- access token – used by the consumer to access a user’s protected resources
- Consumer Key – the “username” of a consumer application that has been registered with the service provider
- Consumer Secret – the “password” for the consumer application
Now, for those even vaguely familiar with OAuth know that there are not just request and access tokens. Each token has a matching token and token secret. The token is like the “username” and the token secret like the “password” for the request. So, there is a request token, request token secret, access token, and a access token secret. As mentioned above, the request tokens are exchanged for the access tokens, and it’s the access tokens that a consumer, or web app developer, wants to have.
Those who have looked at OAuth even cursory know that having a clear understanding of what is going on is essential to be able to do anything with OAuth. When we get more into OAuth we will look at how OAuth also authenticates, but yet it doesn’t. Until mature and resilient libraries are developed that combine SSO and OAuth, such as Facebook Connect, those working with OAuth will need an in depth knowledge to setup and debug systems using this protocol, whether it be working with Twitter, FourSquare, or Flickr.