Support grouping the OIDC configuration by the IDP names

[sberyozkin]

Description
Stephane @FroMage has opened a discussion about the application directly supporting the social/well-known provider logins (Google, Facebook, GitHub, etc) without expecting that the on-site IDP like Keycloak is installed which can support the delegation to these providers. So the application can offer some local login option (name/password for ex plus try to enrich it with some publicly available OIDC IDP options)

Implementation ideas
Sebastien @sebastienblanc has come up with the idea of grouping the OIDC configurations by the IDP name, for example:

quarkus.oidc.linkedin.auth-server-url=https://linkedin/auth
quarkus.oidc.linkedin.client-id=backend-service

quarkus.oidc.facebook.auth-server-url=https://facebook/auth
quarkus.oidc.facebook.client-id=backend-service

Note the only thing which varies is a qualifier like linkedin or facebook.
The OIDC adapter will figure out which configuration to use based on some convention, for example, if a Login with LinkedIn is pressed then it would be up to the application to setup an HTTP context property or header like "IDP: linkedin" etc

[sberyozkin]

CC @stianst @pedroigor

[stianst]

I would discourage supporting social providers directly beyond allowing users to configure them as OIDC providers. It requires a lot of maintenance, documentation and testing.

Then there's also the case that in most such cases you want to add multiple providers, not just a single one, which raises a lot of problems. How does a user select which one they want to do? Do you know add a login page which adds support to list identity providers? How do you map attributes from different providers into an internal model? I could go on and on on how much effort it is to provide identity brokering in a proper way.

[stianst]

By the way we have this great thing called Keycloak that does all of the above. So I would rather see blog posts and ideas on how to enable social login on Quarkus using Keycloak. Let's focus on making that experience super simple and nice rather than duplicating the effort here.

[sberyozkin]

@stianst thanks. As long as it is OIDC it should be fine I guess, though indeed the brokering is something I'd recommend as well, see the thread.

I'm not really sure if the users are ever doing it directly. Stephane, @FroMage, can you comment please ?

[sberyozkin]

@stianst Hi Stian, re Keycloak and the social login, am I right in assuming that as far as Quarkus OIDC adapter is concerned, the existing web-app application would just work right now with Facebook/etc if the KC autentication page is customized and KC itself is configured accordingly ?

[stianst]

Commented on the thread. What he's asking for is basically Keycloak ;)

[stianst]

For social there's really only 3 options that makes sense:

• Allow users to use a single social provider as the IdP
• Recommend using Keycloak (or some other similar thing)
• They can obviously implement it all themselves, but I think they will quickly realise that they wish they had just picked something that already implemented it for them

It's way out of the scope of Quarkus to become some sort of trimmed down IdP.

[sberyozkin]

@stianst Yeah I was just about to comment, Stephane was concerned it (or whatever the immediate IDP the users work with) could not be available in some cases, but Keycloak is freely downloadable :-).

[FroMage]

Well, no, I'm not asking to reimplement Keycloak, but what our story is for people who want to provide social logins as an option without having to use Keycloak.

A LOT of sites handle login by delegating to whatever OpenID provider, like this: https://doodle.com/login

I didn't think we could afford to tell users that to use external openid providers they had to use Keycloak, but it looks like you're saying that's what we should tell them?

[sberyozkin]

@stianst Definitely but Sebastien's proposal is only about selecting an OIDC adapter connection configuration. Actually, may be we are talking about the multitenancy here :-)

[FroMage]

Same for https://gitter.im/

[FroMage]

My question is: what's our user story for an app developer to use openid of any of the famous providers, without using keycloak?

I want to write a Quarkus app that delegates login to Google/Github/Facebook: what does my app look like?

[stianst]

@FroMage not at all. Users can use whatever external OpenID Connect provider they choose. That could be Google, Auth0, Octa, or Keycloak. Now if they want to use multiple providers, have users locally registered, etc. they should make a choice on an IdP that supports that for them.

[sberyozkin]

@FroMage It looks like to me now this issue is effectively a duplicate of #4448. Of course we'd recommend to use Keycloak and I don't see the users preferring to work with the quality IDP like Keycloak as per @stianst 's advice starting doing it all manually, but once #4448 is fixed, the users would be free to do whatever they want really since the configuration would be dynamically loaded

[stianst]

Doodle for instance quite likely uses an IdP or they've gone and implemented a whole bunch of stuff themselves.

[stianst]

@sberyozkin that's correct with #4448 users can configure multiple IdPs, then create some sort of login page that let's users select which IdP they want to use.

[sberyozkin]

@stianst Yeah, sounds like exactly what @FroMage is asking about :-)

[sberyozkin]

@FroMage Please watch #4448, I think we can close this issue as a duplicate

[FroMage]

OK fine.