Sandbox authentication fails with invalid_scope

[Michele Mottini]

I created a new confidential client with this allowed scopes:

I use it in a stand-alone launch sequence with scope 'patient/*.read launch/patient'. The sandbox let me login and then select a patient (so it recognized 'launch/patient') but then it redirects back with an invalid_scope error code

Any idea of what could be the problem?

   Thanks

   - Michele

  CareEvolution Inc

[Michele Mottini]

I re-created the confidential client using the quick registration form and now I am not getting the invalid_scope error anymore, but the access token request fails with an invalid_client, 'Bad client credentials' error.

I am passing an authorization header:

Authorization: Basic NzhkMTViZGQtNDZkNS00MTdlLThhY2MtMGFlMWE1ZDUxMTY4OkFNUTFRekM2bWU2YU4xTmtOZ1NZT3JfRTlXOThvakZEbHprYkt4Z1c0U0dHOFQ3Z3dVNTNHd1d5R1hYUGVQdHFoTEJnal93TFV1eGhzOUk1WFFTYjNTdw==

and according to https://www.base64decode.org/ that string decodes to:

78d15bdd-46d5-417e-8acc-0ae1a5d51168:AMQ1QzC6me6aN1NkNgSYOr_E9W98ojFDlzkbKxgW4SGG8T7gwU53GwWyGXXPePtqhLBgj_wLUuxhs9I5XQSb3Sw

that is indeed <client ID>:<client secret>:

Client ID

78d15bdd-46d5-417e-8acc-0ae1a5d51168

Client Secret

AMQ1QzC6me6aN1NkNgSYOr_E9W98ojFDlzkbKxgW4SGG8T7gwU53GwWyGXXPePtqhLBgj_wLUuxhs9I5XQSb3Sw

I tried also to URL-encode the client id and client secret before converting to base 64 but got the same error

Any suggestions?

   - Michele

[Nikolai Schwertner]

Hi Michele,

Earlier this year I added the private client behavior to the SMART JS client.
https://github.com/smart-on-fhir/client-js/commit/abcf36

This is invoked by adding a "secret" parameter to the FHIR.oauth2.authorize for example here
https://github.com/smart-on-fhir/sample-apps/blob/master/standalone/launch.html#L7

Could you try this for comparison against your OAuth client?

Best,
Nikolai

-- 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]

Also, worth pointing out that if you are sending a client secret via the "Authorization" header for your token exchange request, you should NOT include a "client_id" parameter in the body. For some reason MitreID gets confused if your request includes both. Here is a sample client-side logic:

https://github.com/smart-on-fhir/client-js/blob/abcf36cef8784b084f5243e1606104e91eabd7ae/src/client/bb-client.js#L92

[Michele Mottini]

Thanks Nikolai, I think that that is exactly the problem - I am still sending client_id in the body - I'll try to remove it.

(BTW according to the specs client id and client secret should be URL-encoded before being concatenated, your JavaScript code sample does not do that - does MITRE expects URL encoded?)

  - Michele

[Michele Mottini]

...yes, removing client_id from the body fixed the problem, now works fine

(and I realized that URL-encoding for MITRE is moot, the client id and client secret are auto-generated and they do not contain any character that needs encoding)

   Thanks

  - Michele

[Nikolai Schwertner]

Cool.

Yes, no need to urlencode the components of the Authorization header, since they get base64 encoded anyways and never parsed as anything else. The only character that would be of concern is colon (:) but that's not a valid character for either of these strings. So, the documentation example is right http://docs.smarthealthit.org/authorization/basic-auth-example/

[Justin Richer]

To be fully clear and pedantic:

While MITREid explicitly chooses values that don’t need an additional level of encoding, not all server implementations will do so, and any client or client library really needs to do both levels of encoding to be fully spec compliant. This has bitten several implementations in the past that we’ve seen, and even our own client library didn’t always do the URL Encoding and therefore fell apart when talking to a different server implementation.

So even though you don’t *have* to to make it work here, you still should. 

 — Justin

[Michele Mottini]

Thanks

Yes I did - in the client and also in our server, that was not doing it

  - Michele

  CareEvolution Inc 

To unsubscribe from this group and stop receiving emails from it, send an email to smart-on-fhir+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
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-fhir+unsubscribe@googlegroups.com.

[Michele Mottini]

Also, worth pointing out that if you are sending a client secret via the "Authorization" header for your token exchange request, you should NOT include a "client_id" parameter in the body. For some reason MitreID gets confused if your request includes both. Here is a sample client-side logic:

https://github.com/smart-on-fhir/client-js/blob/abcf36cef8784b084f5243e1606104e91eabd7ae/src/client/bb-client.js#L92

...just discovered that the Cerner server DO require the "client_id" parameter in the body when using the "Authorization" header, so client code that works with SMART does not work with Cerner and vice-versa. 

I'd rather avoid having to add a flag to change the behavior depending on the server - any chance of having the two servers accept the same things?

 - Michele

  CareEvolution Inc

[Matt Randall]

Michele,

I'm having my team look into our behavior.  If we're requiring this (client_id when credentials are present) I'd agree that we're out of compliance with RFC 6749 and we'll work to get this corrected quickly. 

Note: technically, under RFC6749 you should be able to include that always, so I don't necessarily want to dissuade the MITREid team from supporting that for RFC compliance, either.

Thanks,

Matt