[keycloak-dev] Improve first login with identity provider
Vlastimil Elias
velias at redhat.com
Thu Jul 16 02:38:39 EDT 2015
On 16.7.2015 03:31, Scott Rossillo wrote:
> Why can't we just require email scope from upstream IDPs? What system
> these days doesn't use email as some sort of unique identifier,
> including Twitter and Github?
You should be surprised ;-). Some Oauth providers simply doesn't have
separate email scope, some of them doesn't return email at all (twitter,
StackOverflow), some of them doesn't return email in some cases, eg.
Github does not return email if user sets "Public email" to "Don't show
my email address" in his user profile Setting (which looks like error
for me that this setting affects REST API, but it is how it works).
Facebook user can deny providing email during approving login for your
server on Facebok's "Consent" page.
Vl.
>
> On Wed, Jul 15, 2015 at 9:09 AM Bill Burke <bburke at redhat.com
> <mailto:bburke at redhat.com>> wrote:
>
> Looks like IDP logins will require configurable auth flows too like
> registration and login currently have in master. Man, all this
> stuff is
> going to be hard to get both easy to use and easy to extend.
>
> On 7/15/2015 4:40 AM, Vlastimil Elias wrote:
> > I agree also that solution with temporary user account is not ideal.
> > Ideal solution (which I proposed originally) is to present "Update
> > Account Page" as part of social registration flow before KC DB
> account
> > is created. So you sort out all conflicts in this phase and then
> create
> > final correct user or link social account to existing KC account.
> >
> > Vl.
> >
> > On 15.7.2015 10:00, Stian Thorgersen wrote:
> >> After some thought I agree the proposal I made is way to
> complicated. Implementing the migrate account feature would be way
> to complicated, and probably not that often used.
> >>
> >> I like the idea of having an option on an IdP to trust email or
> not. We don't need that many options though, a simple on/off
> toggle will be enough. When login using a new IdP and email exists
> if this option is enabled we should just add the link to the
> existing account, if it's disabled we should just display the
> error message that email is already in use (like we do now), but
> we can improve on that message to make it more clear to the user
> what they have to do.
> >>
> >> That won't solve the initial problem that sparked this
> conservation though. If the user logs in with a IdP that doesn't
> require email we can now ask the user to enter the email address,
> but if they then add an email address that's already in use
> there's not an easy way to recover from that. Maybe that could be
> solved by not creating the account until the user has performed
> the initial set of required actions on a first login with IdP?
> >>
> >> ----- Original Message -----
> >>> From: "Scott Rossillo" <srossillo at smartling.com
> <mailto:srossillo at smartling.com>>
> >>> To: "Bill Burke" <bburke at redhat.com
> <mailto:bburke at redhat.com>>, keycloak-dev at lists.jboss.org
> <mailto:keycloak-dev at lists.jboss.org>
> >>> Sent: Tuesday, 14 July, 2015 9:16:12 PM
> >>> Subject: Re: [keycloak-dev] Improve first login with identity
> provider
> >>>
> >>> +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 <mailto: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
> <mailto:mposolda at redhat.com> >
> >>>>>> To: "Vlastimil Elias" < velias at redhat.com
> <mailto:velias at redhat.com> >, keycloak-dev at lists.jboss.org
> <mailto: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 <mailto: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
> <mailto: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 <mailto: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
> <mailto: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 <mailto: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 <mailto: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 <mailto: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
> <mailto:bburke at redhat.com> " and password
> >>> 2) User does a social login, new account is created "
> bburke at redhat.com <mailto: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
> <mailto:bburke at redhat.com> " and password
> >>> 2) User logins with Facebook, " bburke at redhat.com
> <mailto: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
> <mailto: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
> <http://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 <mailto:keycloak-dev at lists.jboss.org>
> >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >>>
> >>> _______________________________________________
> >>> keycloak-dev mailing list
> >>> keycloak-dev at lists.jboss.org <mailto:keycloak-dev at lists.jboss.org>
> >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >> _______________________________________________
> >> keycloak-dev mailing list
> >> keycloak-dev at lists.jboss.org <mailto:keycloak-dev at lists.jboss.org>
> >> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >
>
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org <mailto: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
--
Vlastimil Elias
Principal Software Engineer
jboss.org Development Team
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150716/36a2ef90/attachment-0001.html
More information about the keycloak-dev
mailing list