Hot answers tagged

33

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


16

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


15

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


13

Yes, it is bad practice and a security problem. Email addresses are PII (personally identifiable information). Like all other PII, email addresses should never be stored unencrypted at rest; doing so is inherently insecure. If your JWTs are going to be stored at rest anywhere - such as a database, or local or session storage in the browser - then you ...


13

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


11

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


10

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


8

JWT "no-brainer" choice is for any UI app which will need to authenticate user as well any API calls which require authorization on the API not just authentication. Both API key and JWT can provide authentication and authorization. API key is on project scope and JWT is on user scope. API keys are considered to be vulnerable to man-in-the-middle ...


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


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


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


5

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


5

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


5

Two options: Use a different signing key for each separate user DB. That way tokens cannot be valid in more than one system. Store only a random surrogate key in the token. This key is then mapped to an account server side. This is common when the DB is not distributed. For a distributed DB you'll need replication.


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


4

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


4

The identifier in the URL can be always faked by an attacker. You need a mechanism to ensure that the identifier is actually valid. This is why when modelling endpoints executing a certain operation, the url value is not considered a granting authority and instead a different mechanism is implemented (sessions, JWT tokens,...). And then if you decide you don'...


4

JWT's can be used for anything you want the server side to communicate back to itself or other services in the ecosystem in a trusted manner through an untrustworthy client. The user principal, display name, and resource authorizations would all be sensible. That spares the server from going to a DB to look these things up prior to doing work. Use your ...


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

It's commonplace to store a user's e-mail address in a token. The properties of said e-mail address are up to the identity provider (is it unique, can it be changed etc.) A few scenarios which are potentially insecure are a user changing their e-mail address and another user then taking up that e-mail address. Or a user deleting their account and re-...


3

I have to admit, I've just created a REST API using the approach like the one described above: We provide a username and secret for each client, which is allowed to access our REST service. The client has to generate a new JWT for each REST call and has to add the token to the request header. Why did I choose this approach and what are the advantages and ...


3

When communicating with a web server, you may be interested in: Guaranteeing that you're actually communicating with the server, not somebody who pretends to be that server. Encrypting your communications. It's not of the business of your ISP what you store to Amazon S3 or what text messages you send through Twilio. Ensuring your request or the response ...


3

It sounds like you have a lot of permissions, and maybe those permissions have very long names. One way of reducing the overall token size would be to severely abbreviate them, and add a static class of constants to make them humanly readable. eg. public static class Permissions { public const string HasAccessToThisMethod = "HATTM"; } and [...


3

Let's ignore JWT tokens for the moment and think of a classical session based authentication mechanism using cookies: a user accesses a login page; they use their username and password to login; server checks the database and finds the username+password match; the user data is stored in the session and the user receives a SESSION_ID cookie; any further ...


3

The most fundamental rule of web application security is you can not trust the client. The expiry date is the single most important security feature of a JWT, because it's the only way you can tell the difference between an old stolen token and a newly created one. A JWT with no expiry is like a skeleton key: if anyone gets hold of it, they can carry on ...


3

how do we keep the user authenticated on the mobile app even after the refresh token expires? All the famous apps out there do not prompt the user to authenticate let's say weekly or worst daily [...] This use case is the sole purpose of refresh tokens. So set the expiry to match how long you want the user to be able to stay signed in without being prompted ...


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 think I finally got it. The thing is that custom claim names (either public or private) should not match reserved claims names because it would break the interoperability between systems exchanging JWT for authorization. For example, we can not use a custom claim name exp (expire) and set something different than a timestamp because whoever validates the ...


2

That's actually one of the caveats of completely stateless JWTs. You cannot invalidate specific token. You may invalidate them all by changing your secret on the server, however this operation will revoke all JWTs, not just a single one. If you'd like to introduce blacklisting, you unfortunately have no other choice than to introduce some id into your token'...


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.


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