Hot answers tagged

60

Whoever possesses the private key can create valid tokens where your system simply can not distinguish between a legitimate token and a token created by the attacker. I am guessing you are not just using the expiry field but also the subject field sub, which is in short terms the logged in user. With the private key, I can create a token with any subject I ...


6

Having a leaked private key would be equivalent to issuing JWTs using only the header and payload sections, and trusting any such JWT a user sends you. If the private key isn't private, there's no protection offered by the signature section anymore, so you might as well leave it off. Now you'll save bandwidth with smaller JWTs and you'll save CPU time from ...


5

No, JWTs can never be either all lowercase or all uppercase. That's because they're a base64url encoding of a byte sequence that starts with {". All possible byte sequences starting with that, when encoded, will start with ey and then an uppercase letter from I to L. Case is relevant in the base64url encoding; aaaa encodes the octets 0x69 0xa6 0x9a, ...


3

A few thoughts: Cookies aren't a great place to put refresh tokens at all, really. They're not the worst, but it's more common to use Local Storage and only ever transmit them when you're using them. Of course, they are script-accessible that way, but HttpOnly is actually very minimally useful as a protection and you need solid protection against XSS anyhow....


3

Simple: A JWT must be properly signed or encrypted with the private key of the authenticating server. If you don't have that private key then you would have to sign/encrypt with your own private key. You can do that, and thus generate a valid JWT, but the application you send it to will easily be able to tell it was signed with the wrong key, and thus will ...


3

You can't rely on the client code General rule of thumb: once you send code down to the client to run on the user's machine, it's not your code anymore. The only security you can count on is security that's enforced by the server. Stateful vs stateless When designing a JWT mechanism you have to choose whether you want the server to track sessions in some ...


3

Would it not be more prudent to just generate a large ... string Yes, it would. A token is often a straightforward solution, and is easier to get right. Cryptographic solutions often have pitfalls or need to be implemented totally correct to be secure. Random tokens are more secure because they are simpler. JWTs are especially useful when having multiple ...


3

It's true that you can use a random string for the magic link and it'll work just fine. However there are a few benefits for choosing to implement it using JWTs: JWT validation doesn't require a call to the database. This is perhaps the main benefit of using JWTs at all. Depending on the number of users this can mean a significant performance difference. It ...


3

Please note that storing JWT in a cookie or localStorage is not the main concern. It is just as fine to store the JWT in a cookie as in localStorage, AS LONG AS the server does not look for the JWT in a cookie header. If you store JWT in a cookie called token but only accepts it on the server side in a Authorization: Bearer ... type header, you are just as ...


3

JWT is a bearer token by design so the client who has it can use it multiple times. So if you want to keep your session management stateless thats a tradeoff you will have to make. This article about stateful vs stateless session management highlights the differences very well. If you want to keep a higher level security then you need to use a different ...


3

Regardless of the type of application, having only one set of credentials is certainly bad practice. For starters, since it's shared, it's more likely to be treated less carefully; e.g. written down in places where people are likely to see, and thus could more easily fall into the hands of an attacker. Once the password is compromised, it's a bigger deal to ...


3

The benefit of using some sort of public key for verification is that the verification can be done offline. For example, say I ask service XYZ to validate a user and, if authorized, provide a JWT. I can query service XYZ to provide me their long-term signing key once, and validate the JWTs that have been issued. As long as they continue to use the same ...


2

The reason is that base64-encoded strings should be a multiple of 4 characters in length. If the base-64 string is not a multiple of 4 characters in length, then pad it using the '=' characters. The following command runs successfully (as you stated in your question): echo -n 'eyJ0ZXN0MSI6eyJ2YWwyIjotOTEuNiwidmFsMyI6NDAuMTIzNH19' | base64 -d {"test1&...


2

Is this mechanism safe against CSRF attacks? This method of splitting a JWT and storing the signature in the cookie and the rest of the token in Browser Storage does not provide any additional protection against CSRF attacks than if the entire JWT was stored in Local or Session Storage. Yes, it will mitigate CSRF attacks, but you don't need to add the ...


2

As mobile applications do not have cookies - this is a wrong statement. The support of cookies is provided by the OS. You may want to look at CookieManager for Android or HTTPCookieStorage for iOS. Both Android and iOS apps do support cookies including httpOnly. For JWT, the server should not care if the client is a browser or a native mobile app. If the ...


2

Great question! I've seen a wide range in the level of complexity of JWT tokens. Let's break your question down. (Wow this post got long. TL;DR at the bottom) Intent of a JWT I guess to start with, I'm not entirely sure what the underlying intent of a JWT claim is, which might help point me in the right direction. To me, the intent of a JWT is to assert ...


2

I agree with the accepted answer above, except for it being the "worst case scenario". I don't think you need to be quite that scared. At worst, if your private key is leaked, you could just generate and use a new one. Your users with tokens that were valid up until this point will now have invalid tokens... so they'll have to re-authenticate, ...


2

I stumble across this in trying to help someone on another forum and the answers here give information about client certificates that is, at best, misleading if not incorrect. First things first. What is a client certificate? A client certificate is (in typical parlance) an X.509 certificate like the one that let's your browser trust this website. What ...


2

One answer (which was cross-posted to the W3C DID WG Issues page where this question was also cross-posted): There is always some correlation risk when an individual entity uses the same identifier for themselves, for interactions with multiple other entities, or even for multiple interactions with one other entity. Multiple strategies are used to minimize ...


2

Background Lets start from the top here. Your server receives a request: Hi server, Can you do X for me? - Jane Access Control is when the server checks to see that Jane is actually allowed to do X before processing the request. Generally speaking, all apps will have some endpoints that need an access control check -- maybe Jane is not allowed to delete ...


1

You made me watch a 80 minute video... And there's a blockchain. Not one, but more than one. There's 5 categories of DID: Ledger based DID: the original DID Ledger middleware (Layer-2) DID: uses a storage layer over the DID blockchain. It should work like the Layer-2 protocols on Ethereum blockchain. Peer DIDs: it's like a permissioned blockchain. A ...


1

First, as Steffen's comment points out, you don't send credentials (certainly not complete ones, suitable for authentication) in JWTs. I mean, you could, but that both completely misses the point of a JWT and is totally useless. In my years of reviewing many, many web apps and services I have never seen this pattern. I'm really curious where you got the ...


1

Using per-user secrets - stored in either the database or the file system, or indeed anywhere else - completely misses the point of JWTs. Well, one of the points, and using symmetric secrets (rather than public keys) means you don't get the other, either. If you have to look up a value before you can even verify a JWT, you've destroyed the scalability and ...


1

Perhaps the cookies are marked as SameSite, or you are using a browser that has SameSite as default behavior.


1

Amazon has a couple of services that target this kind of use-case. Amazon KMS is a key storage platform that integrates with AWS. You can upload keys to it and have your applications sign stuff via the sign API. This keeps the actual keys off your servers. Another benefit is that it integrates with all of the security monitoring and alerting in the AWS ...


1

I think the advice you got to not send the ID token is good. In general, an ID token should never be forwarded to some other entity besides the client that received it. Besides just breaking this cardinal rule, there's no cryptographic or physical relationship between the two tokens. As a result, a substitution attack vector is opened up. In other words, the ...


1

Here is where your logic breaks down: assuming it has the refresh token Why would the server have the refresh token? It's important to understand the role these play in this process. A JWT has a short expiration because they are stateless and cannot be invalidated. Short expirations are inconvenient for users, so the system has a refresh token which is ...


1

Sensitive Data Exposure You should ensure that no sensitive data is made available on the frontend simply by loading the page. The site should be designed such that sensitive data must be retrieved from the backend, and only after proving valid authentication/authorization to access such data. CSRF CSRF is only really an issue if you are using cookies for ...


1

XSS can access anything a script can. Why? Because XSS injected scripts are indistinguishable from other scripts. If you keep a JWT in memory, XSS can access and exfiltrate it. How can you protect your token? Store it in a cookie with the HTTPOnly flag.


1

Access and Refresh Tokens (which aren't always JWTs) provide an additional layer of security and usually related to access. As for your concerns, the expiry is not a sole defense against an attacker. You still need to enforce encrypted communication and secure storage of the tokens. That is, if you have an attacker who gained access to your system in away ...


Only top voted, non community-wiki answers of a minimum length are eligible