The OAuth authentication framework provides users with a safe way to access online services without putting their credentials at risk. Here’s a quick rundown of what you should know about OAuth 2.0.
What on Earth is OAuth 2.0?
OAuth 2.0 is the current version of an open standard created to let generic applications access online services on your behalf, that is with your identity, but without giving those applications your user name and password for those services.
What does that mean? Can you give a concrete example?
Of course. OAuth 2.0, or just OAuth for brevity, is what, for example, allows you to post something on your blog and then have it automatically announced on Instagram, Twitter or any other social network, but without ever passing to your blog content management system (CMS) the passwords for any of those accounts.
So OAuth 2.0 is about authentication?
No, not at all. OAuth is not an authentication protocol, but a standardized system to authorize limited access to online service. This is a crucial distinction! OAuth has nothing to do with how you prove to Instagram, LinkedIn or anybody else that you are really you. It only gives third parties what is called “secure delegated access” after you have authenticated your identity in some other way.
SEE: Google Chrome: Security and UI tips you need to know (TechRepublic Premium)
Okay. How does OAuth actually work?
To do its job, OAuth distinguishes among four actors, or roles: Resource Owner, Resource Server, Client and Authorization Server. The resource owner is simply the user who wants some work done on their behalf, by some third-party Client, on a Resource Server. If you want your blog to announce a new post on Instagram, Instagram is the Resource Server, you are the Resource Owner of your Instagram account, and your blog CMS is the Client. The Authorization Server — the core of OAuth — is the piece that, after verifying the identity of the Resource Owner, gives the client what are called “Access Tokens.”
Access tokens? What do they do?
Access tokens are what actually make it unnecessary to share passwords. Personally, I think that something like “temporary access badges” would have been a much clearer, self-explanatory name, but as things went we are stuck with tokens, of two different types. The actual Access Tokens are small files that a client must show to a Resource Server to prove it is authorized, for a limited amount of time (often just a few hours), to act on behalf of some user. The most used format for OAuth Access Tokens is the one called JWT (JSON Web Tokens), which supports encryption and digital signatures of the data it carries. Besides Access Tokens, OAuth servers also issue Refresh Tokens, which last much longer than the others but can be revoked at any moment. Their purpose is to let clients request new, temporary Access Tokens whenever the ones they were using expire.
So with an Access Token an OAuth client can do whatever it wants in my name?
Not exactly, and this is the beauty of OAuth. Each access token has its own well defined Scope, which is a set of fine-grained permissions, each for one kind of action, and one only. Using different Scopes for example, you may simultaneously connect two independent Clients to your Twitter account, one authorized to only send tweets, and the other only to read your Twitter timeline. Thanks to Scopes, that is, OAuth can simultaneously handle as many services and applications as you need, each with different permissions. Many services even include some kind of centralized OAuth dashboard, to let users keep track of how many Clients they authorized, see which permissions each of them has, and update or revoke them at will.
SEE: Password breach: Why pop culture and passwords don’t mix (free PDF) (TechRepublic)
But how do OAuth clients get Access (or Refresh) tokens?
To get any token by an Authorization Server, an OAuth Client must be “introduced” to it, meaning it has to approach it with some proof that someone wants it to receive that token.
OAuth 2 defines three main ways to issue such “grants.” The one most commonly used by social networks and similar online services is called “Authorization Code,” while “client credentials” are (I am simplifying here!) optimized for machine-to-machine scenarios, in which software programs must get authorizations from other programs, not human users. Finally, there are the grants called “Device Codes,” which are designed for devices without browsers or keyboards, like smart appliances and gaming consoles. Without getting into details, those Devices Codes generate other codes that the owner of the devices can manually pass to the Authentication Server from an ordinary desktop or mobile browser to finish the authorization procedure.
I think I get how OAuth works now, but can we please go over the whole process again?
Sure, let’s see how all the pieces work together in the case of the blog asking authorization to automatically announce all your new posts on Twitter. To make that happen, the blog CMS will (after you logged in, of course!) ask you if you want to do that. If you accept, the blog will present an authorization grant that includes some unique identification code, to the Authorization Server for Twitter. Using a dialog window in your browser, that server will ask you to explicitly authorize one or more actions (e.g., to send tweets, reply to tweets, download your timeline and so on) that it needs to create the corresponding Scope. If you accept, the Authentication Server will pack everything it got as an Access Token, and send it to your blog CMS. At that point, the CMS will be able to use that token directly to contact the Resource Server, that is Twitter, and do whatever you authorized it to do. Have you noticed the greatest feature of this whole procedure?
Not really. What would that be?
The fact that everything explained in the previous paragraph can be reduced to two independent flows, one to concede the initial grant, and one to issue and use the actual Access Token, that are handled by different, totally independent servers. This highly scalable architecture, plus the granularity of permissions provided by OAuth Scopes, are what makes OAuth 2.0 so useful and so successful.