The OAuth authentication framework provides users with a secure way to access online services without risking their credentials. Here’s a quick recap of what you should know about OAuth 2.0.
What is OAuth 2.0?
OAuth 2.0 is the current version of an open standard created to allow generic applications to access online services on your behalf that identify you, but without giving them a name your user and password for those services.
What does it mean? Can you give a specific example?
Of course. For example, OAuth 2.0, or just OAuth, allows you to post something on your blog and then automatically announce it on Instagram, Twitter or any other social network, but never get forwarded. your blog’s content management system (CMS) passwords for any of those accounts.
So OAuth 2.0 is about authentication?
Not quite. OAuth is not an authentication protocol but a standardized system for allowing limited access to online services. This is an important difference! OAuth has nothing to do with how you prove to Instagram, LinkedIn or anyone else that you really are you. It only gives third parties what is called “secure authorized 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 between four actors or roles: Resource Owner, Resource Server, Client, and Authorization Server. A Resource Owner is simply a user who wants to do some work on their behalf, by a Third Party Client, on the Resource Server. If you want your blog to announce a new post on Instagram, then 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 part that, after verifying the identity of the Resource Owner, provides the client with what is known as an “Access Token”.
Access token? What are they doing?
The access token is what really makes password sharing unnecessary. Personally I think something like “temporary access badge” would be a much clearer and easier to understand name, but as things go, we’re stuck with tokens, belonging two different types. The actual access tokens are small files that the client must show to the Resource Server to demonstrate that it is authorized, for a limited period of time (usually just a few hours), to act on behalf of the Resource Server. for some users. The most used format for OAuth Access Tokens is the one called JWT (JSON Web Token), which supports encryption and digital signatures of the data it carries. Besides the Access Token, the OAuth server also issues a Refresh Token, which lasts much longer than others but can be revoked at any time. Their purpose is to allow customers to request a new, temporary Access Token whenever they are using an expired one.
So with an Access Token an OAuth client can do whatever it wants on my behalf?
Not exactly, and this is the beauty of OAuth. Each access token is clearly identified Range, is a set of fine-grained permissions, each for a single action type and a single permission. For example, using different Scopes, you can connect two independent Clients to your Twitter account simultaneously, one is only allowed send tweet and the other just to read your Twitter timeline. Thanks to Scopes, that is, OAuth can handle as many services and applications as you need simultaneously, each with different permissions. Many services even include some kind of centralized OAuth dashboard, to allow users to keep track of how many Clients they have authorized, see what permissions each of them has, and update or revoke them at will.
SEE: Password Breach: Why Pop Culture and Passwords Don’t Go Together (Free PDF) (TechRepublic)
But how does the OAuth client get the Access (or Refresh) token?
In order to receive any token by the Authorization Server, the OAuth Client must be “referred” to it, which means it must approach it with some proof that someone wants it to receive the token. that newspaper.
OAuth 2 identifies three main ways of granting such “grants”. The most common information used by social networks and similar online services is called “Authorization Code”, while “customer credentials” (I am simplifying here!) Optimized for machine-to-machine scenarios, where software programs must obtain authorization from someone other than the program, not the user. Finally, there are grants called “Device Codes,” designed for devices without a browser or keyboard, like smart devices and game consoles. Without going into the details, those Device Keys generate other codes that the device owner can manually pass to the Authenticator Server from a regular desktop or mobile browser to complete the authorization process.
I think I understand how OAuth works now, but can we please review the whole process?
Sure, let’s see how all the pieces work together in case the blog requires authorization to automatically announce all your new posts on Twitter. For that to happen, the CMS blog will (after you log in, of course!) ask you if you want to do that. If you accept, the blog will present a license, including a unique identifier, to the License Server for Twitter. Using a dialog window in your browser, that server will ask you to explicitly authorize one or more actions (e.g. send tweets, reply to tweets, download your timeline, etc.) which it needs to create the corresponding Scope. If you accept, the Authentication Server will encapsulate everything it has as an Access Token and send it to your blog CMS. At that point, the CMS should be able to use that token directly to contact the Resource Server, which is Twitter, and do whatever you let it do. Did you notice the best feature of this whole process?
Not really. What would that be?
The fact that everything explained in the previous paragraph can be reduced to two independent threads, one to acknowledge the initial grant and the other to issue and use the actual Access Token, is handled by the machines. Different owners, completely independent. This highly extensible architecture, plus the granularity of permissions provided by OAuth Scope, is what makes OAuth 2.0 so useful and so successful.
