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

Wed Mar 13 07:59:55 EDT 2019

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