What's with the shouty title? Well, I wanted to grab your attention and get straight to the point:
🗣️🗣️ Don't use JWT for your backend authorizat...
For further actions, you may consider blocking this person and/or reporting abuse
You can implement sessions and include them in the JWT, and during the JWT validation (probably in a middleware) you can check if the session is valid, this way you can invalidate a session and even if the JWT is valid you block access.
You can also use a blacklist, you can implement it with redis and add JWT tokens within this blacklist and consult this blacklist before authorizing in the middleware.
While that approach has been used in the past @wiliamvj , I wouldn't recommend it and here's why:
In the first proposal the JWT holds an identifier to a session which is managed server side like this:
Then if the session ID is valid server side, you move forward. This functions like a cookie. This way you lose the trust, independent verification, and statelessness in the JWT because of the addition of a state to it.
In the second proposal, there's addition of a token revocation mechanism, which has it's own set of downsides. One of which is that it relies on reading a negative list of what's NOT allowed, which can be attacked more easily (e.g. DDOS) than reading from a list of what IS affirmatively allowed (e.g. inserting a signing key).
The thing is Token Revocation doesn't really solve the New Enemy problem unless on every authorization mutation you can individually track down and revoke every impacted token, or rotate your signing key and issue all new tokens. Both proposals are fraught with errors.
Similarly for the sessions, you would have to track down which sessions are impacted by each and every authZ update (and their transitive downstream implications) and update or invalidate the sessions.
Hope that clears it up!
I use JWT for authorization. But if i stop using JWT, what other best alternatives do i have?
Well that depends on what your usecase is @keyru_nasirusman . Here are some possibilities:
Writing your own custom authZ solution is an option and there are libraries (such as CanCanCan, Flask Principal etc) that handle this for you. I'd like to add that while it's a good learning curve to write your own custom authorization, doing so in complex production environments can get messy very fast.
If you want to abstract your authorization logic from your code you can consider a policy engine. The policy engine is centralized (maybe running in a sidecar) and all authZ requests go out to this engine. This works great when you already have all of the data ready at the time of the call. For ex: An HTTP filter or something like that where the data that you're making your request based on is already available to you in the form of the IP address of the caller or so on.
If you are building for scale and want a system that is flexible, you can look into Relationship-Based Access Control. This is a fairly new system and is gaining in popularity. You essentially model all your relationships and store them as edges in a directed graph. The advantage is that it can really scale. For example: this is the system Google uses across all their services such as Cloud, & Docs with a service they named Zanzibar. There are some open source software that are based on Zanzibar as well.
Feel free to ask more questions, or tell me your usecase and i'd be happy to assist :)
Thanks, I will read more on the options you mentioned above (I am interested on the Zanzibar based softwares). I will also be glad if you write an article on any of alternatives of JWT.
I will definitely be writing about Zanzibar soon. Cheers!
Maybe add a clarification for those who might confuse Authorization and Authentication.
That's a fair point as people often conflate the two
Authentication is about making sure the user is who they say they are. You're proving your identity with something you have like a username and password.
Authorization is the next step. Once a user's identity is confirmed, authorization decides what parts of the application they are allowed to use.
So, authentication checks who you are, and authorization determines what you can do or access in the application.
Give a read to OAuth2 specs, refresh tokens, and short-lived access tokens - you might change the way you look at this.
OAuth scopes face the same problems as pre-canned roles - Sometimes they're not fine grained enough, and if you just do one-scope-per-thing that can be done, your scope list gets too big to store and manage effectively.
Here's a real-world example: You have a scope for an Admin role. Now suppose you need a billing-admin (only change billing settings), or auditor (see everything, do nothing), or an assistant (federate access, do nothing).. you get my drift.
Eventually user-defined roles really break the OAuth paradigm.