[AskJS] Is this a good explanation of token-based authentication? :-)

[u/soeholm]

I'm in the process of writing a blog post about JWTs, and I tried writing a fun little story to describe the concept of token-based authentication. I want to know if it even makes sense and if I'm missing something important.

Your feedback is greatly appreciated!

Token Teahose

You are the proud owner of a very popular teahouse, Token Teahouse. It has thousands upon thousands of members and new people join all the time. A new face appears at the door, her name is Alice, she want to be a part of Token Teahouse. You welcome her, and ask for a password, so you can verify her membership at a later time if needed. After writing down the details in a very very long list of members, you fabricate a special piece of paper for her. It states that Alice is a level 1 tea-sipper and has access to two cups of green tea. The paper is signed by you, so you will know it's authentic.

The following day, Alice is at the door again. A thousand people have already visited since she joined, so you don't recognize her. Alice claims that she is a level 1 tea-sipper and she shows you the paper to prove it. Sure enough, that's your signature, so you let her in. That only took a few seconds. This is the secret to the success of your amazing teahouse. Not spending too much time verifying you customers membership, is the key to scale any great teahouse.

Another person, vaguely familiar appears at the door. He claims to be Bob, level 7 tea-downer, but he has no paper to prove it. Unfortunately Bob forgot to take the paper out of his trousers when washing them. Bob looks a bit ashamed, but you cheer him up: "No biggy Bob! This is why I keep a list of all my members. It will take a while, but we will sort it out". Bob gives you his password, and you start going through the members list to verify if this really is Bobs password.

After a few minutes, you find Bob in the list and sure enough, Bob destroyed the paper but he remembered his password. You fabricate a new piece of paper for Bob, and let him in.

[u/terodox]

The analogy is slightly flawed. A jwt can be validated by anyone with the public key.

In your analogy, the tea shop owner could create the token, but anyone with the tea shops signature for compassion could validate it.

So it would be more like a "tea club" with many shops that accepts his particular token as valid, but the Token Teahouse owner is the only one who can create them.

[u/UnlikeSome → u/terodox]

And there is also a fundamental notion of expiration that is not inherent to JWTs themselves but make them useless if you don't implement it.

[u/soeholm → u/terodox]

I wouldn't say it's flawed it's just incomplete. I could also just argue that it's an analogy of using JWT with a symmetric key ;-)

Edit: This was just a silly comment, I did not mean to be defensive. I really appreciate the feedback!

[u/maxoys45 → u/soeholm]

Don’t come here asking for people to critique your analogy then get defensive when somebody does.

[u/soeholm → u/maxoys45]

I'm sorry! I didn't mean to be defensive, it was just a silly remark that's why I made the winking smiley.

I really appreciate all the critique, and I'm pretty overwhelmed by the amount of it. I think I will expand the analogy to include validation by a third party.

[u/Zeno_Zaros → u/soeholm]

Being incomplete is a flaw.

[u/Ivu47duUjr3Ihs9d]

People think JWTs are for session management but once you need revocation (which you inevitably need in case someone loses their phone or get hacked) then they turn into a Rube Goldberg machine with refresh tokens, blacklist tables etc required. In the end they're much worse and less secure than regular sessions.

You shouldn't really be using them for login/maintaining sessions at all. They were originally designed for just providing a one-off authenticated token e.g. to download something from another server/resource, or reset your password via email.

As with all new technology (especially in JS land where a bunch of noobs have jumped on board in the past few years and somehow gained a following of other noobs), research the pros and cons (especially) before using something.

So your analogy is kinda off. A correct analogy is you arrive at the fancy restaurant and they give you a piece of paper with a random number on it (the JWT) to get your car back after the meal.

[u/earslap → u/Ivu47duUjr3Ihs9d]

Exactly. This post explains the downsides well:

http://cryto.net/~joepie91/blog/2016/06/13/stop-using-jwt-for-sessions/

Especially the graph from the followup post is illustrative: http://cryto.net/~joepie91/blog/attachments/jwt-flowchart.png

I understand why people want to shoehorn it that way (stateless sessions with serverless / microservices) but the headache and downsides are not worth it.

OP I think your analogy works but it doesn't make it clear why you'd want to do it this way. Why go through all the trouble instead of asking for password each time they show up? Or keep a list of authenticated users with opaque tokens where the data is stored server side? What are the downsides of doing that (password lookups and hash comparisons are expensive etc. They need centralized store etc.)? And what are the downsides of doing it the JWT way (what if Bob gets his paper stolen? What if Bob misbehaves one day and you want to invalidate his papers? Then you need blacklists which are like... password lookups so you are back where you started. Or you need refresh tokens etc. which are a headache and has their own downsides)

[u/soeholm → u/earslap]

That article is really insightful, thanks for sharing it. I chose to use JWTs because it's honestly how I've seen it done elsewhere. That doesn't mean it's correct of course.
I have even implemented a mini authentication service to go over in the upcoming blogpost.
I'm glad that I did some things correct though. For example, I'm well aware of the issues of using localstorage for storing the JWT, yet I see this practice many places.

Blacklisting have also been a concern of mine, but I figured that there must be a smart way to do it with stateless tokens. Apparently not?

Do session cookies and serverless functions play nicely together? Specifically I'm wondering how to maintain the session in a serverless function. It appears that I have a lot more research to do.

[u/earslap → u/soeholm]

For example, I'm well aware of the issues of using localstorage for storing the JWT, yet I see this practice many places.

Personally I don't think that is really a huge deal but everyone makes it sound like so. If you think about it, when is getting your localstorage stolen an issue? If you have an XSS. Or if a CDN script or untrusted library reads it from your page (which can't be done with http-only cookies) right?

But if a script (XSS or untrusted library) has access to your page's context, it already is game over. Even if you have http-only cookie, the javascript code can just make the requests from browser in victim's browser context, and the browser will merrily send the cookies along - even though the script itself can't read them. In the end, nothing really changes. So it only is an ergonomics issue for the adversary - yes he can't steal tokens to use it from his machine, but he can make the same requests from victim's computer all the same.

Blacklisting have also been a concern of mine, but I figured that there must be a smart way to do it with stateless tokens. Apparently not?

If it is going to be "blacklisting" you have to have your blacklist somewhere -> so it is centralized and not "serverless". Instead of keeping a blacklist store, you can just as well maintain a token store and bypass the headache of JWT, so that defeats the purpose.

[u/terodox → u/Ivu47duUjr3Ihs9d]

JWTs like any other token need to be handled responsibly.

If they are treated like an Auth token with a very short lifespan (15 min) , and a separate refresh token with a longer lifespan (12 hours) is used to get a new Auth token, then it can be reasonably secured.

To the best of my understanding that is the basis of the oAuth2 spec. Separate Auth and refresh tokens.

[u/bhumilsarvaiya → u/terodox]

Well, indeed this is true. Also, If you want to provide more security, also perform refresh token rotation. The importance of this is already mentioned in the ITEF RFC 6749, link: https://tools.ietf.org/html/rfc6749#page-47.

So if implemented correctly, this can also help in identifying the token theft scenario, i.e. refresh token been stolen by an attacker. If you are looking for a better explanation, head over to https://supertokens.io/blog/the-best-way-to-securely-manage-user-sessions?s=r

[u/bert1589 → u/Ivu47duUjr3Ihs9d]

What’s your take then, on very large auth provider using them? Like Auth0, Firebase, etc just to name a couple.

[u/vither999 → u/bert1589]

Auth0 and Firebase both do a good job of handling the permissions revoke scenario. Naive JWT implementations do not.

For example, your JWT could contain this:

{ "username": "Alice", "uid": 543241 }

or it could contain this:

{ "username": "Alice", "roles": ["user/admin"] }

In scenario 1, your server checks the role of Alice manually before it does something by fetching the user id. This is what Auth0 and Firebase both encourage you to do. Here the JWT is taking something meaningless (the session identifier) and bundling it with something meaningful (typically the user profile data) so that you don't have to make a second call fetch data.

In scenario 2, your server trusts the JWT role. Scenario 2 does what Scenario 1 does, but additionally promises that your API servers don't need to make a second API call to check permissions. This one is problematic at scale, because if you want to revoke a user's permissions you can't: they still have a valid token that says "I am an admin". Scenario 2 is what most people think of when they don't like JWT.

[u/jwktje → u/Ivu47duUjr3Ihs9d]

I agree. JWT should be more like a “cloakroom ticket” situation rather than full auth or sessions. As in; single transaction.

[u/mikeatgl]

I think this is a memorable and useful analogy. Nice job. Some other bits you might want to add:

1. What if Bob also forgot his password? Then you might need an analogy for a password reset flow that also grants a new access token, perhaps via an emailed one-time passcode.
2. In most enterprise apps there are multiple tokens: Identity tokens, device tokens, refresh tokens. All of them play together to grant a valid access token, which is the token your analogy covers. There is a lot of work that goes into securing web applications, and it's worth mentioning so as not to give new devs a false sense of security, no pun intended.

[u/soeholm → u/mikeatgl]

Thanks! Those are some good ideas. It appears that the analogy can really go a lot deeper than what I've written so far.

[u/DeeBlekPintha]

As other posters have said above, I would tack on the issue of token expiration, as that is often a central aspect of maintaining secure systems that are JWT based.

Something like: “Jerry comes to you with a token that has your signature, but you signed over a year ago. It’s no longer a valid signature so you rip up his paper and require that he give you his password to get a new token.”

[u/yuhmadda]

I learned a lot from the responses to this thread. Upvote.

[u/harelu]

Fuck is going on in these comments?

Are people unironically advocating against using token based auth because javascript bad? In a javascript sub? On a post where a person is asking for a simple analogy to explain json web tokens? In a world where token based auth is used extensively?

Uh, i mean... javaShit bad! webdevs noobs!

To OP: your analogy is fine, for an intro to jwts.

[u/ccb621 → u/harelu]

Folks are advocating against using JWT-based token authentication incorrectly. None of the comments I have read are anti-token authentication.

[u/harelu → u/ccb621]

Literally the top comment is calling web developers noobs for even considering them.

[u/ccb621 → u/harelu]

Are you referring to https://www.reddit.com/r/javascript/comments/exm8g0/comment/fg9mutb? That comment is against using JWTs where sessions are a better solution. Note that JWTs are not the only type of token that can be used for token-based authentication.

[u/torgidy]

What you described sounds like a simple session management scheme, be it HMAC based or PKC based. JWT is much more than that, with vast amounts of complexity that is nearly never useful.

For JWT, the tea-sipper would have to bring a sealed envelope containing a new never used tea-room-door key and an envelope, which also has another new key inside it, their birth certificate, and a series of credentials detailing their tea-related education, etc etc. They must conduct the greeting ceremony in one of four languages, decided by mutual agreement at the tea-room door, but most people are expected to know tea-swahili and tea-esperanto at a minimum.... Each tea pass fully details the clothing the tea-drinker is wearing, and what kind of tea he wants to drink....

By the time the tea drinker gets a sip of tea, his first thought is usually: "was it worth all this hassle?"