[keycloak-dev] Improve first login with identity provider

Tue Jul 14 10:30:54 EDT 2015

On 14.7.2015 15:15, Stian Thorgersen wrote:
>
> ----- Original Message -----
>> From: "Marek Posolda" <mposolda at redhat.com>
>> To: "Vlastimil Elias" <velias at redhat.com>, keycloak-dev at lists.jboss.org
>> Sent: Tuesday, 14 July, 2015 3:05:06 PM
>> Subject: Re: [keycloak-dev] Improve first login with identity provider
>>
>> +1 for do it like this. It seems the biggest challenge is merging the
>> accounts. Not sure if it's better creating temporary user accounts or
>> rather keep all the state in ClientSession. It seems the both approaches
>> has pros and cons...
>>
>> Do we want to support linking multiple accounts during single
>> authentication? It looks we should support it too to have all the things
>> covered properly. I mean the usecase like:
>>
>> 1) User is registered with username/password and email "john at gmail.com"
>> 2) User clicks to "Sign in with Facebook" and authenticates. Keycloak
>> displays "There is already account with john at gmail.com. Do you want to
>> merge account?"
>> 3) Now login screen is displayed again (IMO it should be without
>> Facebook button this time) and user click to "Sign in with Google"
>> 4) Keycloak again displays "There is already account with
>> john at gmail.com. Do you want to merge account?"
>> 5) Now login screen is displayed again (without both Facebook and Google
>> buttons) and user finally login with username/password . After
>> authentication is user john at gmail.com linked with both Facebok and Google
> Yes, but I had a different approach in mind:
>
> 1) User is registered with username/password and email "john at gmail.com"
> 2) User clicks to "Sign in with Facebook" and authenticates. Keycloak creates the account, but sets the email address 'john at gmail.com' as an tmp attribute. Then it displays existing account blah blah, do you want to merge?
> 3) User clicks merge and is shown a login screen without username, but only password (and any linked identity providers)
> 4) Once user is logged in the account created in step 2 is merged with the account created in step 1. After it's merged the account from step 2 is deleted.
>
> This lets the user merge the account from Facebook at any point as long as it's within the expiration time. Newly created (but not active accounts, i.e. outstanding required actions) will have a expiration time and be removed by a background thread.
Yeah, I agree with creating separate temporary accounts. Was just 
wondering about use-case with chaining multiple identity providers 
during single authentication (both Facebook and Google). In this case, 
there will be 2 temporary accounts, so the question is if:
- The "facebook" temporary account is merged with "google" temporary 
account after successful Google authentication (my step 4)
- Both "facebook" and "google" temporary accounts are merged with the 
original john at gmail.com account after authentication is completely 
finished (my step 5)

but maybe this is implementation detail? Not sure...

IMO the period for keep these temporary accounts should be really small. 
I think user should finish the authentication (which will delete 
temporary accounts) within minutes (not the other day or so) and 
shouldn't never be assigned access token to. Otherwise there might be 
issues with temporary account already linked with some application data 
etc...

Also for your step (3), we don't want to be limited just for the default 
password form right? I think that with Authentication SPI, people may 
want various authentication mechanisms (maybe some don't even want to 
use password at all). The tricky part is, that username is already known 
and we want people to just provide credentials (aka password) . But IMO 
if we limit only to form with password + identity providers, the issue 
will return again after some time...

Marek
>> Marek
>>
>> On 14.7.2015 11:22, Vlastimil Elias wrote:
>>> +1000 for all of these improvements
>>>
>>> On 14.7.2015 09:49, Stian Thorgersen wrote:
>>>> We should improve the first login with identity provider flow as it's less
>>>> than elegant at the moment. Some of the suggestion below is how it
>>>> already works and some not!
>>>>
>>>> The mechanism to detect existing accounts should include:
>>>>
>>>> * Username
>>>> * Email
>>>> * Firstname and lastname
>>>>
>>>> This needs to work both initially on the callback from the identity
>>>> provider, but also after the user has updated the profile. If an existing
>>>> account is detected the user should be given the option to do one of the
>>>> following:
>>>>
>>>> * Cancel
>>>> * Merge - this will require the user to authenticate as the existing user.
>>>> Once authenticated the attributes, roles and identity-provider links from
>>>> the new user are copied to the existing user (not overriding existing
>>>> attributes/roles/links)
>>>> * Continue - only if existing account is found by firstname and lastname
>>>>
>>>> For this to work it's probably easier to initially always create the
>>>> account. To get around the case where email is duplicated we can set that
>>>> as an temporary attribute rather than the email.
>>>>
>>>> We also need to make sure we can define what attributes are required for a
>>>> user in a realm, including validation of each attribute. If any of these
>>>> attributes are missing the user will have to update the profile.
>>>>
>>>> Finally, we should add a expires on a user account. If a user initiates
>>>> the login with an identity provider, but never completes the above
>>>> actions (for example closes the browser on the existing account screen,
>>>> or the update profile screen) the account should automatically be removed
>>>> after a given time.
>>>>
>>>> With regards to required actions it should be possible to configure one or
>>>> more required actions for first login for a specific identity provider.
>>>>
>>>> It would be nice to nail down this flow once and for all! If we can all
>>>> agree on the flow, we can allocate someone to implement it for 1.5.
>>>> _______________________________________________
>>>> keycloak-dev mailing list
>>>> keycloak-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>