[keycloak-dev] configuring social providers

[Stian Thorgersen]

* Developers may want to remove Keycloak branding (I assume this would require a paid account or a private Keycloak server)
* Developers may want to access social providers directly (for example to read Tweats)
* Some developers (like myself) will want to spend a little time configuring social providers to provide a best as possible option for users
* Some users (like myself) will not grant permission to a broker (Keycloak), but would be happy to provide access to a select few applications

I can probably come up with more, but in summary:

* Configuring social providers is relatively difficult so early adapters will not want to do it
* Advanced users will want to configure the social providers themselves for more controll (and better, at least IMO, user experience)
* There will be several use cases where it makes sense to share social config between a group of applications, but not globally

With regards to realms I have the same opinion. Some users may not want to manage a realm they just want to let users register with the site and login. In which case they'd be happy to use a public Keycloak realm.

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Monday, 22 July, 2013 3:33:22 PM
> Subject: Re: [keycloak-dev] configuring social providers
> 
> 
> 
> On 7/22/2013 10:15 AM, Marko Strukelj wrote:
> > I don't exactly remember where I saw this but it was with one of existing
> > identity broker providers ... When you set up application you specify what
> > your application needs i.e.
> >
> > - Access Email
> > - Access List of Friends
> > - Post to wall
> > - Access Documents
> > - Access Location
> >
> > You just click checkboxes, and broker requires social provider specific
> > appropriate access profiles.
> >
> > If all the interaction with social graph and social service specific APIs
> > would be proxied through Keycloak APIs then Keycloak can limit access
> > based on application profile, regardless if another application triggered
> > user to grant a greater access to Keycloak then one specific application
> > requires.
> >
> > Also the phishing alarm when seeing Keycloak mentioned in authorization
> > form can be alleviated by adding a Powered by Keycloak badge to SignIn
> > page of the app, or mentioning Keycloak some other way.
> >
> 
> That's a good point.  So what are the current downsides of a global
> account?:
> 
> * Revoke page would only have keycloak.org listed
> * Social login page would state that Keycloak (and not the app) is
> interested in a specific scope.  Which could be mitigated by having a
> "Powered by Keycloak" on the signin page of the app.
> 
> 
> 
> --
> 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
>