[keycloak-dev] Improve first login with identity provider

Vlastimil Elias velias at redhat.com
Wed Jul 15 04:04:48 EDT 2015

Hi Bill,

I agree that account duplicity checking should be based on email only.

My question is which flow will be applied in case if social IdP do not 
provide an email (it is a case for many Idp like Twitter, Github etc) 
but email is mandatory in Keycloak?
User is asked to insert his email on "Update Your Account" page which is 
now implemented as "login action" which means that KC user account 
already exists in this phase.
What to do if email duplicity is detected in this phase? Or do you plan 
to move "Update Your Account" page earlier into reg flow before user 
account is created in KC DB?

I do not see description of this flow in any of your two emails in this 
thread but it have to be resolved somehow.

See detailed problem description in 
https://issues.jboss.org/browse/KEYCLOAK-1540 - this is real problem 
reported by user of Red Hat Developer site.



On 14.7.2015 17:11, Bill Burke wrote:
> On 7/14/2015 10:30 AM, Marek Posolda wrote:
>> 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...
> This is WAY too complicated.  Please see my long previous email.  There
> should never be any temporary accounts.  I'll summarize my previous
> email again:
> * Existing accounts should only be detected by email.  "Bill Burke" gets
> 56 million hits on Google.  It is a very common name.
> Default behavior:
> 1) User registers with "bburke at redhat.com" and password
> 2) User does a social login, new account is created "bburke at redhat.com"
> is stored in a user attribute.  i.e. "Alternative email".
> Website requires linking:
> 1) User registers with "bburke at redhat.com" and password
> 2) User logins with Facebook, "bburke at redhat.com" exists. Prompted
> "Account exists with same email you have registered at Facebook.  You
> have been sent an email verification message.  Please follow the
> directions of this email to login"
> 3) User goes to Inbox, clicks link in email, message screen appears
> "Your Facebook account has been linked.  Click "Ok" to continue.".  User
> gets forwarded to website.
> 4) Facebook is linked to pre-existing "bburke at redhat.com" account.
> This would be implemented with Authentication Flows.  There would be no
> temporary account.  Step #2 would create a ClientSession model and store
> all the facebook metadata within it.  Step #3 would import the facebook
> metadata.
> Alternatively, you could just trust the IDP and do the link
> automatically.  Does Google et. al. send an "email-verified" metadata?
> User wants to link accounts:
> 1) User goes to Account Service, Account LInking page
> 2) User is provided with list of IDPs i.e. (Facebook, Google, etc). And
> clicks one.
> 3) User is prompted to login via that IDP
> 4) User receives prompt "Your Facebook account has been linked.  Click
> "OK" to continue".  User gets forwarded to website.
> In this scenario, there is no removal of old accounts.  The initiating
> account,X,  would import the old Facebook account, Y.  X would create a
> new federation link to Facebook.  Y would be disabled and its facebook
> link removed.  Y is marked as "merged" or "linked" and points to account
> X.  You need to keep Y around as the user may have done a bunch of
> actions under that account...i.e. posted on jboss.org forums.

Vlastimil Elias
Principal Software Engineer
jboss.org Development Team

More information about the keycloak-dev mailing list