Skip to content

Authentication and Authorization

this is a reproduction of the folowing blogs

Digital Identity

It refers to a set of attributes that define an individual user in the context of a particular application. Let’s say you are running a social network application. The user’s personal info, interests, friends, address, and sometimes credit card details could be their identity.


It is a process of verifying that a user is who they say they are. Once a system verifies his identity he would be able to access the application.


Once a user is authenticated, authorization deals with granting or denying rights to access resources.

OAuth 2.0

It is the most frequently mentioned specs when it comes to the web – and also one that is often misrepresented.

OAuth is not an authentication spec. OAuth deals with delegated authorization. authentication is about verifying the user’s identity and authorization is about granting access. While OAuth grants access to applications on the behalf of users.

Before OAuth

Let’s say we have an events app say “LetsMeet”. “LetsMeet” wants to set up a calendar event for you. Now “LeetsMeet” doesn’t have a calendar app, it wants to use third-party service like (Google Calendar) to add events.

So when you log into “LetsMeet”, It would ask you for “Google Calendar” login credentials, which you would enter in the “LetsMeet” app giving it control to the calendar.

In short, you have shared your google calendar username and password with the “LetsMeet” app giving him full access to it. With your credentials, he has the same amount of access as you do to the “Google Calendar”.

Apart from setting up a meeting, he could ready your personal info like other events, with who it is and so on. Apart from that if he has Google account password he could also access mails and so on.

In case if “LetsMeet” is compromised then your information could be stolen or breached.


OAuth 2.0 is an open standard for performing delegated authorization. It’s a specification that tells us how to grant third-party access to APIs without exposing credentials.

So when LetsMeet access Google Calendar on the user’s behalf Google Calendar can limit access to its API without sharing the credentials. It does it using an:

Authorization Server

It is a set of endpoints to interact with the user and issue tokens.

So Google Calendar now must have an Authorization server. Let’s assume that LetsMeet has already registered as a known client with Google Calendar as a result it now access to its API.

back to our problem let’s assume that you are already logged into the “LetsMeet” app and now It wants to access the calendar on your behalf.

First “LetsMeet” sends an authorization request to Calender’s server. In response, the server prompts you (the actual user) to log into Calendar App and grant consent to allow “LetsMeet” to access the Calender API on your behalf. If you grant consent then the Calendar app will send an Authorization code to “LetsMeet” letting it know that the user has agreed to allow it to access the app.

Now Calendar App then issues an access token to “LetsMeet” by which he can access the resources

Login Problem

OAuth 2.0 apps wanted to transfer the responsibility of maintaining security to 3 rd party apps in should they wanted to let users login in with other accounts. i.e “LeetsMeet” wanted to let “google” user to be able to log into it using “google account” bypassing signup all together.

As mentioned above OAuth is for delegating access not an authentication protocol

Problems with Using Access Tokens for Authentication

If “LeetsMeet” assumes successfully calling “google API” with an access token means the user can be considered authenticated, but this approach has 2 problems

  • If someone has stolen the access token from a different user and tries to access then we won’t be able to differentiate.
  • The access token may have been obtained from another client (new client) and injected into “LetsMeet”.

This problem is called confused deputy problem

To resolve this problem OCID was introduced.

OpenID Connect

OpenID Connect (OIDC) is a spec on top of OAuth 2.0 that says how to authenticate users. It is an identity layer for authenticating users with an authorization server by issuing tokens. Tokens are encoded pieces of data for transmitting information b/w parties (server, application, or resource API). In OIDC authorization server issues ID tokens.

ID Tokens

It provides information about the authentication event and they identify the user. They are intended for the client and have a fixed format that the client can parse and validate to extract identity information from the token and thereby authenticate the user.

OIDC declares a fixed format for ID tokens, which is:

JSON Web Token (JWT):

JWT composed of three URL-safe string segmens concatenated with periods.

Header Segment

The first segment is the header segment. It looks something like this


The header segment is a JSON object containing a signing algorithm and token type. It is base64URL encoded on decoding it looks something like below

  "alg": "RS256",
  "typ": "JWT"

Payload segment

It is a JSON object which looks something like this


It contains data claims, which are statements about the user and the authentication event example below:

  "sub": "1234567890",
  "name": "John Doe",
  "admin": true,
  "iat": 1516239022

Crypto Segment

Also know as signature. JWT’s are signed so they can’t be modifed in transit. So when server issues a token, it signs it using a key. When client receives the ID token, the client validates the signature using a key as well.


Authentication Claims

  "iss": "https://{you}",
  "aud": "RxHBtq2HL6biPljKRLNByqehlKhN1nCx",
  "exp": 1570019636365,
  "iat": 1570016110289,
  "nonce": "3yAjXLPq8EPP0S",

some of the required authentication claims in an ID token include:

  • iss (issuer): the issuer of the JWT, e.g., the authorization server.
  • aud (audience): the intended recipient of the JWT; for ID token, this must be the child ID of the application receiving the token.
  • exp (expiration time): token must not be accepted after this time
  • iat (issued at time): time at which the ID token was issued.

Nonce binds the client’s authorization request to the token it receives. The nonce is a cryptographically random string that the client creates and sends with the authorization request. The server then places the nonce in the token that is sent back to the app. With this, the app can verify that the token came from the place it requested the token from in the first place.

Identity Claims:

Claims also include statements about the end-user. Here is an example of these claims:

  "sub": "google-oauth2|102582972157289381734",
  "name": "Kim Maida",
  "picture": "https://gravatar[...]",
  "twitter": "",
  "email": "[email protected]",

Authentication with ID Tokens

Our entities are the browser, an application running in the browser, and the authorization server. When the user wants to log in, the app sends an authorization request to the authorization server. the user’s credentials are verified by the server and an ID token is generated.

The Client application then decodes the ID token (JWT) and verifies it. Both the signature and claim needs to be verified. Finally, we get access to identity claims and can interact with an API.

Accessing APIs with Access Tokens

Access Tokens are used for granting access to resources. These tokens don’t have any specifications or format but most apps doest use JWTs for access tokens because the format enables validation. These have short expiration times and so we may be sending different ones from time to time.

Accessing Resource APIs

Let’s assume we are logged into our JS app in the browser and want to request data. The app first sends the authorization request to the authorization server, requesting an access token to call an API. The server sends the token to the app. Now, whenever it wants to interact with the API, it needs to attach the access token to the request header, like so:

# HTTP request headers
Authorization: 'Bearer eyj[...]'

Now the API needs to verify the token using middleware and returns the requested data.

Now the early question how does OAuth solve the too much access problem

Delegation with Scope

How does the API know what level of access it should give to the application? It is done with scopes.

Scopes limit what an application can do on the behalf of a user. It delegate access control to the API or resourc. The API is then responsible for conbinng incoming scopes with actual user privileges to make the appropriate access control decisions.

Published inUncategorised

Be First to Comment

Leave a Reply

Your email address will not be published. Required fields are marked *