Table of Contents

What is it?

A delegated authorization protocol, NOT authentication protocol. See Definitions if you're unsure what I'm going on about.

From RFC6749:

The OAuth 2.0 authorization framework enables a third-party application to obtain limited access to an HTTP service, either on behalf of a resource owner by orchestrating an approval interaction between the resource owner and the HTTP service, or by allowing the third-party application to obtain access on its own behalf.



Resource owner
entity capable of granting access to a protected resource. When the resource owner is a person, it is referred to as an end-user. In the example of someone wanting access to your Google Plus profile, you are the resource owner.
Resource server
server hosting protected data
application requesting access to a resource server
Authorization server
server issuing access token to the client. Often the case that his server and the actual resource server is the same server (obviously different endpoints, but yah know)


Tokens are random strings generated by the authorization server and are issued when the client requests them.

Access tokens
allows the user data to be accessed by a third-party application. It has a limited lifetime, which is defined by the authorization server.
Refresk token
isssued with the access token but it is not sent in each request. Merely serves to be sent to the authorization server for renewing access token when it has expired.


scope is a parameter used to limit the rights of the access token.

  • List of availabe scopes is defined by the authorization server
  • Client sends scopes he/she wants access to during the request to the authorization server

Authorization flows (grant types)

Just head over to the tutorial below. Shows nice diagrams and all. An Introduction to OAuth2 by DigitalOcean

Something to be aware of when reading the article:

  • client_id refers to some id of which the client application has been assigned by the authorization server when it registered itself

Authorization Code

  • Allows a client application to access some resource, which requires authorization from the user, without ever seeing the user credentials


  1. user is given an authorization code link with request_typecode=
  2. Users authorizes the client_application to access the resource
  3. service redirects the user-agent to the client_application redirect URI, which will take the contain the code received from the authorization_server as a URL-parameter
  4. client_application can then extract the code from the URL, and use this code to obtain a access token from the authorization_server on the token-info endpoint (e.g. /token)
  5. If the authorization is valid, the authorization_server (API) will respond with the access token and the client_application can then use this to access the resource


Password (relies on authentication)

Client Credentials

How it works (uses Password flow)

  1. User want so to access resource x
  2. User asks server for permission access resource x
  3. Server ( provider ) provides user with a key, the access token, which the user can use to "unlock" the resource.
    • This key is completely "opaque" to the user, i.e. the user cannot get any information out of this key, and simply has to trust the server that this key will in fact do what the user requested.
  4. User uses the provided access token to request resource x
  5. Server serving resource x checks if this access token is valid, and returns the resource x if so.

Typical use-case (uses Password flow)

  1. User logs in (i.e. provider authenticates user) for example by using Basic Authentication
  2. Login successful → receive OAuth2 token
  3. Use OAuth2 token to access whatever resources you can access


Access vs Bearer tokens

  • Clients use access tokens to make requests of providers for protected resources.
  • Clients presents "bearer" access tokens on query parameters, headers (Authorization: Bearer xyz), or form parameters


process or action of proving or showing something to be true or valid. In my own words: assessing whether or not a user is valid, i.e. registered. "Who are you"?
function of specifying access rights to resources related to information. In my own words: making sure the user is allowed to access the resource. "What are you allowed to do?"
refers to the server, person, or whatever which wants to access the resource.