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

Wed Mar 13 14:21:45 EDT 2019

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 at optionfactory.net> 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 at redhat.com> wrote:
>
>>
>>
>> On Wed, 13 Mar 2019 at 10:39, Francesco Degrassi <
>> francesco.degrassi at optionfactory.net> 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 at redhat.com>
>>> 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 at optionfactory.net> 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 at optionfactory.net> 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 at redhat.com>
>>>>>> 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 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
>>>>>>>>>>
>>>>>>>>>