Closed tosoikea closed 11 months ago
I think the correct link should be this https://datatracker.ietf.org/doc/html/rfc6749#section-4.1.3 but I get your point.
If the client type is confidential or the client was issued client credentials (or assigned other authentication requirements), the client MUST authenticate with the authorization server as described in Section 3.2.1.
So I guess this is why most authorization servers (read hundreds tested with this module) require client authentication for the token endpoint. That being said, if you omit the secret
option when using Grant then client_secret
won't be sent to the authorization server, because undefined
values are being filtered out.
For example, I removed my secret
and tried to login with Google, here is the resulting error:
{
"error": "invalid_request",
"error_description": "client_secret is missing."
}
For apps hosted on Azure AD in particular you may want to provide a certificate and use that to authenticate your client:
As you can see in that case there is no secret
provided in the Grant config: https://github.com/simov/grant/blob/master/examples/token-endpoint/config.json
Summary
The current OAuth2 library implementation incorrectly includes the client_secret for the authorization_code grant type. This is against the specifications as mentioned in the RFC6749.
Details
Reference
Current Implementation
The current implementation sends the client_secret when making a POST request to the token endpoint for the authorization_code grant:
Source: OAuth2 Implementation
Question for Development Team
Is there a specific and valid reason why the client_secret is included in this scenario?
Impact
This misalignment with the OAuth2 standard might cause compatibility issues with certain OAuth2 providers that strictly enforce the token endpoint specification. Moreover, unnecessary transmission of client_secret could pose a potential security risk if intercepted.
Recommended Action
Please review the decision to include the client_secret and adjust the implementation to align with the OAuth2 standard unless there's a compelling reason to do otherwise.