How should the JWT returned by Hanko be used?

[knpwrs]

There is a somewhat (in)famous blog post which addresses this topic: http://cryto.net/~joepie91/blog/2016/06/13/stop-using-jwt-for-sessions/

Some people seem to take it a little farther: https://gist.github.com/samsch/0d1f3d3b4745d778f78b230cf6061452

What is the recommendation from Hanko? Should the JWT returned by Hanko be treated essentially as a session, or should it be treated as a short-lived token in order to set up a session with a session id?

[knpwrs]

I think a JWT security guide would be good to publish along with Hanko. The key things to look out for are to not allow the none algorithm in your services authorized by JWT, and to restrict the list of algorithms you allow during validation so that other users cannot forge JWTs using weak algorithms, or, for instance, using your public key to sign a JWT with the HS256 algorithm.

More details here: https://paragonie.com/blog/2017/03/jwt-json-web-tokens-is-bad-standard-that-everyone-should-avoid

[FlxMgdnz]

Hey, thanks a lot for your thoughts and the links. We've been thinking about this for a while now. Our current plans are that we'll rework sessions and introduce standard session management and session tokens at some point in the near future. We'll probably leave the current JWT mechanism in place alongside the new system and provide guidance how all this goes together and when to use what and how.

[mmu095]

They are usually expired tokens with a short validity period. Refresh token: The refresh token is used to generate a new access token. Typically, if the access token has an expiration date, once it expires, the user would have to authenticate again to obtain an access token.
https://www.izertis.com › refresh-to...
Refresh token with JWT authentication in Node.js - Izertis

https://github.com/teamhanko/hanko/blob/6761f4b6e700ebfc19b28f35cb330dc6314b03d5/CONTRIBUTING.
https://github.com/teamhanko/hanko/blob/6761f4b6e700ebfc19b28f35cb330dc6314b03d5/SECURITY.md
https://github.com/teamhanko/hanko/blob/6761f4b6e700ebfc19b28f35cb330dc6314b03d5/CODE_OF_CONDUCT.md

[ghstahl]

Just started on my hanko journey.
This is what I need from hanko.

Authentication of a user.

Tell me who they are
Tell me exactly how you got that information.

The perfect thing for me is the id_token.

Who is the user.

1. subject
2. If I could associate metadata with a user and it gets automatically put into the id_token, even better.
3. The user JUST got authenticated against the root_idp (hanko username/password, passkey) OR an external_thirdparty_idp.

The current code I have seen doesn't have the user linking to N number of third party idps. Need that.

Just because a user has a link to a thirdparty IDP doesn't mean that the user actually exists anymore in the third_party IDP.

What I do with that id_token.

I have my own OAuth2 service that has a token-exchange grant_type. I exchange the id_token for access_tokens. To do this I need to know the following.
user_id. (the who you are)
the_idp_that_just_authenticated_you: (the current how)

That proves to me that this user exists in context of the third_party idp.

I don't know if hanko is currently issuing id_tokens.