client_id and client_secret sent via param vs in url

Question

I'm having some problems with my Oauth2 server (Spring) when trying to access some protected endpoints.

If I want to get a token (via Zuul gateway), I'd do something like this:

http://localhost:4444/auth/oauth/token?client_id=gateway&client_secret=1234&grant_type=password&username=user&password=password

(Asume above client and user exist correctly and the Content-Type being application/x-www-form-urlencoded).

This call doesn't work, but, if I do it like this:

gateway:1234@localhost:4444/auth/oauth/token?grant_type=password&username=user&password=password

Then, it works.

Is this considered normal behavior? As far as I could read, this should work. It's like the id and the secret are not being handled when I sent those as params but when I modify the url, the it's taken and everything works. Do I need implement something extra?

To clarify, the Oauth2 server works when I send the client_id and the client_secret like in the second url but if I send those as params (first url), it doesn't.

You can check the code here (OAuth2-service): https://github.com/otamega93/CloudBasedUserRegistration2/tree/master/OAuth2-service

The configuration is mostly at OAuth2Configuration, WebSecurityConfig and AuthServerApplication. I'm testing with Postman. This also happens when I access directly the Oauth2 server.

Answer 1

The token endpoint (oauth/token) is protected, see TokenEndpoint:

Clients must be authenticated using a Spring Security Authentication to access this endpoint, and the client id is extracted from the authentication token. The best way to arrange this (as per the OAuth2 spec) is to use HTTP basic authentication for this endpoint with standard Spring Security support.

and see OAuth 2 Developers Guide:

The token endpoint is protected for you by default by Spring OAuth in the @Configuration support using HTTP Basic authentication of the client secret. This is not the case in XML (so it should be protected explicitly).

The client has to authenticate itself with Basic authentication scheme, therefore the client has to add an Authorization header to the request, see RFC 2617:

To receive authorization, the client sends the userid and password, separated by a single colon (":") character, within a base64 [7] encoded string in the credentials.

 basic-credentials = base64-user-pass
 base64-user-pass  = <base64 [4] encoding of user-pass,
                     except not limited to 76 char/line>
 user-pass   = userid ":" password
 userid      = *<TEXT excluding ":">
 password    = *TEXT

Userids might be case sensitive.

If the user agent wishes to send the userid "Aladdin" and password "open sesame", it would use the following header field:

 Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==

Your first request contains no Authorization header.

Your second request contains a URL with a "userinfo" subcompontent, see RFC 3986:

The userinfo subcomponent may consist of a user name and, optionally, scheme-specific information about how to gain authorization to access the resource. The user information, if present, is followed by a commercial at-sign ("@") that delimits it from the host.