|
|
|
|
|
|
by hardwaresofton
3034 days ago
|
|
|
This was what I was about to post -- JWT-in-cookie is just about perfect from a security/convenience ratio standpoint is it not? Assuming the HTTP cookie is secured properly (like all cookies normally are), it's the perfect way to serve both browser and non-browser traffic (apps may choose to do a little more work to pull the cookie out of the authentication request and use just the auth header if they want). Any thoughts? I can't think of anything glaringly wrong with the scheme. Also, I generally think that if someone has the resources to obtain your JWT it probably doesn't matter if it's encrypted (assuming it's stuff like the user's ID or roles, and not something you shouldn't be putting in there anyway), because the attacker has the time until you revoke the token to do whatever they want as the user. I'd love to hear why I'm wrong |
|
|
In OP's case, I think they're unlikely to see any benefits to using JWT.
Dealing with authN/authZ can grow fairly complicated depending on the business' requirements. On the surface what you're suggesting seems like it would work perfectly fine for many use-cases, so you're not wrong.
JWT is often immaterial to authentication. One must consider how the service is consumed and through which mediums. Depending on the data's importance, you'll need to carefully consider the security model.
Acquiring someone's cookie or token doesn't always mean full access, nor does it mean you get to repeatedly request new tokens. You could require an additional password check before allowing the user to take certain actions. Two examples of this are GitHub and Google.