OAuth 2.0 Form Post Response Mode
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.
@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 form_post is being used, so I wonder why this issue has been closed. Is it because no list of IdPs have been posted?
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 response_mode:
https://stackoverflow.com/questions/79326767/response-mode-form-post-triggers-invalid-csrf-token-in-spring-auth-server
Here are two Norwegian IdPs which support form_post, and the latter almost requires this mode:
- ID-porten: https://idporten.no/.well-known/openid-configuration
- Helsenorge: https://eksternapi.helsenorge.no/sts/oidcprov/v3/.well-known/openid-configuration
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?
@erlendfg @areguru
so I wonder why this issue has been closed
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.
See this minimal implementation as a starting point.
@sjohnr: I have tried to implement this, but the FormPostResponseModeAuthenticationSuccessHandler is not called before the OAuth2LoginAuthenticationFilter, which means I'm getting the following error: org.springframework.security.oauth2.core.OAuth2AuthenticationException: [authorization_request_not_found].
I have probably missed something I need to configure. I skipped the .withObjectPostProcessor part in SecurityConfig since we have configured other validators by using .authenticationProviders, but anyway, this shouldn't be relevant to the problem.
So what do we need to configure in SecurityConfig to deal with the error in OAuth2LoginAuthenticationFilter?
@erlendfg
I'm getting the following error:
org.springframework.security.oauth2.core.OAuth2AuthenticationException: [authorization_request_not_found].
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.
I'm getting the following error:
org.springframework.security.oauth2.core.OAuth2AuthenticationException: [authorization_request_not_found].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 response_mode=form_post didn't work was because SameSite was Lax and not None. Our auth server uses an external IdP for authentication which supports form_post, but it does not work unless we use None. This is further explained on Stack Overflow:
https://stackoverflow.com/questions/79326767/response-mode-form-post-triggers-invalid-csrf-token-in-spring-auth-server
I found the answer in this article: https://docs.feide.no/general/faq/samesite_cookie.html#changes-that-need-to-be-made-on-the-service-provider-side
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.
This issue was transferred from spring-projects/spring-authorization-server (see spring-authorization-server#2195)