JSON Web Tokens

The OAuth way of doing things is to have two tokens: an auth token and a refresh token. The auth token is the one you send with your requests to authenticate them (and can be a JWT), but it has a very short expiry time (say an hour). The refresh token is typically a random string that's stored in your database and can be used in place of a username/password or other credentials to get an auth token.

This way you can store (in an app, or a browser) the less sensitive refresh token (which might expire after a week or so) instead of the highly sensitive permanent auth credentials.

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.

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.

I've been thinking about the same problem lately and have come up with an approach for my use-case that might work:

* Set expiration to a low value (~15 minutes)

* Every generated JWT also gets added to an "issuedTokens" collection for each user

During JWT validation, if the expiration has passed, an "Expired" response would be returned from the server (ex. 401 w/ "Expired" in body). When the client receives this status, it should initiate a refresh process which trades an expired token for a new one.

The refresh endpoint on the server should take an expired token and perform the following:

1. Validate token (except expiration)

2. Retrieve user ID and check if token is in its issuedTokens collection

3. Issue a new JWT

4. Remove the expired token from the collection and add the new one

Upon failure of any of these steps, an Unauthorized error should be sent to client which then requires logging in again.

To prevent a never-ending build-up of issued tokens, we can set a TTL on the tokens in the issuedTokens collection. Set the TTL value to the amount of time that a login should be active for before requiring logging in again.

This approach doesn't hit the database unless you keep trying to refresh an expired token. In which case you can make use of a cached blacklist of failed tokens. This can reside next to the application itself if treated as a cache layer.

This is definitely just a work-in-progress solution that I'm about to test out. Let me know your thoughts on it.

>Looks definitely easier than SAML.

With the exception that it's only signed, not encrypted, yes. SAML does have the advantage in that regard, but I've never been a fan of using clients to transport sensitive information anyway, even encrypted.

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...

The pattern I've seen used most commonly is the latter situation you described. The user authenticates, and is issued a signed JWT which includes their user ID and (optionally - I actually talk about this in my comment here: https://news.ycombinator.com/item?id=8283530) an expiration. You can also delegate roles and permissions through the JWT, which makes for a really slick authorization pattern if you've got a case where you'd like to easily change a user's permissions. I mean, you can add whatever you want to a JWT - I guess I'm just offering suggestions based on my own experience. IMO, user ID is the best way to go, because it's only a single field you have to maintain. If you start adding too much information in there you might end up with a bunch of tokens with old property names etc. Personally I just tried to closely follow what OAuth specified should be added to OAuth JWTs. I think I've got "issuer", "audience", "expiry" and "id" in my current tokens, but adding a list of permissions would be a good choice too in my opinion.

I think what everyone needs to remember is that SSL is a must for these things. If you're issuing non-expiring tokens over non-SSL you're just giving the keys to the castle away. Another thing that should be considered is token storage. I'm using local storage right now which works for me, but it just means I need to be more careful than ever about XSS exploits, because there's no "HTTP only" option for local storage!

Is there a video of your talk available?

'just an hmac token', but attached to the payload in a well-structured way. Very required for the proliferation of libraries across all languages.

There is also JSON Web Encryption, built on top of JWT, which provides encryption in addition to signatures. https://tools.ietf.org/html/draft-ietf-jose-json-web-encrypt...

This seems like a case where Base-85 [1] would have been a better choice than Base64.

[1] http://rfc.zeromq.org/spec:32

Yes, this is a real problem, tokens can get very large if you put too much information.

HTTP does not define any limit for headers, but most of the Web Servers have a default limit, Apache 8kb, IIS 16kb, nginx 4kb (see this question on SO [1]). If your JWT exceeds these limits you will get a "413 Entity Too Large".

It gets only worse if you need to use a query string instead of a header because the limits are lower and IE has a limit too [2].

Solution: carefully design your JWT, what information you will put on there. You usually don't need everything, store only the things you will use on every request, like the user id, name, email, roles are good candidates. Do not try to put the entire Facebook or Linkedin profile on a JWT.

Beside the limits, it will make the request bigger to transport and maybe even slower to verify.

[1]: http://stackoverflow.com/questions/686217/maximum-on-http-he... [2]: http://stackoverflow.com/questions/417142/what-is-the-maximu...

I have used itsdangerous a lot with DRF and it works really well, good call.

Same with Firefox on Linux. The 'S' letters are very noticeable.

That's probably best addressed by the “security considerations” section of the JWT spec:

https://tools.ietf.org/html/draft-ietf-oauth-json-web-token-...

My short answer to “How secure are JSON Web Tokens?”, though, would be that the relevant security issues are likely to come in “around” the use of JWTs, not as a result of JWTs themselves being “weak”. JWT is just a set of conventions for encoding authn/authz claims in JSON and then encrypting/signing the result.

The concepts of JWT encoding and encryption are orthogonal. While they can be used in conjunction with encryption, the question of whether or not the tokens themselves are "secure" is outside of the scope of their use. All standard encryption practices apply and there isn't anything special about using encryption with JWTs.

Answering your questions completely depends upon your application. There is, in general, no "most secure" algorithm for encryption and what you handle on the server completely depends upon the security goals of your application.

For example, I'm currently working on something that passes JWTs unencrypted and unsigned because the application simply doesn't need it. Furthermore, the application does have a method of tracing used tokens, but there isn't really a need for rotating keys or anything else like that.

Hope that helps.

It looks to me like the data is cryptographically signed

Tokens can be either signed (using JWS [0]) or encrypted (JWE [1]), which means that you're just trusting that your encryption/signing key hasn't been leaked.

[0] https://tools.ietf.org/html/draft-ietf-jose-json-web-signatu...

[1] http://tools.ietf.org/html/draft-ietf-jose-json-web-encrypti...

The client must send authentication credentials to the server. For example, a username/password that's provided by a user. There's nothing initially stored on the client that allows it to authenticate without user input.

Of course, you could use a holder of token scheme to authenticate in the case of server to server communication. However, in this case you're making an assumption that both servers can prevent access to the shared secret.

MAC schemes like JWT provide message integrity and a form of authentication that can't always be provided by TLS/HTTPS.

The simplest way of describing it is that with HTTPS, when sending data to/from a server and a client (the client may even be another web server) you can be assured no one but the server or client can see or tamper with the data in transit.

But the client is still able to trick the server, or vice versa, at the application level. To prevent that you need a message signing scheme (aka a MAC), and this is an example of one.

For the case of password reset links from an email, generally speaking there's no point in using something like this; a one-time random token that you track and expire on the backend makes more sense. You'd only want to use a MAC if you need to freeze some kind of state in the URL and retain it, like perhaps a user's IP address. Then you can verify that the user's real IP address does indeed match the IP address in the URL; they can't tamper with the URL to change the IP address if a MAC is used.

I don't know why anyone would want such a feature for a password reset function, and you could also replicate that same behavior just by storing the IP on the backend as well (though while also perhaps making your application somewhat more complex in the process), but that would be one example of doing something like that in a secure manner while still letting the client keep track of the state instead of the server.

One common use of tokens like this is to defer state retention to all your clients so your server can do less work per request and store less data. Simply verifying that the MAC for a message is valid in every request is a lot faster than making a database/data store query to return session info for every request.

You should still use HTTPS with this. The signing used here is not to protect the payload, but to ensure that an authority that you trust has issued the token.

The advantage is particularly that you don't have to use basic auth. Basic auth in a browser context is more or less a non-starter. The browser's basic auth implementation will take over and provide a generally poor, uncontrollable user experience.

For server-to-server authentication, there is less to recommend this, although it does allow services to authenticate without having to check a credential against a data store someplace.

If you have a payload that does not require encryption, but does require authentication, then Hawk (from WalMart) is an option.

https://github.com/hapijs/hapi-auth-hawk

https://github.com/hueniverse/hawk

Supported langs: https://github.com/hueniverse/hawk/issues?q=is%3Aclosed+labe...

I hope it doesn't die! I'm building a service based on it :)

Alternatively + [IMHO] more robust security-wise (although both great projects): https://github.com/lynndylanhurley/ng-token-auth

I think I can answer my own question.

The client doesn't get a shared secret. JWT is a server sending a token to the client which the client then sends back like a cookie. The client isn't allowed to modify the token or the data inside it.

It's like a signed cookie.

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.

To start with, OAuth is an authoriation protocol and JWT is a token format (a signed and/or encrypted piece of data). So they are orthogonal.

The OAuth protocol doesn't specify which token format to use. Normally people have been using an "opaque" token, this is a token that doesn't have any meaning nor content but the meaning is stored somewhere. Here is an example of a table storing tokens and the scopes (permissions) associated to them. Every time an API Call is made, you would have to check against this table to see if the token sent in the Authorization header has the necessary scopes to call the API.

token | scopes oiajoeihfe9jh9283n | read.userinfo, post.friends uhuernvmiwmwo38h2g | read.userinfo

If you would use JWT you wouldn't have to store that information because it would be part of the token (i.e. stateless)

This would be a counterpart JWT

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1c2VyX2lkIjoxMjM0NTY3O DkwLCJhdWQiOiJodHRwOi8vbXlhcGkiLCJzY29wZXMiOlsicmVhZC51c2VyaW5 mbyIsInBvc3QuZnJpZW5kcyJdfQ.tnLKyCWhVfkj2v15maCBJBVgPO08zFp2Lh n4Vkb4OoU

header: { "alg": "HS256", "typ": "JWT" }

payload: { "user_id": 1234567890, "aud": "http://myapi", "scopes": ["read.userinfo", "post.friends"] }

Google now changed their Authentication protocol to use OpenID Connect [1], which is a layer on top of OAuth plus a JSON Web Token. The thing about OpenID Connect which makes it useful for Authentication is that you can verify that the token (JWT) has been issued for your application (and not be used by another application) which was something the OAuth was lacking and a common vulnerability [2].

[1] https://developers.google.com/accounts/docs/OAuth2Login [2] http://homakov.blogspot.com.ar/2012/08/oauth2-one-accesstoke...

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.