OAuth state and url parameter encoding

[Don DeCoteau]

It appears that ' https://fhir-dstu2.smarthealthit.org/#/after-auth' does no re-encode the url parameters and that 'https://authorize-dstu2.smarthealthit.org/authorize' is being called with un-encoded parameters.

If the state value contains a special url encoding character that character is returned decoded. Specifically, if I send a state value that has a '+' that is properly encoded as '%2B' I get back a space instead of the '+' on a redirect.

[Josh Mandel]

Thanks Don for this report. Can you clarify exactly when you're seeing this bug? That is, are you seeing this when trying to authorize your own app (and also requesting a scope like "patient/launch", which involves our patient selector)?

Best,

Josh

On Jan 19, 2016 13:32, "Don DeCoteau" <spars...@gmail.com> wrote:

It appears that ' https://fhir-dstu2.smarthealthit.org/#/after-auth' does no re-encode the url parameters and that 'https://authorize-dstu2.smarthealthit.org/authorize' is being called with un-encoded parameters.

If the state value contains a special url encoding character that character is returned decoded. Specifically, if I send a state value that has a '+' that is properly encoded as '%2B' I get back a space instead of the '+' on a redirect.

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

[Don DeCoteau]

I am attempting to authorize my app with a patient/launch scope. The app authorizes and I get the patient selection screen. When I select a patient I get a redirect with the bad state. If I change the state to be a simple hex string then everything works fine. Looking at a log of the browser redirects shows that  https://authorize-dstu2.smarthealthit.org/authorize receives the query parameters un-encoded.

So, when it decodes those parameters, it will cause the state value (or any other value) to be altered if it contains any special url encoding characters like a '+'. I was using a base64 encoding on the state value and '+' is a valid base64 encoding character.

[O'Keefe, Michael C]

We ran into a similar problem when authorizing to the SMART server. It turns out RFC 4648 (https://tools.ietf.org/html/rfc4648), which describes Base 64 encoding, specifies several different alphabets for Base 64 encoding, depending on the intended use. We switched to using a base 64 encoding function (Base64. urlsafe_encode64 in Ruby) which uses the URL-safe alphabet defined in the RFC, which excludes values such as "+" and "/" that cannot be url encoded . Your language may have something similar.

— 

Michael O’Keefe

mok...@mitre.org

Software Systems Engineer, Sr.

K84C, Open Health Services

--

[Josh Mandel]

Thanks for this report Don. We're able to reproduce this error, and it turns out the issue occurs even without using our fancy redirect-to-patient-selection. It appears to be fixed in the current version of MITREid, which we're looking at upgrading to as we update our reference stack. In the meantime, are you able to work around this bug, or is this blocking your work?

Regarding Michael's comment about base64 encoding: we're not using base64 encoding in this process to stick data into URLs, so that's not quite the issue. We're just using URL encoding. 

Best,

  Josh

[Justin Richer]

In older versions of MITREid there were a few places that weren’t using proper URL builders, but instead were stitching together URLs by hand. We think we’ve fixed all of these in the current version now.

 — Justin

[Josh Mandel]

Thanks Justin! Yes, I've confirmed that this particular issue is fixed in the current https://mitreid.org .

[Don DeCoteau]

Thanks, I am able to work around.