search

keratin / authn-server

Authentication service that keeps you in control without forcing you to be an expert in web security.
https://keratin.github.io
GNU Lesser General Public License v3.0
1.27k stars 109 forks source link

Username in ID token #257

Open cornerman opened 5 months ago

cornerman commented 5 months ago

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 commented 5 months ago

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 commented 5 months ago

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 commented 4 months ago

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 commented 4 months ago

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 commented 4 months ago

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 commented 4 months ago

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 commented 4 months ago

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.