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.
Matty
On Mon, Feb 22, 2016 at 4:01 AM, Pavel Bucek <pavel.bucek_at_oracle.com> wrote:
> Hi Matthew,
>
> which step of the authorization are you talking about?
>
> btw:
>
> 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 <https://tools.ietf.org/html/rfc6749#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 <https://tools.ietf.org/html/rfc6749#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 :-)
>
> Regards,
> Pavel
>
>
> On 22/02/16 03:52, Matthew Ulrich wrote:
>
> Hello all,
>
> 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:
>
> https://youtrack.jetbrains.com/issue/JPS-3030
>
> About midway down that thread, there's a report that someone received the
> following while requesting the token in php:
>
> "error" => "invalid_client" "error_code" => 401 "error_description" => "Authorization header was not passed"
>
>
> 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?
>
> Thanks,
>
> Matty
>
>
>