This whole argument conveniently ignores the case when people operate in heterogeneous environment. JWT is fairly widely supported and works fine across multiple stacks.
andre1sk
OvermindDL1
I’m using JWT (via Guardian) as a login ‘session’ token (bad form I know) and web page access permissions hit the database anyway, however the same JWT is also used on the API area, which does not always hit the database and uses the JWT course-grained permissions where possible. The JWT’s elapse really fast but get regenerated by the server as needed if the rest of the session data from phoenix matches as well. The main system uses a very very fine grained permission setup that I would not see a way to be able to stuff into a JWT in any kind of compressed way at all so I cannot use them strictly for main web interaction, but it is great for API interaction.
1
swennemans
Thanks for replying. So is it an performance argument then? Eg. the blacklist is small thus faster query results?
0
joepie91
It doesn’t ignore it. This is solved the same way as any other microservices scenario, described at the bottom of my follow-up. You don’t need cross-stack sessions, it’s solving the wrong problem.
0
joepie91
(Irritatingly, it seems Discourse doesn’t have a practical multi-reply feature.)
Major tech companies use bearer tokens, but not as their main session mechanism, rather in an SSO-like setup. They typically also keep around session for individual stateful services.
0
mbriggs
A refresh token can be revoked. The reason you can’t revoke a JWT is because by design you dont need to talk to a server. I don’t think guardian actually supports this at this time, but other JWT implementations do.
WRT blacklist is basically a session store, the difference is 1) you barely ever have to revoke sessions. That doesn’t mean its not an important feature (its extremely important), but its definitely the exceptional case. 2) You need something like JWTs anyways for stuff like JWTs anyways for APIs.
1
swennemans
@joepie91 Nice to have you back on the discussion again 
Question: How would you handle communication native app ↔ JSON API. Cookies are not of any use here. Would using a JWT with a session id would be acceptable here?
But then I’m (naively I’m sure ;)) wondering, why wouldn’t I sign and/or encrypt a session ID and put it in the authorization header myself?
0
OvermindDL1
[offtopic]
Open a reply (even at the bottom replying to no one), highlight text, select Quote Reply that appears, they should still get the notification and all and you can do it for as many people as you wish.
[/offtopic]
0
swennemans
It seems that “because by design you dont need to talk to a server” is one of the core elements of what a JWT is, and then we have refresh tokens. That seems defeating the point. As this article states:
This is a long story and I’m finally getting to the point: If you want JWT with powers to revoke the token, then you abandon the federation benefit.
Making the JWT self-descrbing means no honoring party needs to contact the issuer. Just verify the signature (verify the $20 bill is real), and then grant service. If you add in revocation as a requirement, then the honoring party then needs to contact the issuer: “I have $20 bill with serial number T128-DCQ-2872JKDJ; should I honor it?”
I see the benefits here. But it also looks a little like premature optimization.
Your ideas ?
0
joepie91
It depends. Cookies work just fine outside of browsers (any reasonable HTTP library will support them), so you can just use sessions like you would for a web-based thing. It does introduce potential CSRF issues though, depending on your setup, and a bit more state to keep around.
For application-only APIs, the solution is generally to use a standard API authentication scheme. This can be something as simple as a randomly generated API key in a header (over TLS, naturally). Like for sessions, invalidation is a concern, and so you want to avoid stateless tokens unless scale demands it.
For APIs that need to serve both standalone applications and web-based applications, you have two options:
- Either build a separate API or authentication scheme for each case. Standalone apps authenticate like above, web-based things use sessions. Especially if the type of operations that the app does are significantly different from the type of operations the web-based interface does, this is an attractive option maintainability-wise.
- If you’re on a deadline: build a single API that only supports session cookie authentication, and simply use a HTTP library in your stand-alone applications that supports cookies. Of course you still need to worry about CSRF - sending along the token in a header should suffice, and is possible in both the web-based interface and the standalone applications.
Because JWT is a generally well-tested implementation for what it does (ie. signed claims). For security-related things, you should always aim to use existing and well-tested implementations, rather than implementing your own. It’s really easy to mess something up fatally in security/crypto, and there’s no point making (likely fatal) mistakes that somebody else has already made and fixed for you.
Excellent, thanks, that helps
4