Live data from Hacker News

JSON Web Tokens

jwt.io

51–60 of 76 posts

Re: JSON Web Tokens

#51

Is the advantage of using this instead of basic auth and HTTPS that you don't have to use basic auth and HTTPS? (Or if not basic auth, an authenticated session cookie over HTTPS.) I've seen many people write their own system to avoid implementing HTTPS. Which, as much as installing certs is expensive and complicated (especially keeping track of expiration) should probably be done for all web sites for other privacy a…

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.

Re: JSON Web Tokens

#52
How secure are JSON Web Tokens? I understand the basics of JWT, but I'm not an encryption expert.

- What is the most secure algorithm to use when creating the signature?

- Should you do anything else on the server side besides verifying the signature? IE: tracking tokens, rotating keys, etc.

Without knowing much about encryption it seems risky to simply trust a JWT based on signature alone. How hard would it be to actually spoof a JWT with the most secure encryption algorithm?

Re: JSON Web Tokens

#53

Is the advantage of using this instead of basic auth and HTTPS that you don't have to use basic auth and HTTPS? (Or if not basic auth, an authenticated session cookie over HTTPS.) I've seen many people write their own system to avoid implementing HTTPS. Which, as much as installing certs is expensive and complicated (especially keeping track of expiration) should probably be done for all web sites for other privacy a…

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 v…

A minor-ish clarification on terms: a MAC algorithm (e.g., hmac-sha1) should not be conflated with a digital signing algorithm (e.g., rsa-sha1), as the MAC requires knowing the secret in order to validate. MACs are fine for checking that data haven't been tampered with, but do not have the properties of an actual signature that you can verify without being able to reproduce.

Re: JSON Web Tokens

#54

How secure are JSON Web Tokens? I understand the basics of JWT, but I'm not an encryption expert. - What is the most secure algorithm to use when creating the signature? - Should you do anything else on the server side besides verifying the signature? IE: tracking tokens, rotating keys, etc. Without knowing much about encryption it seems risky to simply trust a JWT based on signature alone. How hard would it be to ac…

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.

Re: JSON Web Tokens

#55

Is the advantage of using this instead of basic auth and HTTPS that you don't have to use basic auth and HTTPS? (Or if not basic auth, an authenticated session cookie over HTTPS.) I've seen many people write their own system to avoid implementing HTTPS. Which, as much as installing certs is expensive and complicated (especially keeping track of expiration) should probably be done for all web sites for other privacy a…

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.

Re: JSON Web Tokens

#56

Is the advantage of using this instead of basic auth and HTTPS that you don't have to use basic auth and HTTPS? (Or if not basic auth, an authenticated session cookie over HTTPS.) I've seen many people write their own system to avoid implementing HTTPS. Which, as much as installing certs is expensive and complicated (especially keeping track of expiration) should probably be done for all web sites for other privacy a…

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.

Re: JSON Web Tokens

#57
post #56

Is the advantage of using this instead of basic auth and HTTPS that you don't have to use basic auth and HTTPS? (Or if not basic auth, an authenticated session cookie over HTTPS.) I've seen many people write their own system to avoid implementing HTTPS. Which, as much as installing certs is expensive and complicated (especially keeping track of expiration) should probably be done for all web sites for other privacy a…

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 s…

Which is sad, otherwise things like SRP could have become built in as well.

I guess you could could kludge it into a form with a method="SRP" and have the browser do it's thing with the username and password field.

Re: JSON Web Tokens

#59
post #15

I 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…

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.

Re: JSON Web Tokens

#60

Is the advantage of using this instead of basic auth and HTTPS that you don't have to use basic auth and HTTPS? (Or if not basic auth, an authenticated session cookie over HTTPS.) I've seen many people write their own system to avoid implementing HTTPS. Which, as much as installing certs is expensive and complicated (especially keeping track of expiration) should probably be done for all web sites for other privacy a…

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

Post reply on HN