search

Open-EO / openeo-api

The openEO API specification
http://api.openeo.org
Apache License 2.0
91 stars 11 forks source link

OIDC: Extra parameters in default clients? #534

Open m-mohr opened 1 month ago

m-mohr commented 1 month ago

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: https://github.com/IdentityModel/oidc-client-js/pull/1296

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

m-mohr commented 1 month ago

@soxofaan Do you have thoughts about this?

soxofaan commented 1 month ago

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

m-mohr commented 1 month ago

Google for example needs an extra parameter to request a refresh token (instead of the offline scope). See also https://github.com/Open-EO/openeo-earthengine-driver/issues/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 commented 1 month ago

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 commented 1 month ago

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 commented 1 month ago

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.