[keycloak-dev] User ids and usernames

[Stian Thorgersen]

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: "Stian Thorgersen" <stian at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Thursday, 6 February, 2014 3:41:34 PM
> Subject: Re: [keycloak-dev] User ids and usernames
> 
> Maybe just return additional information in the json response from
> obtaining an access token.  The access token would just contain a link
> to user profile information.  This reduces token size and yet allows
> pure REST Bearer Token services to get profile information if they
> desire it.

I agree some mechanism to retrieve the token + profile in the same request would be nice, but IMO that's an performance optimization that can be done later. Google for example only return the ID, and you need to go an retrieve the profile if you want. I believe this is the way OpenID Connect does it as well, as I'm using Google's OpenID connect endpoints to retrieve the profile.

There's also the case where you don't want to give an app access to your full profile. Currently the token would have to have account/view-profile role to be able to retrieve the profile.

> 
> On 2/6/2014 10:35 AM, Stian Thorgersen wrote:
> > Why would an application need the username? I would think the application
> > would more likely want the id, email and first/last name. For example:
> >
> > * To store an entry in a db associated to the user the id should be used
> > * To display the logged in user the first/last name would be used
> >
> > Thinking about this further, I really think the "reference" used on a user
> > should be a unique id generated by the system and not a user specified
> > string. An example scenario for a online image gallery where using a user
> > specified username would cause problems:
> >
> > 1. User registers with 'bob'
> > 2. User logs in to the image gallery
> > 3. User uploads some private images
> > 4. The user is later deleted by an admin because the user didn't pay his
> > fees
> > 5. Another user now registers as 'bob'
> > 6. If the private images from the initial user are still there, the new
> > user will now be able to access images not belonging to him
> >
> > This makes me think that Keycloak should generate user ids, and we should
> > make sure that even if a user is deleted, the id wouldn't be reused.
> >
> > ----- Original Message -----
> >> From: "Bill Burke" <bburke at redhat.com>
> >> To: "Stian Thorgersen" <stian at redhat.com>
> >> Cc: keycloak-dev at lists.jboss.org
> >> Sent: Thursday, 6 February, 2014 2:59:31 PM
> >> Subject: Re: [keycloak-dev] User ids and usernames
> >>
> >>
> >>
> >> On 2/6/2014 9:48 AM, Stian Thorgersen wrote:
> >>>
> >>>
> >>> ----- Original Message -----
> >>>> From: "Bill Burke" <bburke at redhat.com>
> >>>> To: keycloak-dev at lists.jboss.org
> >>>> Sent: Thursday, 6 February, 2014 2:15:41 PM
> >>>> Subject: Re: [keycloak-dev] User ids and usernames
> >>>>
> >>>>
> >>>>
> >>>> On 2/6/2014 5:02 AM, Stian Thorgersen wrote:
> >>>>> A user should have an id, username and email (what we have now). The id
> >>>>> should be generated by the server and should never change for a user.
> >>>>> The
> >>>>> sub field in the token should use this id, not the username.
> >>>>> Applications
> >>>>> that wants to store information associated with a specific user should
> >>>>> also use this id, not the username or email, as the id will never
> >>>>> change.
> >>>>>
> >>>>> That means it should be possible for a user to change his/her username.
> >>>>> Obviously a username has to be unique within a realm. We should then
> >>>>> allow
> >>>>> a user to login with either their username or their password. When a
> >>>>> user
> >>>>> is able to login with their username we can also remove the forgot
> >>>>> username option on the login form, and only have a forgot password
> >>>>> option.
> >>>>>
> >>>>> This would also help integration with social login as now we don't have
> >>>>> to
> >>>>> try to create a sensible username for a user on social login. Instead
> >>>>> we
> >>>>> create a generated id, and don't even set a username. A user can then
> >>>>> set
> >>>>> the username they want through the account management (or on the update
> >>>>> profile action page if that option is enabled).
> >>>>>
> >>>>> If there's no objections to this, I'd like to add these changes to
> >>>>> alpha2.
> >>>>
> >>>> Ugh, this is just a nasty change.  usernames will rarely, if ever,
> >>>> change and I don't like the idea that users can change their username.
> >>>> A principal name of "bill" is much more coherent than
> >>>> "2341235234234-234123-234123-2341234".
> >>>
> >>> Doesn't matter does it? It's just an identifier, if someone wants to know
> >>> more about the user they should retrieve the user profile.
> >>
> >> User profile would then have to be retrieved for most apps as most apps
> >> would want to display the username.  Maybe add an additional token
> >> extension for the username?  So an additional REST invocation back to
> >> obtain the user profile doesn't need to be done?
> >>
> >> --
> >> Bill Burke
> >> JBoss, a division of Red Hat
> >> http://bill.burkecentral.com
> >>
> 
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
>