OAuth 2.0: Understanding the Dual Token System

Let's start from the basics.  

What is Authentication and Authorization?

1. Old ways of handling authentication and authorization
2. Evolution of modern authorization protocol i.e OAuth 1.0, OAuth 2.0
3. Access token vs Refresh tokens
4. Why use dual tokens instead of one single token?
5. How are modern applications handling these?
6. how is it possible to sign up with Facebook or google from 3rd party websites like unisala.com? 

Authentication:

Process of verifying the identity of a user in the system, through credentials like usernames and passwords.This step ensures that the entity requesting access is who it claims to be.

Authorization:

Determines what an authenticated user is allowed to do. For eg: a user is allowed to edit their own post

1. Traditional authentication and authorization through Session Cookies:

Historically, authentication was often handled directly using session based management.

• User login to a server,
• Server issues session for the user.
• Which then is sent back to the client as cookie. 
• Cookie is stored in user's device and sent with each subsequent request to the server.
• The server then validates the session id in the cookie against the stored sessions to grant or deny access

Session cookies required server to maintain session information which can become resources intensive with larger number of users.

Limitations:

• Cross-Domain Authentication Needs
• Scalability Issues
• Security Risks like session hijacking and cross-site request forgery (CSRF)
• API Integration and Third-Party Access

Transition to OAuth: Necessity as the Mother of Invention

2. OAuth 1.0:

Introduced in 2007 as open standard for access delegation.User can grant a 3rd party application access to their information stored on another service without having to share their login credentials (username and password) for that service.

it used uses cryptographic signature in it's core

generate access token 

  /

 user ---> credential ---> login 

\

generate request token

It introduced communication workflow:

1. Obtaining request token

2. Redirecting the user to authenticate

3. Accessing request token for access token

4. Using access token to access the api

Limitations of OAuth 1.0:

• complex cryptographic requirements
• Scalability concerns: OAuth 1.0 was less suited for large-scale applications.

was a significant step forward, it had a several drawbacks.

3. OAuth 2.0 :

To address these limitations, OAuth 2.0.It is authorization framework rather than authentication.It introduced :

1. Access token
2. Short lived , expires in few mins to hours
3. exposed in each api request sent to the server
4. Refresh token:
5. Long lived
6. expose only when access token needs to be renewed.

Access token and refresh token in OAuth 2.0 address several key issues in web security and usability that arise than just using single token. The rationale 🧠 behind dual token centers around:

1. Enhancing security
2. Security and Risk Mitigation
3. Access token are short lived, this limits the damage if access token is compromised.
4. Minimizing token theft
5. Separation of Role
6. By separating access token and refresh token, There is clear distinction in security sensitivity.And refresh token which can obtain new access token is not exposed with each api request.
7. . Improving user experience by reducing the frequency of re-authentication
8. Reduces need for repeated logins.Without refresh tokens user would need to re-authenticate when the action token expires. This disrupt the user experience.

4. In modern web app, authentication and authorization uses tokens.

------------------------------------------------------------------------------------------------------------------------------

if a access token is compromised , then why would not the refresh token be?

since both lives in client side? 🧐 👀

------------------------------------------------------------------------------------------------------------------------------

Both access token and refresh token are indeed stored in the client side, but

• their exposure
• and the way they are handled differ significantly,

which impacts their susceptibility to being compromised 

Here's why?

• Usage Frequency and Exposure:

1. Access tokens are sent with each api request, increases the change of interceptions
2. Refresh tokens are used less frequently- only when access token needs to be renewed.

• Storage and Security Best Practices:

1. Developer should apply stricter security measures for storing refresh tokens due to their longer validity and greater power.
2. This might include secure storage areas such as encrypted storage. or secure http only cookies where javascript cannot access.
3. Access tokens dues to their shorter lifespan might be stored in less stringent security.

• Mitigation Strategies: Implementation of detection mechanism

1. for example if a refresh token is used form an unfamiliar location or at unusual times. System might revoke the token and require the user to authenticate again.
2. Refresh token can also be rotated regularly. Each time a refresh token is used to obtain new access token, a new refresh token is issued and the old one is invalidated.
3. this limits the time window an attacker has to use a stolen refresh token.

To Conclude: So the dual token system in OAuth 2.0 consist of access token i.e short lived and refresh token i.e long lived. Which balances the need for security and user convenience with the system architecture.