OAuth2, authorization protocol

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

  • AuthorizationA 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 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.

Client ID and client secret are specific to each application. They are used to identify the provider.
Client ID is a public information and it is used to generate the authentication URL. The client secret should be kept confidential for security reasons.
In order to prevent fraudulent transactions during the authentication process, we will only communicate with URLs that you have identified as trusted endpoints.
So we will add a list of trusted URL to redirect to when asking for the authentication code.
Besides, it is necessary to set permission preference about which information is going to be retrieved. We would use r_basicprofile and r_emailaddress

Linkeding Application


Request an Authorization Code

To request an authorization code, you have to hit to the authorization endpoint

GET https://www.linkedin.com/oauth/v2/authorization

including 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/accessToken

including 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=json

sending 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?


Other interesting articles

Deploying a secure and private Docker Registry

iOS Touch ID

3 thoughts on “OAuth2, authorization protocol”

    • 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).


Leave a Comment

¿Necesitas una estimación?

Calcula ahora

Privacy Preference Center

Own cookies

__unam, gdpr 1P_JAR, DV, NID, _icl_current_language

Analytics Cookies

This cookies help us to understand how users interact with our site

_ga, _gat_UA-42883984-1, _gid, _hjIncludedInSample,

Subscription Cookies

These cookies are used to execute functions of the Web, such as not displaying the advertising banner and / or remembering the user's settings within the session.

tl_3832_3832_2 tl_5886_5886_12 tve_leads_unique