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

On Wed, 13 Mar 2019 at 10:39, Francesco Degrassi < francesco.degrassi(a)optionfactory.net&gt; wrote: > I understand. > Taking this into consideration, I'd propose to add a high-level config > option "offline access" to the Google Identity Provider configuration, a > dropdown with three possible values: > - never request offline access (which is the current behavior) > - always request offline access (which always adds the > access_type=offline to the authorization request to google) > - allow offline access to be requested by clients (with docs explaining > that clients can pass a access_type=offline parameter if they want refresh > tokens from google), which adds access_type as a forwarded parameter > I'm not convinced about the last option. When would you use that? Clients talk to KC, not Google. KC doesn't support access_type=offline so makes no sense that the client would use that. > > This should be easy to use and support all possible use cases; would you > support something of the sort? > Cheers > > *Francesco* > > > On Wed, 13 Mar 2019 at 10:14, Stian Thorgersen <sthorger(a)redhat.com&gt; > wrote: > >> 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 >>>>>>>> >>>>>>>