OAuth 2.0 Authorize Endpoint with POST Method

[MayankShivhare999]

Hello,

I am trying to use the OAuth 2.0 Authorization Endpoint (https://www.ory.sh/oauth2/auth) with the POST method instead of GET. My goal is to pass parameters in the body with Content-Type: application/x-www-form-urlencoded rather than as query parameters in the URL.

When I make a POST request to the OAuth 2.0 Authorization Endpoint, passing the parameters in the body, I am able to successfully retrieve the login_challenge. However, after accepting the login_challenge using the URL https://www.ory.sh/admin/oauth2/auth/requests/login/accept, I receive an OAuth2RedirectTo object. This object contains a redirectTo value that includes only the login_verifier, but it does not have other essential parameters like client_id, redirect_url, etc.

When I try to authenticate using only the login_verifier, the authentication process fails with the following error: "Client authentication failed (e.g., unknown client, no client authentication included, or unsupported authentication method)."

Could you please help me identify what might be going wrong, and how I can resolve this issue? I would really appreciate any assistance you can provide.

Thank you in advance for your time and support!

[vinckr]

Hello @MayankShivhare999

I think - and I am not the expert for OAuth2 spec - that POSTing to this endpoint is not defined in the OAuth2 spec.

POSTing to the Authorization Endpoint is behaviour that is not defined by the RFC beyond stating that a POST may be accepted, but doesn't have to be. (related SA discussion)

So (without going deeper into the source code) I think this is probably not implemented at the moment.

My goal is to pass parameters in the body with Content-Type: application/x-www-form-urlencoded rather than as query parameters in the URL.

Can you explain why you would prefer that? I am struggling to understand what you are trying to do. Maybe the Client Credentials flow is what you are looking for?

[MayankShivhare999]

@vinckr Thank you for your response.

Below is curl which I am using.

curl --location 'https://localhost:4444/oauth2/auth['](https://localhost:4444/oauth2/auth%27)
--header 'Content-Type: application/x-www-form-urlencoded'
--data-urlencode 'client_id={{client_id}}'
--data-urlencode 'redirect_uri=https://oauth.pstmn.io/v1/callback['](https://oauth.pstmn.io/v1/callback%27)
--data-urlencode 'response_type=code'
--data-urlencode 'state=123456789'
--data-urlencode 'audience={{audience}}'
--data-urlencode 'scope=fhirUser openid launch offline_access'

I want to avoid passing parameters in url itslef; I want to pass parameters value as request body instead.

[MayankShivhare999]

I am working on Smart on Fhir requirements.

Refer this Link for details

The following requirements are adopted from OpenID Connect Core 1.0 Specification section 3.1.2.1(https://openid.net/specs/openid-connect-core-1_0.html#AuthRequest)

• Authorization Servers SHALL support the use of the HTTP GET and POST methods at the Authorization Endpoint.
• Clients SHALL use either the HTTP GET or the HTTP POST method to send the Authorization Request to the Authorization Server. If using the HTTP GET method, the request parameters are serialized using URI Query String Serialization. If using the HTTP POST method, the request parameters are serialized using Form Serialization and the application/x-www-form-urlencoded content type.

@vinckr, Please let me know if you need any other details.

[vinckr]

I see - it is probably out of scope for me to solve here to be honest - but Ory offers dedicated support agreements for self-hosting Ory, which can also include feature requests if it fits into the product. Please contact [email protected] if you are interested in that.

[MayankShivhare999]

@vinckr
If Ory plans to support the authorization endpoint over POST, then this is likely a Bug.
The GET authorization endpoint works without issues, and while the POST authorization endpoint is supported in Hydra, the login and accept login workflow fails after performing the login.

Refer this for details

[vinckr]

As far as I can tell there are no plans to support this and its not part of the core OAuth2 spec.
I might be wrong.