Comparing JWT and OAuth is like we are comparing apple and apple cart. JWT is an authentication protocol whereas OAuth is an authentication framework. It is possible to have an OAuth implementation that issues JWT as an authentication mechanism. Before getting into more details let’s first understand individually, what is JWT and OAuth.
What is OAuth?
OAuth is an open standard for access delegation, commonly used as a way for Internet users to grant websites or applications access to their information on other websites but without giving them the passwords. This means it is a strict protocol for the issuing and validating of signed access tokens by providing limited access to a web service. Just remember OAuth only works using HTTPS.
How OAuth works
Let’s assume a user has already signed into one website or service. The user then initiates a feature that needs to access another site or service. The following happens
- The first website connects to the second website on behalf of the user, using OAuth, providing the user’s verified identity like client id, secret key etc.
- The second site generates a one-time token and a one-time secret unique to the transaction and parties involved.
- The first site gives this token and secret to the initiating user’s client software.
- The client’s software presents the request token and secret to their authorization provider (which may or may not be the second site).
- If not already authenticated to the authorization provider, the client may be asked to authenticate. After authentication, the client is asked to approve the authorization transaction to the second website.
- The user approves a particular transaction type at the first website.
- The user is given an approved access token.
- The user gives the approved access token to the first website.
- The first website gives the access token to the second website as proof of authentication on behalf of the user.
- The second website lets the first website access their site on behalf of the user.
What is JWT?
JSON Web Tokens are an open, industry standard RFC 7519 method for representing claims securely between two parties. It defines a compact and self-contained mechanism for transmitting data between parties in a way that can be verified and trusted because it is digitally signed. Additionally, the encoding rules of a JWT also make these tokens very easy to use within the context of HTTP.
JWT tokens are JSON encoded data structures contains information about the issuer, subject (claims), expiration time etc. It is signed for tamper-proof and authenticity and it can be encrypted to protect the token information using symmetric or asymmetric approach. JWT is simpler than SAML 1.1/2.0 and supported by all devices and it is more powerful than SWT(Simple Web Token).
The basic idea is that a user will provide a user credentials combination to our auth server. The auth server will try and find the user and if the credentials are good will issue a token that the user will send to access resources on servers protected by JWT Authentication.
Here is an example token:
The token consists of three parts:
All of these parts are base64 URL-safe encoded to make them safe to add in request URLs. For better understanding please visit this link to understand Encode/Decode format.
The main strength of JWT is that it handles your application’s user session in a stateless scalable way. The use of embedded claims means we can easily extract user session information from a server that has no access to your system’s user/session DB. For a distributed Service Oriented Architecture this can be tremendously useful.
Stay tuned for more articles. Happy coding 🙂