In this post, we take a look at some basics of OAuth2 and Json Web Tokens and how to use them.
The basic Token authentication has been a popular topic for the past few years. The basic idea is that attaching a token to the HTTP requests enables you to authenticate your request. This authentication can be valid for every HTTP request until the token's expiration. The Terminology of RFC 6750, clearly defines that a Bearer Token is
"a security token with the property that any party in possession of the token (a "bearer") can use the token in any way that any other party in possession of it can. Using a bearer token does not require a bearer to prove possession of cryptographic key material (proof-of-possession)."
In other words, when someone owns and use a token, the OAuth 2.0 protected target (Resource Server) validates the security token and the request is automatically authenticated. This is why it's very important to use tokens over SSL/TLS to ensure that tokens cannot be intercepted and stolen over the HTTP.
How can i get Token?
Before we describe how we can request a token, we should mention the main roles that are evolving in the OAuth 2.0 Authorization Framework
Resource ownerThe resource owner is the user who authorizes a Client application to access their data. The application's access to the user's data is limited to the "scope" of the authorization granted (e.g. read or write access). The resource owner “owns” a resource at resource server.
The server hosting the protected resources, capable of accepting and responding to protected resource requests using access tokens. Resource Server trusts the Authorization Server.
The server issuing access tokens to the client after successfully authenticating the resource owner and obtaining authorization. In some cases, the Authorization Server and Resource Server it can be in the same server.
An application which accesses protected resources. The client could be hosted on a server, desktop, mobile or other devices. In some scenarios, there is a user behind the request and the client is making a request on behalf of the resource owner (such as a user)
Now that we have described the roles, it's time to move on to the OAuth grant types. Grant types are a way to specify how a client wants to interact with the Authorization Server. Currently, in oAuth 2.0, there are two types of grant type groups and we can be separated by having or not User interaction.
Oath2 Flows – User interactive Flows
In the following scenarios, must be a human interaction at some point that allows access for the client to the access resource.
The authorization code grant consists of 2 requests and 2 responses in total, plus the final request – response to the application. The first step is for an authorization request. Authorization Server validated the request and response with an Authorization Code back to the client. In the next step, the client must exchange the Authorization Code for a token. The response will be a token. Using this token in the Header of an HTTP request, the client can access the resource server.
-It's easy for someone to steal the access token cause of browsers token transmission
-Authorization does not validate the client private key (the client HTTP request is made by using GET method)
The implicit flow consists of 1 requests and 1 response in total, plus the final request – response to the application.
The first step is for a requesting Authorization & Token. Authorization Server validated the request and response with a token transmitted in the browser. Using this token in the Header of an HTTP request, the client can access the resource server.
Oath2 Flows – Non-interactive Flows
In the following flows, there is no separate authorization stage in the sense of that a human must give consent to some resource access.
Resource owner password
The resource owner password grant type allows requesting tokens on behalf of a user by sending the user’s name and password to the token endpoint. This flow it can be useful when a legacy app tries to request a token, but this is so-called “non-interactive” authentication and is generally not recommended cause of the access of client in users username and password.
The resource owner password flow consists of 1 requests and 1 response in total, plus the final request – response to the application.
The client requests token with resource owner credentials. Authorization Server validated the request and response with a token. Using this token in the Header of an HTTP request, the client can access the resource server.
Used for a server to server communication so there is no resource owner involved at all.
The client credentials flow consists of 1 requests and 1 response in total, plus the final request – response to the application.
What is Json Web Token?
While JWT is not part of the OAuth2 standard, is commonly used as the physical structure for a Self-contained Access Token. JSON Web Token (JWT) is an open standard (RFC 7519) that defines a method for transferring claims as a JSON object between two parties. The claims in a JWT are encoded as a JSON object that is used as the payload of a JSON Web Signature (JWS) structure or as the plaintext of a JSON Web Encryption (JWE) structure, enabling the claims to be digitally signed or integrity protected with a Message Authentication Code (MAC) and/or encrypted.
Each JWTs consist of 3 parts:
Header: A JSON object which indicates the type of the token (JWT) and the algorithm used to sign it
Payload: A JSON object with the Claims and Scopes of the entity
Signature: A string created using a secret and the combined header and payload. Used to verify the token has not been tampered with.
Below is a sample JWT token. As you can see, the token has three parts separated by a [.]. Each part is encoded with a Base64.
You can try creating your own token or read an existing on through your browser at jwt.io.
Why should I use JWT token?
The main role of a JWT token is not to hide the body of the token, meaning that anyone can read the body of the token even if it is expired. Using the signature at part 3, it verifies that the body is not been modified. Also, verifies the authenticity of the source of the data (token body). So, it's very important not to store sensitive data inside your access token.The Applications that require a server-side implementation (API's etc) there are mostly communicating through a client. That client can be a mobile application, web application or a legacy system that not supports modern’s UI. This communication must be done in a secure way and the client generally have to prove their identity to the Application Server. In the JTW word, Applications (Resource Server) they are trusting the Authorization Server. Clients request a token through the Authorization Server, in order to receive an Access Token and communicate with the Application Server.
I hope this article helps you understand the basics of OAuth 2.0 and JWT tokens.
Until next time, Happy Coding!