Deep Dive Into OAuth2.0 and JWT (Part 1 Setting the Stage)
Deep Dive Into OAuth2.0 and JWT (Part 1 Setting the Stage)
Take a deep dive into OAuth2.0 and JWT.
Join the DZone community and get the full member experience.Join For Free
Right from the inception of computer-based applications to today, one of the most common, yet complex problems that almost every developer must have come across during his career is security. Which, means understanding what data/information to be presented to whom — in addition to many other aspects like time, validation, re-validation and so on.
While often these two terms are used interchangeably, they fundamentally represent different functions. Let's try to define these one more time to refresh our memory.
You may also like: Understanding OAuth: Grants.
It is the process of authenticating a user or website/application that proves that they are who they claim they are by providing valid credentials for verification. Authentication is usually proven through username and password, sometimes in conjunction with some other information that is known only to the user. This set of information/elements are called factors. Based on these factors, any authentication mechanism can be divided into below three categories.
- Single-Factor Authentication: This relies on username and password (e.g. a website that requires only username and password).
- Two-Factor Authentication: In addition to username and password, this requires a piece of confidential information (e.g. banking websites that require users to enter a PIN known only to the user).
- Multi-Factor Authentication (MFA): Uses two or more security factors from independent categories (e.g. a hospital system that requires a username and password, a security code received on the user's smartphone, and fingerprint).
Authorization is the process of verifying what a user has access to. In authorization, a user/application is granted access to certain APIs/module after determining what level of permissions they're allowed. Usually, authorization happens after identity is validated through authentication.
Authorization is implemented with the use of “policies” and “rules.”
Authentication vs Authorization
While authentication and authorization are often used interchangeably, let us try to understand these with the help of a metaphor: think about soda and cocktail. Both these things are different in nature; soda is an ingredient, and a cocktail is a mixture. Soda can be used to make multiple drinks, and it can exist on its own. A cocktail can be made of many different things, and soda might be one of those things, but it takes more than one ingredient to make a cocktail, and it might not involve soda at all.
As such, it is not correct to say that soda is equal to a cocktail or saying that cocktail means soda. Similarly, authorization and authentication are not the same terms. They can do wonders when implemented correctly, but fundamentally they are different.
In a real-world scenario, you need to protect your resources with both authentication and authorization. When you can prove your identity, you would not be allowed to access the resource. And even if you have proved your identity, if you are not authorized to access a resource you will still be denied access.
There are many ways you can implement authentication and authorization. But, the most popular mechanism these days is “token-based” implementation.
What Is Token-Based Authentication?
Token-based authentication/authorization is a technique, where users enter their username and password once and receive a uniquely generated encrypted token in exchange. This token is then used to access protected pages or resources instead of login credentials.
Token-based authentication works by ensuring that each request to a server is accompanied by a signed token, which the server verifies for authenticity and only then responds to the request.
What Is a Token?
A “token” is a piece of data that is generated by the server containing the information that is required to uniquely identify a user. It is generated as a long string of random characters and numbers.
It could be something like cc7112734bbde748b7708b0284233419 or more complex like eyJ0eXAiOiJ KV1QiLCJhbGciOiJIUzI1NiJ9.eyJtZXNzYWdlIjoiSldUIFJ1bGVzISIsImlhdCI6MTQ1OTQ0ODExOSwiZXhwIjoxNDU5NDU0NTE5fQ.-yIVBD5b73C75osbmwwshQNRC7frWUYrqa TjTpza2y4.
This token has no meaning or use on its own, but, when combined with the correct tokenization system, it becomes an important aspect of securing your application.
Why Use Tokens?
The use of tokens has many benefits compared to traditional methods, such as cookies.
- Tokens are stateless: The token is self-contained and contains all the information it needs for authentication. This is great for scalability, as it frees your server from having to store session states.
- Tokens can be generated from anywhere: Token generation is decoupled from token verification, allowing you the option to handle the signing of tokens on a separate server or even through a different company such us Auth0.
- Fine-grained access control: Within the token payload, you can easily specify user roles and permissions as well as resources that the user can access.
Although this implementation can vary, essentially the steps involved are as follows:
- User Requests Access with Username/Password.
- Application validates credentials.
- Application provides a signed token to the client.
- Client stores that token and sends it along with every request.
- Server verifies token and responds with data.
While there is no limitation to how you want to implement this in your application, there are some standards defined by IETF (Internet Engineering Task Force). Two of the most popular are
2. JWT (RFC 7519).
In this article, we have refreshed our understanding of authentication and authorization, Also we have gone through the basics of token-based authentication. In the next article, we will learn about OAuth2 and JWT in detail.
Opinions expressed by DZone contributors are their own.