-
Notifications
You must be signed in to change notification settings - Fork 1.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
response_mode #1591 #1621
Comments
While not on our roadmap because this is quite rare in today's technology landscape (this is the first real use case I've seen since we started ORY Hydra), there's no veto from our side on this feature. Thus we'd appreciate a PR in Fosite to add this response mode. We'd expect the implementation to pass the OpenID Foundation Conformance tests before this would be merged on master, as to ensure (a) conformance (b) future certifications. |
Thanks @aeneasr we're working on a POC at first to when it works I'll see how to integrate it in Fosite https://openid.net/specs/oauth-v2-form-post-response-mode-1_0.html |
I'd recommend discussing the design before putting work in, unless you're very familiar with fosite! |
Hey @arno-joule any updates on this? |
There is now an issue in fosite for this (ory/fosite#470) and a PR (ory/fosite#509). I would add thought that I am not sure if this is really just for legacy applications? This assures that even authorization code is never logged anywhere (in the query string). |
This patch adds support for the `response_mode` parameter as defined in [OAuth 2.0 Form Post Response Mode](https://openid.net/specs/oauth-v2-form-post-response-mode-1_0.html). Additionally, values `fragment` and `query` are supported as defined in [OAuth 2.0 Multiple Response Type Encoding Practices](https://openid.net/specs/oauth-v2-multiple-response-types-1_0.html). Closes #1621
This patch adds support for the `response_mode` parameter as defined in [OAuth 2.0 Form Post Response Mode](https://openid.net/specs/oauth-v2-form-post-response-mode-1_0.html). Additionally, values `fragment` and `query` are supported as defined in [OAuth 2.0 Multiple Response Type Encoding Practices](https://openid.net/specs/oauth-v2-multiple-response-types-1_0.html). Closes #1621
This patch adds support for the `response_mode` parameter as defined in [OAuth 2.0 Form Post Response Mode](https://openid.net/specs/oauth-v2-form-post-response-mode-1_0.html). Additionally, values `fragment` and `query` are supported as defined in [OAuth 2.0 Multiple Response Type Encoding Practices](https://openid.net/specs/oauth-v2-multiple-response-types-1_0.html). Closes #1621
This patch adds support for the `response_mode` parameter as defined in [OAuth 2.0 Form Post Response Mode](https://openid.net/specs/oauth-v2-form-post-response-mode-1_0.html). Additionally, values `fragment` and `query` are supported as defined in [OAuth 2.0 Multiple Response Type Encoding Practices](https://openid.net/specs/oauth-v2-multiple-response-types-1_0.html). Closes #1621
Is your feature request related to a problem? Please describe.
This is a follow-up to the conversation @aeneasr and @Renkas had in #1591 on having response_mode form_post supported by Ory (as a configuration similar to response_type)
First I agree with @aeneasr that this is deals with legacy applications, and that modern frameworks give better flows/alternatives.
But, we live in a world surrounded by legacy applications that have limited support for OIDC. In this is especially true with Enterprise software.
In my case our organization supports Dynamics 365, we've been going back and forth for a week with Microsoft and Dynamics 365 and most of their SaaS offering, support OIDC as long as it uses a form_post. And I'm not the only one https://community.dynamics.com/crm/f/microsoft-dynamics-crm-forum/279874/portals---openid-connect---response-mode-form_post
I believe as Ory grows as an organization, supporting these very legacy applications by supporting form_post will be a differentiator that would create various ways to support the project.
Describe the solution you'd like
My desired solution would be to have a configuration option that allows the client configuration to take a response_mode, as it currently takes in the response_type.
I can accept that Ory decides this is not a direction.
Describe alternatives you've considered
Various alternatives:
-there are a few products (Azure B2C being the case) that support this approach
@aeneasr and @Renkas I'd greatly appreciate your input on this
Additional context
If this a no, please update https://www.ory.sh/docs/hydra/limitations to clearly state this and the reasons as to why so it doesn't bubble up in your issues
Add any other context or screenshots about the feature request here.
The text was updated successfully, but these errors were encountered: