Re: [keycloak-dev] Allow access_type parameter to be sent to Google Identity Provider

End of the day we are trying to make Keycloak user friendly and having too many configuration options and tweaks doesn't help with that, especially config options like what is being proposed at the moment that requires users to know specific query parameters from Google. I'd rather see either this somehow automatically being figured out by Keycloak or a more high level config option being introduced. That is why I'm asking for details on your use-case and not just accepting a low level config option to be added without discussion. I don't think we will know if/when an offline token is needed automatically, so should rather look at adding an option to request offline token. With OIDC that's done through scope offline, but it seems Google has decided not to follow the spec, but rather do their own thing. On Tue, 12 Mar 2019 at 21:26, Francesco Degrassi < francesco.degrassi(a)optionfactory.net&gt; wrote: > Hello again, Stian. > Putting my specific use-case aside for a minute, do you see a specific > reason not to allow users to configure finer-grained OIDCIdentityProvider > options such as forwarded parameters for well-known, first-party supported, > OIDC compliant social login Identity Providers such as Google? > > *Francesco * > > On Tue, 12 Mar 2019 at 19:20, Francesco Degrassi < > francesco.degrassi(a)optionfactory.net&gt; wrote: > >> We're logging users in through multiple identity providers configured on >> keycloak. >> Regardless of the idp used, the user can link their Google account (if >> they logged through a different idp) to have the application poll Google >> APIs periodically. >> >> Cheers >> >> On Tue, 12 Mar 2019, 18:54 Stian Thorgersen, <sthorger(a)redhat.com&gt; >> wrote: >> >>> Are you using offline tokens from Keycloak that are being exchanged for >>> offline tokens from Google? Or is it what I suspect that you have a user >>> logged-in through Google and you want to access something in Google APIs >>> while the user is logged-in? >>> >>> On Tue, 12 Mar 2019 at 15:27, Francesco Degrassi < >>> francesco.degrassi(a)optionfactory.net&gt; wrote: >>> >>>> I'm afraid I cannot agree, the key element is "unless you really need >>>> one". >>>> The use case for access_type=offline is just that, in case you need to >>>> refresh tokens offline (i.e. when the user is not at the browser). >>>> Forbidding a use case explicitly allowed and supported by google >>>> cannot be correct. >>>> >>>> I agree with Marek about the fact that allowing users to configure >>>> forwarded parameters is the simplest and more general solution, even though >>>> it is not the most user-frlendly, since people might not know they need to >>>> add access_type as a forwarded parameter. Maybe it can be mitigated through >>>> documentation for Google Identity Provider. >>>> >>>> Should I open a Jira before submitting a PR? >>>> Cheers >>>> >>>> *Francesco* >>>> >>>> On Tue, 12 Mar 2019 at 15:09, Stian Thorgersen <sthorger(a)redhat.com&gt; >>>> wrote: >>>> >>>>> I'm not convinced about this approach for two reasons: it's not very >>>>> user-friendly and secondly it's not correct to request an offline token >>>>> unless you really need one. >>>>> >>>>> Google doesn't use refresh tokens for regular sessions, but rather >>>>> give you a fairly long expiration token. As it's lacking the refresh token >>>>> it means you need to refresh the token with a redirect. This can be done >>>>> with a hidden iframe. So the correct approach here is to have the app >>>>> refresh the token by re-auth to KC with a redirect (which can be in a >>>>> hidden iframe). This will do it in a proper way without using offline >>>>> tokens. >>>>> >>>>> >>>>> >>>>> On Tue, 12 Mar 2019 at 14:32, Marek Posolda <mposolda(a)redhat.com&gt; >>>>> wrote: >>>>> >>>>>> Hi, >>>>>> >>>>>> I already saw some request(s) in the past with regards to the >>>>>> GoogleIdentityProvider not provide same level of fine-grained >>>>>> configuration as the OIDC Identity provider. I think that generally >>>>>> it >>>>>> will be nice to remove this limitation(s) and hence allow some >>>>>> custom >>>>>> configurations to be done on the GoogleIdentityProvider as well. >>>>>> >>>>>> So IMO the best would be the option (b) - just add the option to >>>>>> support >>>>>> forwarded parameters. This will probably allow best flexibility and >>>>>> hopefully the usability will be also fine. >>>>>> >>>>>> Marek >>>>>> >>>>>> On 12/03/2019 11:19, Francesco Degrassi wrote: >>>>>> > Hello, >>>>>> > we're testing Keycloak with Google as a social identity provider >>>>>> and using >>>>>> > the token exchange functionality to get access to the IDP access >>>>>> token. >>>>>> > I noticed that Google requires the access_type parameter to be set >>>>>> to >>>>>> > "offline" in the call to the authorization endpoint to release a >>>>>> refresh >>>>>> > token, but there is no easy way to do this in Keycloak; >>>>>> configuring a >>>>>> > generic OIDC identity provider allows me to configure access_type >>>>>> as a >>>>>> > forwarded parameter, but no such option exists using >>>>>> GoogleIdentityProvider. >>>>>> > >>>>>> > I have a patch that (a) modifies GoogleIdentityProviderConfig and >>>>>> overrides >>>>>> > getForwardedParameters() to add "access_type" to the returned >>>>>> values. >>>>>> > >>>>>> > Other options I considered include (b) changing the UI to allow to >>>>>> > configure the forwareded parameters for GoogleIdentityProvider >>>>>> (since it >>>>>> > extends OidcIdentityProvider) or (c) add a boolean configuration >>>>>> option to >>>>>> > GoogleIdentityProviderConfig to allow/disallow forwarding the >>>>>> parameter or >>>>>> > (d) add a boolean configuration option to >>>>>> GoogleIdentityProviderConfig to >>>>>> > set "access_type" to "offline" if checked. >>>>>> > >>>>>> > Which would be the preferred route? Would a pull request be >>>>>> accepted? >>>>>> > Cheers. >>>>>> > >>>>>> > *Francesco Degrassi* >>>>>> > Tech Lead >>>>>> > +39 329 4128 422 <+39+329+4128+422> >>>>>> > *OptionFactory <http://www.optionfactory.net/>* >>>>>> > _______________________________________________ >>>>>> > keycloak-dev mailing list >>>>>> > keycloak-dev(a)lists.jboss.org >>>>>> > https://lists.jboss.org/mailman/listinfo/keycloak-dev >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> keycloak-dev mailing list >>>>>> keycloak-dev(a)lists.jboss.org >>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>>>>> >>>>>