I'm confused, I'll try to step through the process of a user
that logs in via Google through Keycloak, to check that we have the same understanding:
1. A user visits
www.acme.com and clicks on login (see attachment p01.jpg)
2. The user clicks on the Google icon as the user can't be asked to register with yet
another site
3. The user is redirected to Google to allow Acme to access basic details about his
account (see attachment p02.jpg)
4. The user is redirected back to the Keycloak callback, which retrieves the user profile
from Google, creates an internal user in Keycloak, and eventually redirects the user back
to
www.acme.com/logged-in
Next time the user visits
www.acme.com (and is not still logged-in) the user can click
the login with Google icon again and is redirected to
www.acme.com/logged-in without
having to grant permission to the application, or login to Google (as long as the user is
already logged in with Google).
Finally, the user can now choose to disable access for the application to his Google
account (see attachment p03.jpg). If the application is revoked, the user expects to next
time he tries to login with Google to have to re-authorize access for Acme to his Google
account.
The key things to note is that a user grants access to his Google account, which he does
to Acme (the application), not to the Keycloak server. Initially I would say it's best
to have a config per application, then later introduce a mechanism to share these between
multiple applications when that makes sense. However, for an online version of Keycloak
(public SaaS) it would never make sense to have a global configuration.
Ridiculous...Of course it makes sense to have a global account for the
SaaS...Its a lot easier to set up if there is a global Keycloak account
that is re-used. Simple is "Enable Social Login" checkbox. Advanced is
setup your own account.
BTW, how many web surfers even know that the revoke feature even exists?
- [REVOKE]
makes about as much sense to me as a few of the domains I have listed in
my own revoke page:
si.auth.fyre.co
While fyre.co is an identity broker, I don't know WTF "si" is.
--
Bill Burke
JBoss, a division of Red Hat