OAuth2CodeGrantFlow Authorization Headers on access_token request

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

OAuth2CodeGrantFlow Authorization Headers on access_token request

Matthew Ulrich
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:


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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: OAuth2CodeGrantFlow Authorization Headers on access_token request

Pavel Bucek-2
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:

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 :-)

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:


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

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: OAuth2CodeGrantFlow Authorization Headers on access_token request

Matthew Ulrich
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 <[hidden email]> 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:

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 :-)

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:


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


Loading...