Dex: Github doesn't return login - Feature Request

[JoelSpeed]

I have set up dex to back onto Github for authenticating a kubernetes cluster. I was expecting that Dex would return the Github Login as the unique identifier sub. This is the property that we are using as personal identifiers with other oAuth applications and this seems like a major miss for Dex to be not returning this field.

Given we are returned this information from Github (as seen in the snippet below) would it be possible to add this as an extra scope to the Github connector? I've had a look through the codebase but can't really tell how much work this would be.

https://github.com/coreos/dex/blob/2c468ea8a0409ae3e0d9bc38286bb59471b9ce7a/connector/github/github.go#L245-L248

[thomaschaaf]

I have analyzed the behavior or sub and this currently a base64 encoded message which states: 893393github . The number being the github userid.
For debugging purposes you can retrieve which user this is by going to: https://api.github.com/user/893393

There are two ways to add the github username:

1. we could create a new field login https://github.com/coreos/dex/blob/fe1516332c4a41aee1dcab66164660676527a36c/server/oauth2.go#L257 or I am open to another name and that would be exposed.
2. The sub creation would need to be changed:
   Use https://github.com/coreos/dex/blob/fe1516332c4a41aee1dcab66164660676527a36c/connector/github/github.go#L250 user.Login instead of the user.ID, and only base64 encode it if needed:
   https://github.com/coreos/dex/blob/fe1516332c4a41aee1dcab66164660676527a36c/server/oauth2.go#L284
   https://github.com/coreos/dex/blob/3c247db00ae74c40b456c6ba9e3c25283df7b116/server/internal/codec.go#L10

Which method do you guys think is better?

[ericchiang]

This should be returned in the claim somehow. I'd prefer if we had some sort of magic scopes to do this. E.g. I could provide the scope github:login or ldap:dn to return custom claims. Deserves some thought and a proper proposal since this has been suggested before in various forms.

[jwntrs]

Maybe this could be returned in the new federated_claims object?

[sagikazarmark]

It could either go under federated_claims or a separate login_name claim could be added to the list of non-standard names. I think it's common enough to reference users by a string identifier that's not opaque and not an email address.

That being said, login_name should probably be an optional claim as I imagine not all providers can support it.

[sagikazarmark]

Even better: use the preferred_username OIDC claim.

[bonifaido]

My attempt to get this feature into master: https://github.com/dexidp/dex/pull/1566

[ffdybuster]

It would really be great if #1566 could get merged soon. It is exactly what I need (for LDAP) and which I tried to work around most of this morning...