Requesting non-identity scopes before identity scopes results in user_name always being set to subject id

[theferrit32]

Given two token requests with the following scope sets:

1. [openid, profile, email]
2. [data:read]

If (1) is requested first, the system will store a valid, meaningful user_name assuming the IDP returns a value like preferred_username or email in the token response. Then (2) will be matched up with the identity from (1) and client applications will be able to see the user_name when they request the [data:read] token through this service.

However if (2) is requested first, the token response will likely not contain either preferred_username or email and the behavior now is for the User object to be stored in the db with the user_name set to the sub value. Client applications requesting the token for the data:read scope on this user will see the user_name being the sub value. Even if (1) is then performed later and a valid preferred_username or email is acquired in the response, this is not stored and the user_name field for the user object is not updated to this new value.

In most cases, identity authentication is performed first, which will always request one or more of [openid, profile, email] (or equivalent for the IDP), then additional scope authorizations are performed later so this is likely a rare case.

If client applications depend on a stable user_name value (which is recommended against in the OIDC spec), then updating the value when a meaningful one is received may cause issues.