Secure Sandbox System Account Auth

248 views
Skip to first unread message

Daniel Dean

unread,
Feb 21, 2023, 10:57:20 AM2/21/23
to Oracle Cerner FHIR Developers
Hello all,

I have an app registered here

And it is associated with a limited system account registered here

I have followed the documentation here:

But my attempts to authorize using the provided information gives me "invalid client".   Similar to this thread here:

However,
The user in that thread was able to correct the issue by registering an app, which I have already done but I still receive "invalid client".  Just to be clear, as with the thread above, this is the syntax I'm using, of course obfuscating $client and $secret:

curl --http1.1 -X POST 'https://authorization.cerner.com/tenants/ec2458f2-1e24-41c8-b71b-0e701af7583d/protocols/oauth2/profiles/smart-v1/token' \
  -H 'Accept: application/json' \
  -H "Authorization: Basic $(echo -n $client:$secret | base64)" \
  -H 'Content-Type: application/x-www-form-urlencoded' \
  -H 'cache-control: no-cache' \
  -d 'grant_type=client_credentials&scope=system%2FObservation.read%20system%2FPatient.read'

and the response I get is :


What am I missing?  Do I need to be granted explicit access to a context?

Thanks in advance.

Andrew Fagan (Cerner)

unread,
Feb 27, 2023, 1:29:34 PM2/27/23
to Oracle Cerner FHIR Developers
Hello Dan,

I believe the root of the issue you are experiencing is attempting to cross an application registered in a lower domain(sandboxcerner.com vs cerner.com) and attempting to access production auth and developer domain.

I apologize for the confusion.  You will need to register your application in the production code console: https://code-console.cerner.com/ and use that newly registered app in the workflow. (The site/system account you linked was from sanboxcerner.com instead of just cerner.com)

You will not need to pre-register for a system account.  It will be generated for you with app registration.  You may also need to create a new cerner care account as the lower domain code-console is tied to lower domain cerner care.

Thank you,

Andrew

Daniel Dean

unread,
Feb 27, 2023, 2:05:35 PM2/27/23
to Oracle Cerner FHIR Developers
Hi Andrew, thanks for the reply.  It's my understanding that we need to get our application running and tested in the sandbox before becoming approved to run in the main cerner domain.  My intent was to authorize within the sandbox environment, and if I got the endpoint wrong there, could you provide the correct endpoint?  For clarification, the secure sandbox is intended for external application developers, correct?  If I were to attempt to authorize and make API calls thru the main cerner.com domain, wouldn't I be interacting with live customer data?  

Thanks 

Andrew Fagan (Cerner)

unread,
Feb 27, 2023, 2:18:07 PM2/27/23
to Oracle Cerner FHIR Developers
We have overloaded terms that has partially contributed to the confusion.   There are two uses of sandbox.  There is the developer sandbox (which is actually a production millennium domain) which is used for developers testing their integrations with Oracle Cerner and the "sandbox" environment which is a lower tier domain. 

When you are directed to the developer sandbox, you should be registering your application here: https://code-console.cerner.com/  to testing against the developer sandbox millennium domain: https://fhir-ehr.cerner.com/r4/ec2458f2-1e24-41c8-b71b-0e701af7583d/ .  

Thank you, 

Andrew

Andrew Fagan (Cerner)

unread,
Feb 27, 2023, 2:18:15 PM2/27/23
to Oracle Cerner FHIR Developers
We have overloaded terms that has partially contributed to the confusion.   There are two uses of sandbox.  There is the developer sandbox (which is actually a production millennium domain) which is used for developers testing their integrations with Oracle Cerner and the "sandbox" environment which is a lower tier domain. 

When you are directed to the developer sandbox, you should be registering your application here: https://code-console.cerner.com/  to testing against the developer sandbox millennium domain: https://fhir-ehr.cerner.com/r4/ec2458f2-1e24-41c8-b71b-0e701af7583d/ .  

Thank you, 

Andrew



On Monday, February 27, 2023 at 1:05:35 PM UTC-6 dan...@docresponse.com wrote:

Daniel Dean

unread,
Feb 27, 2023, 3:21:32 PM2/27/23
to Oracle Cerner FHIR Developers
Ok, is the authorization endpoint still correct?  Or do I need to authenticate against a different domain?  I've been using this one:


I have tried this with both sandbox and production credentials, with the same "invalid_client" result:

curl --http1.1 -X POST 'https://authorization.sandboxcerner.com/tenants/ec2458f2-1e24-41c8-b71b-0e701af7583d/protocols/oauth2/profiles/smart-v1/token'   -H 'Accept: application/json'   -H "Authorization: Basic $(echo -n $client:$secret | base64)"   -H 'Content-Type: application/x-www-form-urlencoded'   -H 'cache-control: no-cache'   -d 'grant_type=client_credentials&client_id=scope=system%2FObservation.read%20system%2FPatient.read'



Thanks

Mintu Moni Kurmi

unread,
Feb 28, 2023, 2:49:29 AM2/28/23
to Oracle Cerner FHIR Developers
I am too facing the same issue. I have registered system apps in both (code-console.cerner.comcode-console.sandboxcerner.com) for using the bulk data API. But before that, I need to authenticate and get the Auth token. 
I have been hitting on this endpoint (https://authorization.cerner.com/tenants/ec2458f2-1e24-41c8-b71b-0e701af7583d/protocols/oauth2/profiles/smart-v1/token) with the appropriate credentials from the system account from both of the environments. But I have always got the same invalid_client error. 

This is the error message "The credentials used in the client_credentials grant were invalid"

Correlation ID:
a96c247a-17e1-4317-9d6e-692b538a5638


Please help.

Daniel Dean

unread,
Feb 28, 2023, 11:06:05 AM2/28/23
to Oracle Cerner FHIR Developers
So I was able to get an access token by implementing the authorization in code.  Comparing the verbose log from call from a bash curl vs the one I ran from code, the issue looks like the base64 string produced from $(echo -n $client:$secret | base64) actually produces some extra characters at the end of the Authorization: header.  From my script approach, the base64 string is 76 characters, while the one generated from the bash curl attempt was 92 characters, so the way that base64 command is being called is messing up the authentication string.  

Hope this helps.
Reply all
Reply to author
Forward
0 new messages