Is it secure to return a JWT to an already-logged-in user?

Question

I'm using JWT to handle an SSO scheme where two systems (let's call them A and B) both require authentication, but the user datastore is in one system only (let's say A). Everything I've seen about JWT involves the user posting username/password in order to receive the JWT, but what I'm wondering is if it's secure to return a JWT to an already-logged-in user.

To make it a bit more concrete, the authenticating system A (example.com) uses cookie/session based auth, but the second system B (subdomain.example.com) needs the JWT to authenticate. We don't want to force already-logged-in users who have a session cookie to input username/password again in order to get a JWT, so we're thinking we'll implement an API endpoint that returns a JWT to a user who is already logged in (via session auth), which the user can then user to authenticate with system B. In particular, we're using Django REST Framework JWT, which gives the option to manually create the JWT: https://getblimp.github.io/django-rest-framework-jwt/#creating-a-new-token-manually

So e.g. we'd have an API endpoint where you can GET https://systemA.com/api/gimme-jwt/

if user is already authed: return JWT else: return 401

Again, the key difference between this and everything I've seen is that we're returning a JWT to a user who has already logged in.

Answer 1

Providing a JWT token to the authenticated user is not a problem, but you shoud take into account the following considerations:

1. Are your environment secure (is it internal or public network)? Do your use secure transport (TLS) for communications? If not,you shoud care about token integrity and privacy using JWS and\or JWE
2. Do you transfer any PII (Personally identifiable information) data? If so, you should always use encryption for the tokens.

Anyway, before using JWT tokens look into OpenID Connect specification http://openid.net/specs/openid-connect-core-1_0.html that actually describes how to use JWT tokens for SSO, some common vulnerabilities and privacy issues.

Answer 2

Really the question should be

How can I be certain a signed in user is the same person who signed in so I can send them a JWT?

And the answer to that is you can't. This is because of the security best practices:

Assume all input from users is fake or an attack until proven otherwise.

This means you need to require them to re-authenticate to receive the JWT, otherwise you can't be sure they didn't leave it open and walk away.

---

Another consideration is that you should use encrypted channels, and encrypt the JWT. If this is over HTTPS then you can set it as a cookie value to make life a little easier and more secure.

JWTs carry a bit of overhead with them though because at every venture you need to decrypt them, verify them, and then modify them if need be, then re-encrypt them, but there is no way around that otherwise you'd be transferring unencrypted state information which is always a no-no.
You should look into the common practices with JWT and the known threat vectors that exist because of it.

Answer 3

Provided that you are sure that you are giving the JWT to the actual user who logged in, delivering it after authentication isn't a problem.