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

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 >> >

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 >>>> >>>

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 >>>>>> >>>>>

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 >>>>>>>> >>>>>>>

I'd remove the last option and simply make it an "Request offline token: ON/OFF". If someone needs it in the future we can discuss it then On Wed, 13 Mar 2019 at 13:35, Francesco Degrassi < francesco.degrassi(a)optionfactory.net&gt; wrote: > I see your point, although in some cases the abstraction is leaky, e.g. > in the token exchange case, where the client knows there is Google behind > KC and relies on a refresh token being available even though KC doesn't > necessarily. > Maybe we could remap scope=offline to access_type=offline for Google, but > I'm not sure, it feels a workaround for Google doing their own thing. > > Let me know your preference, I'm ok with removing the last option. > Cheers > > Francesco > > On Wed, 13 Mar 2019, 13:00 Stian Thorgersen, <sthorger(a)redhat.com&gt; wrote: > >> >> >> 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 >>>>>>>>>> >>>>>>>>>