Details
-
Improvement
-
Status: Open
-
Trivial
-
Resolution: Unresolved
-
None
-
None
-
Patch
Description
The OpenID Connect auth extension supports only the "implicit" flow, and currently hard-codes the value of the "response_type" parameter as "id_token". According to the OIDC spec, the authentication server should return the user with an ID token but in some auth server implementations, other values of this parameter are required and they will not work otherwise, but still return the necessary information (the user's ID token in the id_token parameter) when given their required value.
My particular use case involves authenticating against AWS Cognito. If the Cognito IdP receives a request with "response_type=id_token" rather than returning a sign-in page and authenticating the user, it returns a page showing just an "invalid request" error message. If instead "response_type=token" is used, authentication works as expected. In the [Cognito documentation|https://docs.aws.amazon.com/cognito/latest/developerguide/authorization-endpoint.html] it is stated that "response_type must be code or token".
I've only tested and confirmed that this is an issue with AWS Cognito, but according to the documentation for the OIDC identity providers on a couple other major cloud providers:
GCP's Identity Platform seems to require response_type to be "token id_token" or "id_token token"
Azure's Microsoft Identity Platform [requires|https://docs.microsoft.com/en-us/azure/active-directory/develop/v2-oauth2-implicit-grant-flow] response_type to be "id_token" or "id_token token"
I'm submitting a PR that adds an optional guacamole.properties string parameter for the OpenID auth extension that allows overriding the default value of response_type. The default value is "id_token", so the behavior remains unchanged if the override parameter is left unspecified.