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

[Stian Thorgersen]

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 at optionfactory.net> 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 at redhat.com>
> 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 at redhat.com> 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 at lists.jboss.org
>>> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>
>>>
>>> _______________________________________________
>>> keycloak-dev mailing list
>>> keycloak-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>
>>