Verification of JWT Token by service itself (possible with present symmetric encryption) & Consideration of asymmetric encryption for a JWT token

[arvindh123]

FEATURE REQUEST

1. Is there an open issue addressing this request? If it does, please add a "+1" reaction to the existing issue, otherwise proceed to step 2.

2. Describe the feature you are requesting, as well as the possible use case(s) for it.

Verification of JWT Token by service itself (possible with present symmetric encryption)

Objective

Verification of JWT token by service, without depending on auth service. Auth service will issue only token, Service by them self will verify the token

Present scenario

Every request received by service need to verify token, So the service call the auth service to validate the token, So, Auth service will have more network traffic and computation all the time.

Proposal

If service can be able to verify the JWT token signature by itself, then no need to send request to auth for verification.

At present auth service use HMAC encryption
To verify the JWT token by service itself, the HMAC secret key need to share with all the service.
Distribution of HMAC secret key to service is not good way I think, since with this HMAC symmetric key we can able to verify the certificate and we can able to create JWT Token with any other tools or codes ,

Anyone who knows the HMAC symmetrical secret key can tamper the system.

Consideration of asymmetric encryption for a JWT token (For the case service verifies JWT token by itself)

If we use asymmetric encryption key RSA256, then we need to share only PUBLIC key with all service.

Implementation rough idea:

Auth service will generate private and public key Private key is used by auth service to generate JWT with signature Private key is not shared or not distributed, It will remains in auth service

Public Key is shared to service as JSON Web Key Set - JWKS Key through HTTP endpoint example: http://mainflux-auth:9999/.well-known/jwks.json

And also we should have two token for this case , Access token with 10 minutes or less than 10 minutes expiry time and Refresh token with 12 hours or more than it .

Access Token is to access the resource Refresh Token to get access token

Additional security by rotation of asymmetric key

In additional, in auth service, we can rotate the programmatically public and private key on daily basis, and keep the public and private key in memory so no one (even us) could tamper them, Or we can keep it them as file whenever it is generated.

3. Indicate the importance of this feature to you (must-have, should-have, nice-to-have). should-have

[arvindh123]

Request for Comments @mainflux/contributors @mainflux/maintainers

[drasko]

@arvindh123 in the ideal state JWTs are stateless, have short expiry date and then can be verified even on the proxy - which saves traffic and decreases latency.

However, in Mainflux we introduce also a long-live JWTs, and these can be revoked. Revocation makes JWT stateful, and their validity must now be checked in the DB (by Auth service).

This somehow beats the purpose of JWT, but if we need revocation - this is the only solution.

Maybe we can add two types of JWT checks - for those that are short-lived and those that are long-lived, and apply different strategies.

[arvindh123]

@drasko , I agree with your point to have two tokens with short life and long life, it also mentioned in above issue.

Access JWT Token - Access token is short life , which can be stateless, This can be used by Service to do self-validate without reaching Auth service.

Refresh JWT Token - Refresh Token with long life , which can be stateful , This can be use to get access token.

To get Access JWT Token, The user should sent request to Auth service with Refresh Token, Auth service can verify the Refresh JWT token , it can also check for revocation of token and then issue Access Token to requestor.

[arvindh123]

Blocked: Waiting for new auth to merge with main branch