-
Notifications
You must be signed in to change notification settings - Fork 1.3k
OAuth 2.0 Form Post Response Mode #207
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
Comments
@TakahikoKawasaki I'm curious which well-known OIDC providers have implemented this? Are you able to provide me a list of providers? |
Not limited to but at least the certified OPs whose "Form Post OP" column is checked support OAuth 2.0 Form Post Response Mode. |
See this minimal implementation as a starting point. |
Is there any plan to support response_mode? |
One of our IdP requires that I posted the following on Stackoverflow for a couple of days ago, and now I understand why it's not possible to set this value for Here are two Norwegian IdPs which support |
I would like to add some context to the previous comment. ID-porten is the common IDP for Norwegian public services, and is operated by the Norwegian Digitalisation Agency (Digdir). It is used for instance by the "Norwegian Labour and Welfare Administration". Helsenorge is the National online health services in Norway. Both welfare administation and medical information services are of course considered particularly sensitive, and an eID with the highest security level is required. Form Post response mode was introduced to address security concerns related to encoding response values in the default query response mode, which sends the response parameters as a part of the redirect URL. Form Post Response Mode is sending response parameters in the body of an HTTP POST request. This prevents sensitive data from being stored in HTTP logs, referral headers, or browser histories, reducing the risk of data leakage. What is the reasoning for not implementing this? |
This issue is still open, however, it's "on-hold" until there is greater demand for the feature. This issue was logged in Feb 2021 and there are still no upvotes on the main issue. We prioritize features based on community demand by reviewing upvotes on the main issue. In the meantime, consuming applications can easily implement this feature using the minimal implementation linked in this comment. |
@jgrandja How can we upvote this issue? |
@areguru Add a 👍 to the main issue comment. |
@sjohnr: I have tried to implement this, but the I have probably missed something I need to configure. I skipped the So what do we need to configure in |
Please open a stack overflow question that includes all the details and code to reproduce the problem, then provide the link here and I'll take a look. |
@sjohnr: I figured it out. We're actually not affected by this bug since it's related to the communication between the client and the auth server. The reason why I found the answer in this article: But this must work between the client and the auth server as well, and I can confirm that the minimal implementation works, even though it was not related to our first problem. |
See FormPostRedirectStrategy as it may be reusable for implementing this feature. |
Uh oh!
There was an error while loading. Please reload this page.
OAuth 2.0 Form Post Response Mode support.
Form Post Response Mode (aka
response_mode=form_post
) has a considerably big impact on authorization server implementations. It is recommended that the feature be designed and implemented from the beginning.The text was updated successfully, but these errors were encountered: