users@jersey.java.net

[Jersey] Re: OAuth2CodeGrantFlow Authorization Headers on access_token request

From: Pavel Bucek <pavel.bucek_at_oracle.com>
Date: Mon, 22 Feb 2016 10:01:38 +0100

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, perAppendix 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 perAppendix 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