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