OAuth2 is a authorization protocol, that emerged from the Social Web. This allow users to authorize third parties to access their information without them having to know the user’s credentials.
There are multiples entities involved in the OAuth2 flow:
- Resource owner: Entity that may grant access to protected resources. It may be an authorization of certain resources and no other. Resources owner is usually a person.
- Client: It is a website or application that will access to the protected reosurces of the user with his/her authorization.
- Provider:
- Authorization server: Validates user and credentials; and generate access tokens.
- Resource server: Receive requests for access to protected resources; granting access if the token that comes in the body or in the headers (generally in the headers ) is valid.
Google, Facebook, Microsoft, Twitter or Ping Identity are OAuth2 providers.
Use cases of the authorization protocol OAuth2
A person which has an account on Facebook or Twitter wants to publish content through another application. Using OAuth2, the user gives permission to that application to post on the wall.
But the user does not authorize it to see the friend list and of course he/she never grant access to the user’s credential.
At any time, for security reasons the user can terminate the access authorization of the application, without having to modify the password on Facebook or Twitter.
The resource owner would be the user. The client would be the application from which we want to make publications. The provider would be Facebook or Twitter.
A person which has an account on Facebook or Twitter wants to publish content through another application. Using OAuth2, the user gives permission to that application to post on the wall.- A person with a Facebook or Twitter account wants to access another platform without having to register. In this case, the application asks the user to log to Facebook or Twitter, and if the information is correct, the third party allows the user to perform actions on the platform.
The resource owner would be the person, and he/she gives access to the information that the application needs to consider a user is valid. The client is the application that the person wants to access without having to register. The provider is Twitter or Facebook.
The disadvantage of this is that some application can let a user log in using Facebook or Twitter. After that it posts messages in the user’s profile without soliciting permision. That’s why it is important to read the fine print of what information we are giving to the client application.
Example of the flow for a client application
Let’s see an example of how it works for a client application using Linkedin as a OAuth2 provider.
Configuring your Linkedin application
When we set up our application, it will provide us with a client identifier and a client secret.
Request an Authorization Code
To request an authorization code, you have to hit to the authorization endpoint
GET https://www.linkedin.com/oauth/v2/authorizationincluding this parameters :
- response_type: code.
- client_id: This is the client ID we obtained while creating the application.
- redirect_uri: The url which retrieves the authentication_code that will be sent back after authentication.
- state: It could be a unique string value of your choice .
- scope: List of member permissions your application is requesting on behalf of the user. In our case ” r_basicprofile r_emailaddress “.
This resource will show a login page of the OAuth2 provider service. And the users can enter their user name and password. In this case, Linkedin credentials. The client application do not have access to this information.
When the user has logged in, we are redirected to the redirect_uri adding a code parameter in the url. The client application has access to code parameter, but not the user’s credential .
The authorization code is not the final token with which you make calls to LinkedIn. It is used in the next step of the OAuth 2.0 flow to exchange for an actual access token.
Exchange authorization code for an Access Token
Send a Post request to
POST https://www.linkedin.com/oauth/v2/accessTokenincluding these parameters :
- grant_type: authorization_code.
- code: The code that we have just received.
- redirect_uri: The same redirect_uri you sent in the previous step. In this request, there is not redirection .
- client_id: Client ID is generated, when we created the application in Linkedin.
- client_secret: Client secret is generated, when we created the application in Linkedin.
The response of this request, is the access_token. In some other providers, it could return a refresh_token.
If you need example of how to use the refresh token, here is explained deeply.
Make authenticated request
Once we get the token, we can make authenticated API request on behalf of the user. For example, to get the user information we could send a GET request to
GET https://api.linkedin.com/v1/people/~:(id,first-name,last-name,email-address)?format=jsonsending the token as a header.
If the token is valid and has not expired, the user information is retrieved.
Which OAuth provider has you used?
This article is very clear.
is this procedure same for all oauth providers ?
In my experience, most of the oAuth2 providers work in a similar way.
The main difference would be the way the access token is used. In some providers it has to be send as header (for instance Authorization: Bearer access_token) and in others it is send as a parameter.
Besides, there are some variety in the name of the permissions the application is requested (scope).
Great explanation !