JWTs are simply an authentication mechanism, and can be used as part of your method of authentication in various ways. My company uses JWTs for one of our web services (REST API), with a keystore holding the public certificates of trusted clients which can then request a temporary access token. Since we're using RS256 instead of HMAC256, we have the capability to not only private communication between the client and server but also guarantee that this person is who they say they are, since the key to decrypt their JWS has to be in our public keystore already. To conclude:
For us, the JWT isn't created when the user logs on, but in order to log on. We use JWTs as an assertion of user authentication, generating a temporary access token where we set expiration time and the system they get access to, and return that JWT as the response.
A REST API won't use cookies, the client that made the request will have to handle maintaining it themselves, but that's one way of doing it. It just needs to be stored on the client side. But make sure to keep it safe, it's effectively a plaintext password if it doesn't contain any context-specific data within the body (which in turn is verified by the JWS).
How we manage this has been described, but to spell it out: Yes. A JWT token has an expiration property for a reason. If it is being used as an access token, an indefinite JWT can be as dangerous as a password. As an example, we have a protocol for client and server. Clients assertion token should have a lifetime of up to 5 minutes, and the server will return an access token with a lifetime of an hour. Any subsequent requests to the access service and you will have to request a new one by creating a new JWT to be used as the assertion token.
Let me know if you have any other questions about this! I tried (hah) to keep it short but it got fairly lengthy anyway.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
JWTs are simply an authentication mechanism, and can be used as part of your method of authentication in various ways. My company uses JWTs for one of our web services (REST API), with a keystore holding the public certificates of trusted clients which can then request a temporary access token. Since we're using RS256 instead of HMAC256, we have the capability to not only private communication between the client and server but also guarantee that this person is who they say they are, since the key to decrypt their JWS has to be in our public keystore already. To conclude:
For us, the JWT isn't created when the user logs on, but in order to log on. We use JWTs as an assertion of user authentication, generating a temporary access token where we set expiration time and the system they get access to, and return that JWT as the response.
A REST API won't use cookies, the client that made the request will have to handle maintaining it themselves, but that's one way of doing it. It just needs to be stored on the client side. But make sure to keep it safe, it's effectively a plaintext password if it doesn't contain any context-specific data within the body (which in turn is verified by the JWS).
How we manage this has been described, but to spell it out: Yes. A JWT token has an expiration property for a reason. If it is being used as an access token, an indefinite JWT can be as dangerous as a password. As an example, we have a protocol for client and server. Clients assertion token should have a lifetime of up to 5 minutes, and the server will return an access token with a lifetime of an hour. Any subsequent requests to the access service and you will have to request a new one by creating a new JWT to be used as the assertion token.
Let me know if you have any other questions about this! I tried (hah) to keep it short but it got fairly lengthy anyway.