Forem: Diego Dias

OAuth & OpenID - Tokens basics

Diego Dias — Wed, 28 Aug 2024 10:07:47 +0000

As promised, I'll cover tokens a bit more in-depth particularly on this post, as I try to keep them as more as dry/simple as possible to make sure they're effective, so you're kind eating power food for each one of them :D

Quick recap ( some words that summarise previous content ).

1 - Authorization
2 - Authentication
3 - Client Registering
4 - Redirecting

Previously we started introducing something around tokens, we saw that tokens can carry or not user information.

That's why we have denominated two types for them:
1 - Opaque
2 - Structured

The opaque token doesn't carry any user information or role access info, on the other hand, the structured token is usually forged using a secret key and provided back by the Authorization server, therefore this token is usually also a string, but a string in which can only be parsed by those who have the secret key to retrieve user information and access roles or anything else you'd like to put on the token.

PS: It is not recommended to put more info than necessary as the token travels a lot, so it is not recommended bit-wise.

That means:

1 - Only who have the key can parse the token
2 - Resource servers should have the key in their secrets to parse the token.

With that being said the access token is now obtained, now there's another dev decision to make: "Do we need get MORE user info or not"?

Although a structured token can carry user data, it is recommended to keep it as clean as possible, a common pattern of JWT token is:

{
  "iss": "https://auth.example.com",
  "sub": "1234567890",
  "aud": "https://api.example.com",
  "iat": 1693257600,
  "exp": 1693261200,
  "scope": "read write",
  "email": "user@example.com",
  "roles": ["admin", "user"]
}

User ID (sub): A unique identifier for the user.
Issuer (iss): Identifies the issuing authority of the token.
Expiration (exp): The token's expiration time.
Issued at (iat): The timestamp of when the token was issued.
Audience (aud): The intended recipient(s) of the token (e.g., your application).
Scopes/Permissions: Define what the user is allowed to do.

Now that we have the user ID (sub), we could call the auth server again to get the user information by calling Open ID Connect which would provide more user info to our application IF WE DECIDE so, it is not mandatory, but...

Now we are getting to an end, there's 2 important things I want to cover here: Refresh token and Token revocation:

1 - Refresh token
Whenever we receive an access token, there's an option to also receive a refresh token alongside with it, that means now you have 2 tokens, the only difference is that the refresh token doesn't give you access and a longer or no expiration time.

So whenever your access token expires, to avoid that annoying login screen again we just send it alongside with your refresh token to the auth server, so we can retrieve access again without extra user effort.

2 - Token revocation
This is an endpoint on the authorisation server that works for expiring your tokens immediately, so whenever calling this endpoint, your access token expires at the authorisation server, meaning further checks on it will obtain a negative scenario.
PS: Usually the refresh token expires when this is called.

Okay, I guess that would do for now, here is what we covered so far:

1 - Token types
2 - Token structure
3 - Roles
4 - Open Id is a decision
5 - Token refreshment
6 - Token revokation

That is a lot of crucial steps on understanding authentication/auth, I hope that helps anyone on understanding, please leave comments and suggestions on how to improve !

OAuth andOpenID - Introduction

Diego Dias — Thu, 22 Aug 2024 08:59:50 +0000

Hello, welcome to my second post at Dev.to! :D

We'll cover the basics of OAuth and OpenId and try to make the concept simple enough to memoize for interviews, let's go!

First thing, OpenID and OAuth are different things.

Authorization

OAuth is responsible for issuing a "token" after you provide your credentials to the OAuth server, which answers back with the access token that gives you access to APIs but doesn't carry any user data. That's what they call authorization.

Authentication

OpenId implements the concept of user identity on top of the OAuth token mechanism, the difference is that you also receive an ID Token alongside the access token. That's what they call authentication.

const OAuth = 'Authorization';
const OpenID = 'Authentication';

Simple, isn't it? Well, that's what they say. Look at the diagram below:

Link to the full diagram:
https://infosec.mozilla.org/guidelines/assets/images/OIDC_sequence_diagram.png

That's basically the flow for an OpenID authentication.

The main difference between this type of authentication and the standard cookie model is that it has its own authentication server and this server has full access agency, meaning controlling access by registering applications upfront and generating ClientID's and ClientSecret's for each registered client on this server.

These Secret's and ID's are now used on the clients to perform requests to the authentication server, which provides the token.

I think that's a good introduction to OAuth and OpenID.

What've learned so far:

1 - Authentication and Authorization
2 - Authorization Server
3 - ClientID and ClientSecret

In the next articles, I'll cover more about the token and its different strands.

JWT - Concept for interviews

Diego Dias — Wed, 14 Aug 2024 21:49:01 +0000

I've been working with JWT in mostly all of the projects for the past 5 years, I myself had set up an authentication endpoint using JWT for a personal project from scratch and yet, sometimes I fail to answer how JWT works in interviews.

The objective of this post is basically to create a simple strategy to fix this concept in our heads so when we get to an interview and they ask around that, we know how to counter-punch.

It should be simple, so let's stop with the useless chatty chat and go to what really matters.

THE JWT

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

That's how a JWT token would look like, each dot represents a divisor in the structure.

1. Structure

header.payload.signature

Header
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.

The header usually stores the algorithm and the token type.

The algorithm stands for the type of algorithm that will be used to encode the token, usually we use HS256.

Payload
eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.

The payload usually contains something like:

{"iat": timestamp, "iss": string, "exp": timestamp, "userId": string, "userRole": boolean}

User identification (e.g.: userId, userRole)
Expiry
IssuedAt (iat): Represents the token creation date.
Issuer: (iss): Servername whom issued the token.
Expiry: (exp): Token expiration time.

Signature
SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

The signature is compound by creating a hash using HMACSHA256 algorithm with the given input:

HMACSHA256(
base64(header),
base64(payload),
base64(key)
) = Signature.

Simple as that, we have an output which is the Encoded JWT token, it now can only be validated by servers who have the key and where the key is matchable with the token.