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

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