Skip to content

client_id and client_secret provided via query parameters are accepted for client_secret_post #1378

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

Closed
idotobi opened this issue Oct 2, 2023 · 4 comments
Assignees
Labels
type: bug A general bug
Milestone

Comments

@idotobi
Copy link

idotobi commented Oct 2, 2023

Describe the bug
When a client has the authentication method client_secret_post enabled, token requests like the following succeed:

POST /oauth2/token?client_id=messaging-client&client_secret=secret&grant_type=client_credentials

However, according to The OAuth 2.1 Authorization Framework specification they must not.

Including the client credentials in the request content using the two parameters is NOT RECOMMENDED and SHOULD be limited to clients unable to directly utilize the HTTP Basic authentication scheme (or other password-based HTTP authentication schemes). The parameters can only be transmitted in the request content and MUST NOT be included in the request URI.

To Reproduce

  1. Adapt the samples/default-authorizationserver/src/main/resources/application.yml
     oauth2:
       authorizationserver:
         client:
           messaging-client:
             registration:
               client-id: "messaging-client"
               client-secret: "{noop}secret"
               client-authentication-methods:
             registration:
               client-id: "messaging-client"
               client-secret: "{noop}secret"
               client-authentication-methods:
                 - "client_secret_basic"
+                - "client_secret_post"
               authorization-grant-types:
                 - "authorization_code"
                 - "refresh_token"
                 - "client_credentials"
  1. Start the default sample server ./gradlew -b samples/default-authorizationserver/samples-default-authorizationserver.gradle bootRun
  2. Execute curl -X POST "http://localhost:9000/oauth2/token?client_id=messaging-client&client_secret=secret&grant_type=client_credentials"

Expected behavior
The specification does not directly say what should be returned in this case.

I would think that one of the following two responses would be reasonable (with a slight preference for 1):

  1. Bad request, to be very specific
HTTP/1.1 400
{
    "error": "invalid_request",
    "error_description": "OAuth 2.0 Parameter: client_id and client_secret not allowed as query parameter",
    "error_uri": "https://datatracker.ietf.org/doc/html/rfc6749#section-5.2"
}
  1. Unauthorized, as credentials are not found in any of the supported/expected ways
HTTP/1.1 401

Further Notes
As far as I understand, this is caused by the usage of OAuth2EndpointUtils.getParameters(request) in

, which calls jakarta.servlet.ServletRequest#getParameterMap, which according to the docs includes both body and query parameters in the returned map.

Request parameters are extra information sent with the request. For HTTP servlets, parameters are contained in the query string or posted form data.

@idotobi idotobi added the type: bug A general bug label Oct 2, 2023
@jgrandja
Copy link
Collaborator

@idotobi client_secret_post is a valid client authentication method option.

As per spec,

In addition to that, the authorization server MAY support including the client credentials in the request content using the following parameters: ...

Including the client credentials in the request content using the two parameters is NOT RECOMMENDED and SHOULD be limited to clients unable to directly utilize the HTTP Basic authentication scheme

Although it's NOT RECOMMENDED, it is a valid option and no where in the spec does it say it's not allowed. It does state...

it SHOULD be limited to clients unable to directly utilize the HTTP Basic authentication scheme

I'm going to close this as client_secret_post is a valid client authentication method option.

@jgrandja jgrandja self-assigned this Oct 11, 2023
@jgrandja jgrandja added status: invalid An issue that we don't feel is valid and removed type: bug A general bug labels Oct 11, 2023
@idotobi
Copy link
Author

idotobi commented Oct 12, 2023

@jgrandja Thank you for your reply.

I know that client_secret_post is a valid authentication method.
However, as far as I understand with client_secret_post the credentials must be passed in the body.
Yet the current implementation of the spring-authorization-server allows to send the credentials via query-parameters and hence in the URI, which the specification explicitly disallows for client_secret_post.

The parameters can only be transmitted in the request content and MUST NOT be included in the request URI.

At least that's how I would understand this sentence.
Please consider to reevaluate your classification of this issue as invalid.

@jgrandja
Copy link
Collaborator

@idotobi Apologies, as I misread your original comment and this issue is valid. Thank you for your persistence 👍

Re-opening and will apply a fix before the release this coming Tue.

@jgrandja jgrandja reopened this Oct 13, 2023
@jgrandja jgrandja added type: bug A general bug and removed status: invalid An issue that we don't feel is valid labels Oct 13, 2023
@jgrandja jgrandja added this to the 0.4.4 milestone Oct 13, 2023
@idotobi
Copy link
Author

idotobi commented Oct 16, 2023

@jgrandja No worries. Glad I could help to improve the project 🙂

Thanks for your work 🙏 !

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type: bug A general bug
Projects
None yet
Development

No branches or pull requests

2 participants