Username in ID token

[cornerman]

When using authn, I realized that the id token (e.g. in authn-js accessed via authn.sessionToken()) does not contain the username. Is it possible to get this info into the id token issued by authn-server, so the frontend has direct knowledge about it?

[AlexCuse]

There's email and preferred_username claims defined here https://www.iana.org/assignments/jwt/jwt.xhtml

Either could make sense depending how authn is configured.

[cornerman]

That sounds right - depending whether usernames are configured as emails. Do I understand correctly, that this is not yet possible with configuration? Can I help with adding support for this?

[AlexCuse]

I don't see any reason it would hurt, I think a PR would make sense. I'm not sure if we would want to make inclusion configurable or not - the relative anonymity is something I always liked about JWTs but not sure if its a must-have. @cainlevy any thoughts here?

[cainlevy]

My only concern is token length, and I don't know off the top of my head if that could be a concern for anyone.

Another way to get this information in a client might be a session endpoint that returns a few details about the current token's account.

[cornerman]

Thank you for your answers. I would definitely prefer username/email in the ID token, because of latency when calling a dedicated endpoint. That would be for the frontend and the backend.

Do we know what kind of length concerns there are for the token?

[cornerman]

About anonymity: a lot of setups use a separate id and access token. So, the access token without identifiable information can be sent to the server.

For the token length: making it configurable would probably make all sides happy then :)

[AlexCuse]

Yeah the dedicated endpoint makes sense to me - #253 is adding an endpoint to retrieve oauth account details and it sort of fits in with that, it could be changed to eg /account/info to include the username as well. You could call this once after login and store it in session / cookie if latency is a concern.

That said I can see how it would be convenient to include in token. Probably relatively safe as long as its configurable / opt-in. Would need to update at least the go client to include the new claim as well I think.