not allowed any of the scopes specified

[Lucas Manning]

Hi,

I'm getting this error: 

(app) is not allowed to request any of the scopes specifed

Correlation ID: 7a96e8d8-5715-4bf9-82ee-4264749f8cc2

while attempting to authorize.

I'm making a GET request to the endpoint:

https://authorization.sandboxcerner.com/tenants/0b8a0111-e8e6-4c26-a91c-5069cbc6b1ca/protocols/oauth2/profiles/smart-v1/personas/patient/authorize

with the parameters:

.

client_id=<my client id>

response_type=code

redirect_uri=<my app domain uriencoded>

scope=patient/Observation.read -- urlencoded

aud=https%3A%2F%2Ffhir-ehr.sandboxcerner.com%2Fdstu2%2F0b8a0111-e8e6-4c26-a91c-5069cbc6b1ca

Does anyone have any idea why this would be happening/what I am doing wrong?

Thanks.

[Lucas Manning]

my client id is 4be6ff72-a31b-4205-930c-26b8dbbf9278

[Jenni Syed (Cerner)]

Hi Lucas,

Any patient/* scope would require the authorization server to know the patient in context, which would require a SMART launch or launch/patient scope to be requested. If you add launch/patient to the list of scopes requested, then patient/Observation.read would be a valid scope to request.

You'll also need to modify your application to have that scope granted (it's not in the current list of scopes for your app). That change will take about 15 minutes to reflect in the authorization server.

~ Jenni

[Lucas Manning]

OK. Thanks for the response.  Though I am confused why I still get the same error when my scope just has user/Observation.read? Could you explain this? Thank you again.

[Jenni Syed (Cerner)]

Lucas,

Can you double-check the correlation id above? That error was not related to scopes requested, but instead was an invalid client id (and there were a few other issues with the request). I

So I can double-check, can you give me the correlation id for the request for user/Observation.read?

~ Jenni

[Lucas Manning]

this is the correlation id: b65c370e-ae30-4d5e-aeb8-1243e3df97ff

[Lucas Manning]

Here is where the redirect goes.

[Jenni Syed (Cerner)]

It looks like there are a few things going on (I looked through all the requests for this client id since the correlation you sent). When I address all the issues below, I am able to get the application to authorize successfully. 

• The specific correlation from above is still requesting patient/Observation.read but no launch scope, which is an invalid request.
• I do see some successful requests late last night, and when I use a url that addresses the issues below, I wind up at a login page for the application (authorization is success)
• The app should use the conformance (/metadata) endpoint to discover the token and authorization endpoints, then pass in the URL of the same FHIR server in to the authorization server as the aud parameter. Right now, the app is calling the authorization for a patient, but passing in the practitioner FHIR server URL. See details here: http://fhir.cerner.com/authorization/#requesting-authorization-on-behalf-of-a-user
  
• The app is now requesting patient/launch (which it doesn't have access to yet - you'll need to modify your application).
• Sometimes the parameter values are not being URL encoded before passed in. IE: they're coming in as user/Condition.read instead of user%2FCondition.read or https://fhir-... instead of https%253A%252F%252Ffhir-... (scopes, redirect, aud). This seems to vary in the calls I see - sometimes the params are encoded and sometimes they're not. I think some of the encoded examples may be coming from curl
• Many recent examples are passing in a "grant_type" parameter set to "authorization_code", along with the correct parameter "response_type" param equal to "code". See examples here: http://fhir.cerner.com/authorization/#examples The app doesn't need to send in a "grant_type" parameter for authorization.
• Don't forget to set a state parameter for security. http://fhir.cerner.com/authorization/#state  There's a "stata" param in the examples, but it's being ignored since that's not a valid param

~ Jenni

[Lucas Manning]

OK thanks. I was just testing a lot last night to see if anything would work. Maybe if I explain my use case a little you can help me solve my problem. I have a standalone web app that is provider facing. The provider must be able to choose a patient and view all the data. Originally I had my calls to the auth endpoints on my server side, but I see why that cannot work. Now, when I put the call to the auth endpoints on the client side, I get a response that I cannot process because there are "no access control allow origin" header. from my understanding, the response I get would otherwise take me to a login screen. My second question is: what credentials could i use to test that login? 

Thank you.

[Jenni Syed (Cerner)]

Hi Lucas,

You'll want to build your application as a provider application, not patient (you'll have doctors sign in, not patients). You have the correct FHIR URL for that, but are using an incorrect authorization URL. The FHIR URL should start with fhir-ehr. See: http://fhir.cerner.com/millennium/dstu2/#secure-sandbox

We do not allow the launch/patient scope for providers, and your application won't be able to use the launch scope either, since it's standalone. Your application will need to use all user/* scopes since the authorization server will not have context of the patient being acted upon. Also, your application would need to implement patient search using our Patient resource. Ideally, we would support launch/patient for provider, but the workflow above would allow your app to function in absence of that support.

The ACAO issue is interesting - we do support CORS, but it requires that the CORS headers the browser sends are in place. Since this is browser-side, have you tried opening developer tools to see what is being sent and returned from the calls the javascript is making? Are you using the fhir-client.js library, as mentioned here (so you don't need to write your own OAuth/SMART)? Also, while the authorize URL needs to be made in a browser for the user to enter credentials, there's nothing that would prevent the token call from happening server-side.

Credentials are documented in the code console for providers (portal/portal). Right now, your application is hitting the patient sign in, so those credentials won't work. If the app uses the token and authorize endpoints from the FHIR metadata, you'll be sent to the provider sign in page.

~ Jenni