Regarding the usage of the 'sub' field in jwt tokens
Hi, thanks for the awesome repo. I'm building a site based on it, and found something that confused me.
This project uses the jwt field 'sub' as a kind of way of explaining the intention of the jwt (first example, second example), instead of just using it to describe the subject, or user in our case, of the token. I thought that this was the way the 'sub' field should work, at least from what I've read.
Is there a reason for this? Am I understanding the usage of 'sub' wrong?
I am planning of using the 'sub' field in my site to send the username back to the web client, and this way have an easy way to access it to show on the site. Is this wrong or unsafe?
Thanks!
I'm trying to do something similar @joaqo and was wondering the same thing. The sub field in the access_token seems to be commonly used to "identify the principal that is the
subject of the JWT": reference
I think using sub to identify the user has just become a standard practice. It should be safe. Because sub is really just a custom key you can include in the payload of the JWT, it shouldn't matter.
Also found some documentation in the fastapi docs. This describes using the sub to indicate subjects other than a user: an item, a car or a blog post. So, you could prefix sub to include the subject type: username:john or post:12345 and then validate accordingly. I think I will go this route in my application, as I'm emailing JWTs embedded in a URL link to allow anonymous users access to specific items with a subset of perms
I think the use of sub as the "intention of the JWT" should instead be used under the iss key. As many best practices recommend, it is good to validate many different keys in a JWT - adding an iss wouldn't hurt, and similarly serves the purpose of describing the intention of the token.
Some more good info here: https://blog.angular-university.io/angular-jwt/
But using JWT for Authentication is such a common use case that there are a couple of specific properties of a payload defined for supporting: user identification, and session expiration
iss means the issuing entity, in this case, our authentication server iat is the timestamp of creation of the JWT (in seconds since Epoch) sub contains the technical identifier of the user exp contains the token expiration timestamp
Hey, thanks for the detailed response @paul121 ! I think I'll just go ahead and use sub for username. Cheers.
Traceback (most recent call last):
File "main.py", line 5, in
python3.8
How to install?
@SurelyYouareJoking https://github.com/mpdavis/python-jose pip install python-jose[cryptography]
I can't see these examples (first example, second example) but I imagine this has been updated to reflect sub appropriately i.e. email, is that correct? @joaqo can we close this?
Yes, looks like it was wrong back then, but now sub of the access token contains email of the user