[keycloak-dev] Improve first login with identity provider

Tue Jul 14 15:16:12 EDT 2015

+1 for auto-merge. We modified the code to do that.
I like Bill's approach with multiple options though as this is the most
flexible and different people will have different requirements.

On Tue, Jul 14, 2015 at 11:13 AM Bill Burke <bburke at redhat.com> 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.
>
>
>
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150714/87aa88cb/attachment-0001.html 