Sorry if this is a dumb question, but what's exactly the difference between JWT and OAuth?
(EDIT: typo)
JSON Web Tokens
31–40 of 76 posts
Re: JSON Web Tokens
#32Thanks for spreading the word Adam! We (Auth0) are heavy promoters of the usage of JWT. Here are some articles about using JWT instead of cookies on single page apps with APIs, and its pros/cons. https://auth0.com/blog/2014/01/07/angularjs-authentication-w... https://auth0.com/blog/2014/01/27/ten-things-you-should-know...
JWTs seem really great to handle auth on single page apps with APIs, but I don't quite understand something yet:
What is the best and recommended way to implement a "remember me" feature?
I'm using the "angular-fullstack" yeoman generator (https://github.com/DaftMonk/generator-angular-fullstack) which uses your npm packages, but it lacks of a feature like that, and the app is pretty much unusable, user must log in every time after closing the browser...
Re: JSON Web Tokens
#33How do you invalidate tokens?
You can store the expiry time in the token itself. Then it is up to your server to validate that the token is still live. If you need to mass invalidate every token, you change the signing key.
So is there any way to do single-sign-out if using these tokens for authentication?
Re: JSON Web Tokens
#34I think writing your own variation of this at one point is a sort of rite of passage for web developers. I thought I was so clever with my custom PHP framework and sessionless backend. That said, it's done because it works well and makes sense. I'm glad to see we're finally settling on a recommended way of doing this. I've recently incorporated JWTs into my own application. One of the questions I'd like to ask other…
One way of doing it is having an out-of-bands way of refreshing tokens in responses. So if the token is about to expire you can return an updated one on the side-channel.
We've been doing this for a while in our angular apps using response interceptors: http://engineering.talis.com/articles/elegant-api-auth-angul...
Re: JSON Web Tokens
#35Sorry if this is a dumb question, but what's exactly the difference between JWT and OAuth? (EDIT: typo)
JWT contain a payload, thus the token itself can contain auth information, while OAuth tokens are "dumb" and you have to store the token somewhere serverside to verify authentication.
This makes JWT great for simple APIs.
Re: JSON Web Tokens
#36Thanks for spreading the word Adam! We (Auth0) are heavy promoters of the usage of JWT. Here are some articles about using JWT instead of cookies on single page apps with APIs, and its pros/cons. https://auth0.com/blog/2014/01/07/angularjs-authentication-w... https://auth0.com/blog/2014/01/27/ten-things-you-should-know...
JWTs seem really great to handle auth on single page apps with APIs, but I don't quite understand something yet: What is the best and recommended way to implement a "remember me" feature? I'm using the "angular-fullstack" yeoman generator ( https://github.com/DaftMonk/generator-angular-fullstack ) which uses your npm packages, but it lacks of a feature like that, and the app is pretty much unusable, user must log in…
Store the token on a cookie or localstorage (see store.js for instance).
Re: JSON Web Tokens
#37JWTs are a pretty great solution for various authentication and authorization related problems, like OAuth tokens, password reset tokens and the like. Using an information-bearing (and signed) token like a JWT tends to make your web apps less stateful and simpler, by offloading the problems of determining authorizations to a single, central location. The main downside is that the representation (base64-encoded json)…
This seems like a case where Base-85 [1] would have been a better choice than Base64.
Re: JSON Web Tokens
#38JWTs are used to great effect in Google's Wallet Digital Goods apis to allow you to control which payments are allowed and authenticate postbacks ( https://developers.google.com/wallet/digital/docs/tutorial ). It's a shame that service seems to be more or less dead...
I hope it doesn't die! I'm building a service based on it :)
I think it'll be around for a while but it's definitely in a strange place. Some of the pages like the signup page and checkout settings page ( https://checkout.google.com/inapp/merchant ) just give a service unavailable error half the time, and it's been that way for months. And in the merchant center, the 'Business insights' section doesn't work and hasn't for months either. Last week we couldn't access our order history for a few days. The sandbox payments environment doesn't work most of the time either, and even production sometimes has errors loading the payments screen.
It's also really limited in that there is no API to get order status to check if a subscription is still active - so if you miss the cancellation postback, you have no way of knowing which subscriptions are active and which aren't. You also can't change the value of an active subscription. That was the biggest thing people were asking about when they introduced it at IO three years ago, and it's still not fixed.
So if you are in a country where you have a better option you might want to consider it :)
Re: JSON Web Tokens
#39JWTs are a pretty great solution for various authentication and authorization related problems, like OAuth tokens, password reset tokens and the like. Using an information-bearing (and signed) token like a JWT tends to make your web apps less stateful and simpler, by offloading the problems of determining authorizations to a single, central location. The main downside is that the representation (base64-encoded json)…
This seems like a case where Base-85 [1] would have been a better choice than Base64. [1] http://rfc.zeromq.org/spec:32
Why would you consider Z85 to be a better choice? When you take URI encoding into account, Base64 is both simpler (no need for %-encoding)[0] and more space efficient (1.75 URI characters per byte for Z85, and 1.33 for Base64)[1]. The very first line on jwt.io says, JSON Web Token (JWT) is a compact URL-safe means of...; being URI-safe appears to be an explicit design decision.
[0] All but six of Z85's special characters get encoded by Javascript's encodeURIComponent:
: + = ^ / ? & [ ] { } @ % $ #
(68 * 1 + 17 * 3) / 85 = 1.4 uri_chars/char
1.4 * 5 / 4 = 1.75 uri_chars/byteRe: JSON Web Tokens
#40I think writing your own variation of this at one point is a sort of rite of passage for web developers. I thought I was so clever with my custom PHP framework and sessionless backend. That said, it's done because it works well and makes sense. I'm glad to see we're finally settling on a recommended way of doing this. I've recently incorporated JWTs into my own application. One of the questions I'd like to ask other…
Yes, it is a bad UX that the session expire randomly and how to handle this is a whole subject per se.
Here are my two cents:
- Web Apps: If you set an expiration of 1 week, do not use the token for 1 week. Use it for a day and then use the token to get a new token. This way every time your user uses the application, he gets one extra week logged in. This is not different than the normal concept of session and cookies.
If the user does not use your application for a week, next time he go to your app, he will have to login again and this is fine and widely accepted.
- For Mobile/Native Apps: you can use the same explained above, but that's not how most of the mobile applications work these days, I can open facebook after a month without using it and I'm sure I will not need to login again. One way you can do this is to use a refresh token that never expires to fetch a JWT that does expires. The problem with a token that never expires is that it never expires, what happen if your phone is stolen?. In my opinion, there must be a clear and easy interface where the user can revoke these tokens but looking at random alphanumeric characters wont help, so the best practice will be to show something like "Revoke access on John's IPad" this means that the refresh token must be requested for an specific device name.
Certain events can trigger things, if you lost your wallet (at least in Argentina), first thing you do is to call the bank to disable your credit cards. If you forget your laptop in a friend's house and you don't want then to read your Facebook you will probably change your password. Changing the password is usually a good event to
1. Revoke all refresh tokens (for native apps)
2. Anchor the "iss" date for JWTs, this means that tokens issued before the last password change are not longer valid.
Because changing the password can have other purposes, you can also put a prominent button in your UI: "Close session on all browsers and devices", this will delete all refresh token and store the timestamp to check against the JWTs.
We might write a blog post soon about this on Auth0's blog: https://auth0.com/blog.