Authentication vs Authorization: Sessions, JWT, OAuth

In today's world everyone building the saas, mobile app or any api services basic or first build block is to implement authentication and authorization

Yash Patel5/20/20266 min read3 views
AuthorizationAuthenticationSessionsCookies
Authentication vs Authorization: Sessions, JWT, OAuth

Modern applications also need to be secure and safe ways to identify the users and what they can have access to.

we often have terms like

  • Sessions
  • JWT
  • Cookies
  • OAuth
  • OpenID connect
  • RABC

But some times we can't elaborate what every concept is and where it is being standout or solve cons of others.

I'will try to mention and breakdown as simple as much as i can.


Authentication vs Authorization

Authentication means:

who are you?

Authorization means:

What are you allowed to do? or what are you allowed to access?

For e.g. -

  • i am login into a dashboard => authentication
  • i am accessing the admin page like manage all users => authorization

As a user we can successfully authenticate to system but we can't have all permissions to access certain resources.


What are sessions?

Sessions are a stateful authentication approach.

where user login flow is like this

  1. client sends email/password
  2. the server validates credentials
  3. server create a session
  4. session id is stored in DB or Redis
  5. session id is send to client inside a cookie

on every request browser automatically send the cookie, server checks the session store and server verifies the user and on expirations it sends new session token

Pros:

  • sessions can be easily revoked
  • mostly perfect for monolithic applications
  • secure server side management

Cons:

  • as app scales sessions become harder to manage and harder to synchronizing sessions across multiple servers
  • mobile apps not working naturally with cookies

so API's start working with stateless authentication.


What is JWT?

JWT(JSON Web Token) is a stateless authentication approach.

JWT provide solution for transferring claims between 2 parties in stateless manner and it has 3 parts

  1. Header - contains some meta data like signing algorithm.
  2. Payload - contains user data such as user ID, roles, permissions
  3. Signature - used to verify the token and if after using secret value if it is tempered then it will fail

A server signs the token using a secret key.

When the client sends the token again:

  • the server verifies the signature
  • extracts user data
  • authorizes the request and it doesn't need session storage

It can solve scalability issue can verify with different servers with secret key

One challenge is theft if someone got secret key then you have to reset and every user have to login and if we have to revoke access of one user then also it will not allow for single user and logout is become harder until expiration for compromise token

But there is a hybrid approach

Hybrid Approach

  • JWT for scalability
  • stateful storage for revocation

e.g maintain a token blacklist where unethical users token is store and not allow for login and store refresh tokens in a database and revoke suspicious users individually.

this combines stateless and stateful security control

session-jwt-flow-image.webp

What are Cookies?

Cookies are simply stored on browser and other server can not access others cookies

From server side we can store session IDs, authentication tokens, preferences inside cookies.

Browser automatically send cookies with request to same domain. Cookies are not authentication themselves, It is only a transport storage mechanism.


Types of Authentication

Stateful

  • In this server store user sessions.
  • Best for Web applications, dashboard, system requires strong session control.

Stateless

  • Client store JWT tokens and and send on every req in header and in that it doesn't require to store session in DB and it is suitable in APIs, microservices, mobile applications

API Key Authentication

  • API is the way where you can generate a secure cryptographic key and you can use that API key using programmatic to user server or perform any operation in respective platform and it also provides expirations config and provide on every call and so it shows our identity by that.
  • it is easy to generate, good for m2m communication and easy support

OAuth 2.0

  • Till now we have discuss all methods and in that we have to provide login and password and we get token or store session but every time we using same password and remembering the password is complex and if system breach can exposes password and if some 3rd party application require password to access other data and that time we was first sharing the password so it was not secure in that some 3rd party will have full access and it might not secure so for that OAuth came in picture.
  • initially lets say we share password with 3rd party application and if we change in one app then we have to make changes everywhere
  • In OAuth users can share access with any platform without sharing password to any platform and with OAuth anyone cannot have full access it will only have limited access or details
  • but OAuth 1.0 was having some complexity in cryptographic signature and have to handle multiple tokens and has scalability issues so it evolves and OAuth 2.0 was introduce
  • OAuth 2.0 was simple but it was not vulnerable but it allow Devs to choose flows based on app type like
    • Auth code flow for server side apps
    • Implicit flow for browser based app it is not preferred due to security
    • Clients credentials flow for m2m communication
    • Device flow where we have limited control over input like tv
  • OAuth was great for authorization but how we go for authentications so that issue was solved by OpenID connect where it is built on top of OAuth by introducing id token which was JWT and it was not in oauth1.0
  • So when user have to sign in then it req to server of google and it grants some permission and get id token in response and client will have that token and do operation using that token and client can exchange with resource server and get id token and client can access info using that
  • So with OAuth and OpenID Connect we have secure auth system without password exchange.

So mainly Stateful is used in web, Stateless is used in APIs, API key used for server to server, and Oauth for third party

So authentication means who is the user and authorization is what user can do

Let's say you are creator of any platform there you will have some border for some users and for others different and you have to give or defined permissions for every group of users and there you will need authentication and authorization.