Bad request 400 when trying to retrieve the Access Token

5,365 views
Skip to first unread message

lgor...@interagy.com

unread,
Jul 2, 2016, 4:49:38 PM7/2/16
to SMART on FHIR
Hi guys,

I'm trying to use the authentication process, but when I make the POST to the app to retrieve the Access Token I'm constantly getting:

org.springframework.web.util.NestedServletException: Request processing failed; nested exception is java.lang.RuntimeException: There was a problem attempting to get the access token.
Response Status : HTTP/1.1 400 Bad Request .
Response Detail :<html>

I'm following the exact details explained here (content type, header credentials encryption, params):

http://docs.smarthealthit.org/authorization/

Have you ever experienced something like this?

Thanks in advance


Josh Mandel

unread,
Jul 2, 2016, 5:03:46 PM7/2/16
to lgor...@interagy.com, SMART on FHIR
Have you registered a confidential client, or a public client? Could you share an example of a complete request you're making, including headers?

--
You received this message because you are subscribed to the Google Groups "SMART on FHIR" group.
To unsubscribe from this group and stop receiving emails from it, send an email to smart-on-fhi...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Nikolai Schwertner

unread,
Jul 2, 2016, 5:05:05 PM7/2/16
to smart-...@googlegroups.com
I assume that you are asking about the token exchange step of the authorization process (against the authorization server). Could you share your POST request (header and body)?

Leonardo Gorbliuk

unread,
Jul 2, 2016, 5:28:44 PM7/2/16
to Josh Mandel, SMART on FHIR
Hi Josh,

Thanks for your quick reply.

Its a confidential client, and the sample request is described below:

Headers:
  "Content-Type" => "application/x-www-form-urlencoded"
  "Authorization" => "MmQyNGVjNjAtYzM4Y...." (continues)
Encrypted params:
  grant_type=authorization_code
  redirect_uri=http://localhost:8080/localfhir/launch/redirect
  code=ghYbey
 
Maybe its worth mentioning that this same example used to work a few months ago.
--


Ing. Leonardo Gorbliuk
Eduardo Acevedo 561 - 1°F
(1405) Ciudad de Buenos Aires, Argentina
Tel:  +54 (11) 3529-6328
www.interagy.com

Josh Mandel

unread,
Jul 2, 2016, 5:50:10 PM7/2/16
to Leonardo Gorbliuk, SMART on FHIR
Your authorization header should begin with "Basic " -- perhaps really does and you've just mis-summarized here?

Leonardo Gorbliuk

unread,
Jul 2, 2016, 6:25:49 PM7/2/16
to Josh Mandel, SMART on FHIR
Oh yes, you're right.

I cut that part from the example, but its there and its being sent.

Josh Mandel

unread,
Jul 2, 2016, 6:35:12 PM7/2/16
to Leonardo Gorbliuk, SMART on FHIR
Can you clarify what you mean by "encrypted params"?

Also: hmm, I just googled the phrase from your error message ("here was a problem attempting to get the access token.") and it appears to be coming from this library -- is that Java library the one you're using to connect to our server? It looks like this library is cutting off the error message and printing out only a single string ("<html>"). Can you try fixing this to provide a complete error response and see if that reveals anything about what might be going wrong?

-J

Leonardo Gorbliuk

unread,
Jul 2, 2016, 8:02:06 PM7/2/16
to Josh Mandel, SMART on FHIR
Hi Josh,

Yes, it is the library I'm using, and instead of "encrypted" I meant "encoded":

postRequest.setEntity(new UrlEncodedFormEntity(transferParams));

where transferParams contains the values described on the mail above.

The entire response is:

<html>
<head><title>400 Bad Request</title></head>
<body bgcolor="white">
<center><h1>400 Bad Request</h1></center>
<hr><center>nginx/1.8.1</center>
</body>
</html>

So I guess is not much of a help...

Josh Mandel

unread,
Jul 2, 2016, 8:43:57 PM7/2/16
to Leonardo Gorbliuk, SMART on FHIR
Well, that information is actually interesting -- it shows that your error is coming from the reverse proxy (nginx) that sits in front of our authorization server, rather than the authorization server itself. That suggests there's something malformed about your request itself. I can't reproduce this behavior when I try to mimic the request you shared earlier in this thread (given the headers and body you listed). With a very long header, I can trigger an error from nginx like "400 Request Header Or Cookie Too Large" (this is not a bug; you shouldn't be sending very long headers to our authorization sever) -- but your error doesn't have such a useful hint. Is it possible you're sending different values from what you've listed here?

  -J

Leonardo Gorbliuk

unread,
Jul 9, 2016, 11:15:56 AM7/9/16
to Josh Mandel, SMART on FHIR
Hi Josh,

Thanks for your reply. And sorry for the delay on the tests.

As you predicted, the problem was exactly the length of the "Authentication" header, since changing removing it or changing its value makes the request hit the server and throw the corresponding error (missing authentication or invalid code).

The problem is that SMART its what gives me the clientId (36 characters) and clientSecret (86 characters) when I register my application, so the encoded result (according to http://docs.smarthealthit.org/authorization/basic-auth-example/) is long enough to exceed the server's limit.

Is there anything I can do on my side to overcome this?

Thanks again.

Josh Mandel

unread,
Jul 9, 2016, 11:20:34 AM7/9/16
to Leonardo Gorbliuk, SMART on FHIR

Thanks for the follow-up. Could you perhaps share a complete breaking example of an http requests that you're making? E.g. if you could demonstrate the issue with a "curl" command that would probably help us to debug.

Best,

Josh

Leonardo Gorbliuk

unread,
Jul 9, 2016, 11:49:10 AM7/9/16
to Josh Mandel, SMART on FHIR
Hi Josh,

This is really strange, when I emulate the call via curl it works as expected (described below). So now it looks more of a Java Client issue than an issue with the server.

Since it is an existing client, I will continue taking a look at my side to see what might be happening, since the length of the header now does not look like the cause (and I guess it is expected, as it says bad format, not exceeded length).

Thanks for all your help.

curl -d "grant_type=authorization_code&redirect_uri=http://localhost:8080/APP/launch/redirect&code=TmKoIV" https://authorize-dstu2.smarthealthit.org/token --header "Authorization:Basic MmQyNGVjNjAtYzM4YS00MjhhLTg1ODUtZTBjMmIwMmNjOWQ0OkN6LUcyekZUaDNnWlpLUURrd2tyMDQ3bjVFMTVsd3FPc3Q5QXBCMVd6TW5RV0hFTjRCd29NTXd4dURqX21rd2hNb1czakdUdjdmclR5WXZwZkpFT2NR"


Leonardo Gorbliuk

unread,
Jul 17, 2016, 12:02:28 PM7/17/16
to Josh Mandel, SMART on FHIR
Hi All,

To wrap this up: the problem was caused by the "com.sun.org.apache.xerces.internal.impl.dv.util.Base64" class when trying to encode a byte array. In some contexts (were not able to specify which) it cut the encoded String by adding some line break characters on the result ("/n"). So the problem was solved by replacing this library with the org.apache.commons.codec.binary.Base64 one.

Thanks for your help to figure this out.

Regards,

kko...@gmail.com

unread,
Mar 24, 2017, 5:30:05 PM3/24/17
to SMART on FHIR, jma...@gmail.com
Hi Josh,

I have the same error, but don't think the resolution is the same.  While using the App to authorize, I get 'Bad Request' error from the server. I can't dig more into the message as my app is using simple-oauth library and is deployed as a cloud function (no way to trace network traffic). In any case, I did try CURL  as follows - 

curl -d "grant_type=authorization_code&redirect_uri=http://localhost:4200/login&code=yMQ6wO" https://authorize-dstu2.smarthealthit.org/token --header "Authorization:Basic ZmFmNWFkMGEtNDhk..." and get a different error - 

{"error":"invalid_client","error_description":"Client with id faf5ad0a-48db-4bd4-a969-2bbca8a7d9ac was not found"}


The client ID is correct. So I'm not sure where things are going wrong.

Thanks for your help.

_K

kko...@gmail.com

unread,
Mar 24, 2017, 5:36:28 PM3/24/17
to SMART on FHIR, jma...@gmail.com
Sorry - Just realized that I'm using the wrong auth server uri in the CURL request. With the correct one though, the error is  - 

curl -d "grant_type=authorization_code&redirect_uri=http://localhost:4200/login&code=t8EjQc" https://sb-auth.smarthealthit.org/auth/token --header "Authorization:Basic ZmFmNWFkMGEtNDhkYi00YmQ0L...."

{"error":"invalid_grant","error_description":"JpaAuthorizationCodeRepository: no authorization code found for value t8EjQc"}


Thanks.
Reply all
Reply to author
Forward
0 new messages