Jwt Authorization
The JWT is used in many application as it offers various features for authorization.In this story we will learn about authorization using Json Web Token(JWT).
What is Authentication?
Suppose you are inviting someone as a guest in your house and he/she arrives at your font gate either security guard or security camera or you will check whether its the same person you invited or not. If yes then that person will be allowed inside the house. In case some other person arrives then you wont allow him/her as you were not expecting that person.
So in this scenario we have identified or authenticated the person and then allowed him/her.
In case of some backend application we check whether the user exists in the system if yes then that user will be recognised.
Difference between authentication and authorization
Considering the above example we understood what is authorization. Now lets again consider the above example, so will you allow that person in a room where you keep all your work related stuff or your very important documents. No right, because that person is a guest and letting that person access to those stuff is irrelevant and might lead to some problem.
So the person is authenticated but not authorized to enter some places of the house.
But the family members has access to those important places . So they have he authority to access those important stuff.
This is the idea of authorization.
You might have seen in youtube you can see all the videos without logging in but you can’t post a comments, subscribe to a channel or like a video.That is because user is not authorized to post a comment or like a video without logging in but allowed to watch video. And that makes complete sense. With user logged in youtube will know who is posting comment or who is liking the video.
What is JWT?
Json Web Token(JWT)
Its an encrypted string which is obtained by encrypting json object which has 3 components namely : header, payload and signature. we will know about these in later part of this story.
This encrypted string is used by the client to for authorization and exchange information.
Once the client gets authenticated a token is generated according to the user data and is sent to the client.
Components of JWT
As we can see in the image that it has 3 parts seperated by ‘ . ’ .
First part (Header) — eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.
Second Part (Payload) — eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.
Third part(Signature)-SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c
Header — The header has 3 claims
alg — this claim specify the algorithm used to signing/decrypt the token. Like HMAC SHA256 or RSA. For unencrypted token its value should be none.It is a mandatory claim.
{
"alg": "none"
}typ — type of token.It may happen that token is a mix of other objects including a JWT header, so we need to specify the media type for that , for this purpose this claim is required, but this happens rearly .This is an optional claim.When present its value should be “JWT”.
{
"typ": "JWT",
"alg": "HS256"
}cty- This claim specifies the content type of payload. This is also an optional claim. If payload carries usual arbitrary data then there is no need for this claim but its needed for instances where payload is a JWT (condition of nested JWT), then this claim must be present and carry value “JWT” , which tells that further processing of payload is required as payload contains jwt. This condition is rare and this claim is rarely present.
Payload
This is the section which has all the user related data. No claims are mandatory here, but some claims have predefined meaning to it. These claims which have some specific meaning attached to it are known as registered claims.
Registered Claims-
exp- this claims contains the time instance at after which the token should be considered invalid. This can be set at the time of creation of jwt and can be used to check whether the token is valid or not. The format of time instance should be second since epoch (Unix epoch (or Unix time or POSIX time or Unix timestamp) is the number of seconds that have elapsed since January 1, 1970 (midnight UTC/GMT)).
nbf — (not before) this is opposite to exp and its value should be in seceonds since epoch. This claim contains the time from which jwt is considered valid.
iat- The time of at which the jwt is issued.
jti — This claim contains unique value and can be used to uniquely identify a jwt with similar contents. There can be different implementation for generating unique value for this claim.
iss — case sensitive claim that identifies the party that issued the jwt.
sub — a case sensitive claim that carries information that uniquely identifies the party that this jwt carries information about.
aud — array of unique values that identifies recipient of jwt uniqely.
Signature — The signature part contains base64 encoded header , base64 encoded payload and a secret key. The secret key is used to encrypt the content inside signature. The signature is used for validation of the token and also checking whether the contents inside jwt are not tampered or changed.
HMACSHA256(
base64UrlEncode(header) + "." +
base64UrlEncode(payload),
your-256-bit-secret
)Signature validation
The secret/private is used for validation and generation of the token .At the time of validation the header and payload both are used to generate a signature and if that signature matches the signature which is there in the jwt then token is valid otherwise there can be some tampering in the token payload or header.
Follow the link for jwt implementation spring boot .JWT authorization implementation.
