Description
Expected Behavior
The different combinations of supported by OIDC response_type values are described in
https://darutk.medium.com/diagrams-of-all-the-openid-connect-flows-6968e3990660
Normally only 3 different types of response_type are used:
1. code id_token
2. code token
3. code id_token token
https://stackoverflow.com/questions/57302426/when-would-i-use-a-hybrid-flow-with-response-type-code-id-token-token-in-openid
The support of hybrid oidc flows will help to communicate with Azure AD B2C https://docs.microsoft.com/en-us/azure/active-directory-b2c/openid-connect#send-authentication-requests
Current Behavior
oauth2-proxy supports only “response_type", "code", which is authorization code flow.
Possible Solution
Add possible values of “response_type" to configuration.
Parse response of callback to read access and Id tokens.
Context
The suggestion was already mentioned in comments in different issues.
In order to get an id_token with azure we seem to have to specify the response_type=code id_token in the request. Currently the provider_default implementation only does code
#131 (comment)
I see in provider default, it has response_type=code, can we set response_type=token option in oidc provider?
#586 (comment)
Your Environment
Fork of oauth2-prexy/oauth2-proxy March 2021, v7.0
Activity
JoelSpeed commentedon Apr 1, 2021
Did anyone ever start a proof of concept on this? We are undergoing some major changes to the provider packages at the moment and I'd rather we stabilise that before adding extra features if they are complex. If someone has a POC and the changes are actually not too bad, then I think it would be ok to proceed. Seems like a reasonable feature request though
frittentheke commentedon May 14, 2021
I believe this idea is quite valid to allow for more OAuth backends / providers to be used and adapted to.
I was talking to @samirachoadi who is working on a PR to support ADFS.
To support authentication against ADFS 3.0 it would be required to use the token directly and not go via the id_token, see my comment: #1021 (comment)
I can use and authenticate via Grafana's Generic OAuth client just fine, because it supports configuration of the
id_token_attribute_namevia grafana/grafana#26577 which I can then simply configure toid_token_attribute_name = access_tokenand it works.With OAuth2-Proxy being a universal reverse proxy, support for such "non-standards" or other flows would just be create to not depends on all the individual applications to support OAuth and to support it with all sorts of flavors, but to have OAuth2-Proxy mitigate this chaos ;-)
frittentheke commentedon Jun 14, 2021
@MNF there were multiple ResponseTypes supported with the louketo-proxy / keycloak-proxy:
https://github.com/louketo/louketo-proxy/blob/c1e1afea5671837f2dfea46eee98bd9f0208e87f/oauth_test.go#L172
Maybe reusing some of its logic and even code is sensible as it worked and still works for tons of people using this implementation.
github-actions commentedon Aug 14, 2021
This issue has been inactive for 60 days. If the issue is still relevant please comment to re-activate the issue. If no action is taken within 7 days, the issue will be marked closed.
frittentheke commentedon Aug 17, 2021
Not stale
github-actions commentedon Oct 17, 2021
This issue has been inactive for 60 days. If the issue is still relevant please comment to re-activate the issue. If no action is taken within 7 days, the issue will be marked closed.
michael-freidgeim-webjet commentedon Oct 17, 2021
the issue is still relevant
github-actions commentedon Dec 17, 2021
This issue has been inactive for 60 days. If the issue is still relevant please comment to re-activate the issue. If no action is taken within 7 days, the issue will be marked closed.
6 remaining items