61–70 of 76 posts
For those (like me) wondering just how exactly you use those tokens, I found this quick introduction: http://www.intridea.com/blog/2013/11/7/json-web-token-the-us... 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.
For those (like me) wondering just how exactly you use those tokens, I found this quick introduction: http://www.intridea.com/blog/2013/11/7/json-web-token-the-us... Looks definitely easier than SAML.
>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.
Earlier quoted context omitted.
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.
Generally for web app development, I think MACs tend to suffice for the vast majority of use cases.
A side note for anyone considering the use of timestamps within the payload for expiry: note that if you are going to have multiple machines verifying expiries, they will need to be using NTP to ensure that all machines have the same current timestamp at all times.
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…
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.
I'm surprised this has picked up a fancy name and full libraries for so many languages. Not to mention the use of "JWT" as the acronym, which is already famous for "Java Web Toolkit". It's just an HMAC token for validating the integrity of the data - it proves the data has not been modified, that's it. People have been using this for years, perhaps most popularly used by Facebook to sign API requests and responses. A…
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...
1. They're made up of three .-delimited segments: header.data.sig
2. JWT doesn't prescribe any particular sig algorithm. The header indicates by what method the {data} JSON object was signed to get {sig}. A common sig method is hmac-sha
3. JWT only provides a signature to assure that the {data} was not tampered with. The data is not private at all and easily inspected (which is nice for debugging). JWE can provide encryption http://tools.ietf.org/html/draft-ietf-jose-json-web-encrypti...
And for some: "Why is this useful?". It's useful if my API needs to receive requests to do serious business like delete things or post as your account. How do I know if the request is from a trusted source? Well if the trusted source has a secret key they can use to generate the {sig} according to the {data}, then I can verify that the requester had access to the secret key and therefore trusted.