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

Wed Mar 13 14:24:10 EDT 2019

Ok, thanks.
I'll open a Jira and submit a PR to this effect ASAP.

On Wed, 13 Mar 2019, 19:21 Stian Thorgersen, <sthorger at redhat.com> wrote:

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