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

Wed Mar 13 08:35:03 EDT 2019

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