I've recently been trying to use the OAuth2CodeGrantFlow to get a token from the JetBrains Hub application (using Hub as my OAuth2 provider).
I'm able to start the auth request and get a code and state from them but when I try to finish the request, I'm rejected with a 401.
Looking into their issue tracker a bit, I see that someone else reported a similar issue:
About midway down that thread, there's a report that someone received the following while requesting the token in php:
"error" => "invalid_client"
The folks at Jetbrains then said that the OAuth2 standard requires that there is an Authorization header with the service id, service secret and auth code passed with the token request. I'm not particularly familiar with the OAuth2 standard, but they include some links to the standard.
Their claim is that sending the auth code as form params, while currently accepted by Google, is not OAuth2 compliant.
I believe that Jersey is sending the auth code as form params and not an auth header.
Is it possible to finish the OAuth2 token request the way that they describe with the current library?
which step of the authorization are you talking about?
Auth request: https://tools.ietf.org/html/rfc6749#section-4.1.1
The client constructs the request URI by adding the following parameters to the query component of the authorization endpoint URI using the "application/x-www-form-urlencoded" format, per Appendix B:
Jersey is doing that, see AuthCodeGrantImpl#start() // returns creates the uri which you should present to the user
Access token request: https://tools.ietf.org/html/rfc6749#section-4.1.3
The client makes a request to the token endpoint by sending the following parameters using the "application/x-www-form-urlencoded" format per Appendix B with a character encoding of UTF-8 in the HTTP request entity-body:
Jersey is doing that, see AuthCodeGrantImpl#finish() // puts the parameters into the entity as a form, exactly as written above.
Looking further, I see Jetbrains guys might be correct: https://tools.ietf.org/html/rfc6749#section-3.2.1
A client MAY use the "client_id" request parameter to identify itself when sending requests to the token endpoint. In the "authorization_code" "grant_type" request to the token endpoint, an unauthenticated client MUST send its "client_id" to prevent itself from inadvertently accepting a code intended for a client with a different "client_id". This protects the client from substitution of the authentication code. (It provides no additional security for the protected resource.)
Anyway, you should be able to do that by supplying the client instance when building Jersey OAuth flow and add that header by yourself when needed.. not a nice way, but should work..
.. feel free to file a bug / improvement request and ideally pull request as well :-)
On 22/02/16 03:52, Matthew Ulrich wrote:
Alright - thanks for the feedback.
As you mentioned in your reply, I'm talking about the #finish.
I picked up the source; I'll try and compile a useful pull request.
On Mon, Feb 22, 2016 at 4:01 AM, Pavel Bucek <[hidden email]> wrote:
|Free forum by Nabble||Edit this page|