OIDC: Extra parameters in default clients?

[m-mohr]

Some OIDC services (unfortunately) require some extra parameters to be sent alongside the requests.
Example: Google needs an access_type parameter to get refresh-tokens

It looks like some libraries also support this.
Example: IdentityModel/oidc-client-js#1296

Shall we add an optional field with extra parameters that clients could mix into the request?

[m-mohr]

@soxofaan Do you have thoughts about this?

[soxofaan]

I don't understand the use case of IdentityModel/oidc-client-js#1296 well enough. On what OIDC request would you need additional parameters?

[m-mohr]

Google for example needs an extra parameter to request a refresh token (instead of the offline scope). See also Open-EO/openeo-earthengine-driver#87. Not really spec compliant (although they claim that), but something that seems happen in practice. I'm wondering whether others have similar issues, then we could provide this as a solution. Wouldn't do it just for Google though.

[soxofaan]

Yeah, when playing with google OIDC a long time ago, I've also had some issues with them doing some non-standard stuff (or at least doing different things than other providers). I'm not sure we should spend a lot of time trying to adapt to them.

Note that if you really want to integrate Google there are already workarounds through identity federation services like EGI, or host-your-own-Keycloak. If you want Google, you probably want others like GitHub or Microsoft, so you need such a federation/proxy thing anyway

[m-mohr]

I need Google for Google Earth Engine with specific scopes that need to be set, so don't need others and a Keycloak etc would be quite some overhead if it would work at all. Never tried it...

[m-mohr]

I think I found another use case of such a query parameter.
For example, we are using this prompt=login/consent/... parameter in openEO Platform.
So I think an optional object that defines additional query parameters to the authorization endpoint isn't that out of scope for us.