Hot answers tagged

29

You choose not to encrypt the payload for the same reasons that you choose not to encrypt anything else: the cost (however small it is) exceeds the benefit, and a lot of data simply doesn't need to be secured that way. What you mostly need protection against is people tampering with the data so that the wrong record gets updated, or someone's checking ...


12

Cookies: in their early version, a text file with a unique client Id an all the other information needed about the client (e. g. roles) Cookies are tuples key-value originally addressed to retain data related to the client activity. This retention is what we know as session or application state. Fundamentally, they were made for holding the state of web ...


9

The short answer is no. There should not be any problem because email is a valid and registered public claim. I have a user DB where each user's unique ID is their email ... Well, there's a protected claim for users' ID. The claim sub. 4.1.2. "sub" (Subject) Claim The "sub" (subject) claim identifies the principal that is the subject of the JWT....


9

These are intended for scenarios where you have a token issuing authority that is not the same as the application that is the intended recipient. This may not be different for your application. But consider a large scaled application. You might have an OAuth or SSO server that's issuing the certificates, and an application that wants a token that shows the ...


9

The positives/pro I can see of storing the JWT token in our database would be that even after assigning the token we will have the power to invalidate or deactivate the existing the tokens even before the expiry This only happens if you're validating the token against the database, in which case why use JWT? The whole point of having a self-contained, ...


7

Use both. In your mobile app, you have better control over the code that runs and can avoid XSS vulnerabilities. So storing the token is not so problematic and you can have your code pass it to the API In your webpage you do have to worry more about injected code, so use the secure cookie to store the token and have the browser pass it automatically After ...


7

The purpose of including claims in the token is so you don't have to have that communication between the resource and the authentication provider. The resource can just check that the token has a valid signature and trust the content. Assuming the private key is private to the auth server you are good. Some providers change their key around to mitigate the ...


7

Cookies: in their early version, a text file with a unique client Id an all the other information needed about the client (e. g. roles) Your definition of cookie doesn't really describe what they do. A cookie is a key-value pair that is set via HTTP response header (Set-Cookie) by the server and stored by clients that support them. Cookies are sent back ...


6

In general, as many operations as possible should be tied to a real, human user. It forces people to authenticate properly, it pushes for a single consistent authorization strategy, and it's an important part of providing a cohesive audit trail. And in general, you have three sort of scenarios with microservices: 1. The user comes in, uploads a photo, and ...


4

The use of the term signature in the RFC is analogous to a digital signature in asymmetric cryptography. In asymmetric cryptography if the sender encrypts a message with their private key, anyone who has the message can decrypt it with the sender's public key. So the goal with the term signature isn't to keep a message secret, but to verify the integrity/...


4

If the purpose of this end point is to perform an operation on the "current user" as defined by the user in the JWT token, then you absolutely don't want the User Id in the URL. You don't want someone to maliciously change the URL to perform an action on a user other than their own, and implicitly using the JWT token for the user to operate on is a great ...


4

I think you are muddling the concept of the id of the user that is authenticated and the id of the user that you want to delete. I could be wrong but it's a little unclear when a user would delete him/herself and what that would mean. I would think the user being deleted and the user that is authenticated would typically be different. For the second part ...


3

I don't understand why you think having the JWT token expire will be a problem. You should only be validating the expiry when the message hits your system (request submitted). If you have a Queue in front of your service, you should check / validate tokens before the message containing them get into the Queue. If you have a service operation which takes a ...


3

Suppose the following scenario A user logs in into your application from 3 different devices. Each device gets a separate JWT to remember the login, with a different expiration date & time. That user changes their username and/or email address from device 1. The question is, is it acceptable that the action in step 3 automatically logs the user out on ...


2

To add to Robert Harveys answer, there is a significant disadvantage to encrypting the payload - it means that the recipient of the service needs share a secret with the authentication server (the encryption key) to understand whether or not the bearer of the token is authorised or not. In contrast anyone can validate a JWT using only the public key ...


2

I would not share a secret. I would use asymmetric encryption like RSA and have each service generate a key-pair, then share their public keys with each other. That way they can both validate and sign JWTs created by the other as needed.


2

For me the main reason to store the token in local storage instead of redux store is that they are fundamentally different in nature in that: You usually want too keep the auth token between page refreshes You may want or not to do that with the application state Aside from that, setting the state in the action creator seems to me just wrong, since the ...


2

I will do a guess from different sources. I heard "security is not a crosscutting concern" I would put authentication in it. It can not be separated from the program although not included in the model and then pressed in when needed. Whether you are authenticated is not part of your model in a way that you have two objects, one authenticated and one not ...


2

The point of JWTs is that they can be verified in a decentralized manner, simply by checking the signature. A JWT is therefore irrevocable. This limitation is by design. If you create some authentication service that contains a list of revoked tokens, any consumers of the JWT must first check that auth service. This removes any advantages of the ...


2

You are missing the point of JWT. Logging in is the process of confirming someone's identity (i.e. authentication). Once you've confirmed the identity, you generate the JWT with all the user's needed information (like roles, etc.). That JWT is then signed so that you know it is valid. The browser needs to present the JWT as a bearer token, and the web ...


2

It sounds like JWTs are overly complex solution to a problem that doesn't exist, in this case. From what you described, this is just a presentation issue (that happens to be about security) as opposed to an actual security issue. All the code executed on client-side is untrusted, and you have to assume a client can access any bit of it at any time (eg: it's ...


2

Imho you should opt for the more secure approach 1 - option A (see why) and reduce the permission count by creating groups and leverage the possibility of flags. The client could have: const accessMode = Object.freeze({ none: 0, execute: 1, write: 2, read: 4 }); And combine permissions: file.accessMode = accessMode.read | accessMode.write; The ...


2

Spring allows you to specify certain parameters to your method with annotations so you don't have to do anything directly with the HttpServletRequest itself. The most common place to put your JWT token is as a bearer token in the Authorization header. The HTTP request would look something like this: GET http://example.org/myservice/123 HTTP/1.1 ...


2

You have indicated that "the token is needed by the service" and you are concerned with passing the token all the way from the web layer into the service layer. In comments on Berin's answer, though, you explain that the purpose of this is role based authorization. There is a simpler implementation possible, in which you create a filter that reads the JWT ...


1

The big things to address are: non-repudiation: the user should be unable to deny that the actions are theirs. That means that the identity cannot be easily stolen by someone, and that the token provided can be validated that it is correct. auditable: you need to be able to determine if any users are behaving badly, and terminate access if so. controllable:...


1

I have found that usually the overriding concern with this kind of thing is "what does the third party support?" If they are able to do stuff like oauth or client ssl certs, then great you can put in whatever the standard security library that your platform supports. As with all security problems the answer is always to use a standard off the shelf package ...


1

I think it's common to store Refresh tokens in persistent storage. It's the Access token you don't want to store. Access token is verified on each call to your API (or whatever else) so you don't want to have that checked in the Db every time. That's where JWT shines because it can verify the integrity of the token without the need to store it on the server. ...


1

So you have implemented OAuth2 but you have a 'security' specifications from the 90s which say "the user's session must expire after 15 min" or "When the user clicks log out their session is no longer valid" One way to get around this is to implement token revocation. There are a number of ways of achieving this but storing the tokens on a db and ...


1

From my experience, if all your systems are using some central role and permission database, you can add all that into JWT. However, this approach might not work well in SSO scenarios when the auth server itself has no idea whatsoever about the target system that will receive and trust the token. The roles and permissions of the user are entirely upon the ...


1

This probably belongs on stackoverflow but here's a fairly minimal implementation of retrieving the client-cert using JAX-RS filters: import java.io.IOException; import java.security.Principal; import java.security.cert.X509Certificate; import javax.annotation.Priority; import javax.ws.rs.Priorities; import javax.ws.rs.container.ContainerRequestContext; ...


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