OAuth2 Issues when Requesting Authorization on Behalf of a System. Error: unsupported_grant_type

287 views
Skip to first unread message
Assigned to aaron....@oracle.com by me

Chris Kavan

unread,
Jan 20, 2021, 5:47:37 PM1/20/21
to Cerner FHIR Developers
I am attempting to Request Authorization on Behalf of a System, but continue to get "error": "unsupported_grant_type".

I see that this topic has come up regularly and attempted to follow any steps listed in the conversations I found, but am still getting these errors.

In the body, I've specified grant_type=client_credentials&scope=system%2FObservation.read%20system%2FPatient.read (mimicking the example from the authorization documentation). I've tried this from a "Provider" app and with a "System" app. I linked the Client ID with the System app and verified that the app's System Scopes include those I'm requesting. I've tried this from curl and Postman, but have not been successful.
headers.png
body.png

Jenni Syed (Cerner)

unread,
Jan 21, 2021, 10:01:07 AM1/21/21
to Cerner FHIR Developers
Chris,

To remove any configuration issues in Postman, can you try with the example curl statement in the documentation and see what response you receive?


Regards,
Jenni

Chris Kavan

unread,
Jan 21, 2021, 5:12:26 PM1/21/21
to Cerner FHIR Developers
When I test with curl with the linked example, I get an invalid_client error:

Expect-CT: enforce, max-age=30

WWW-Authenticate: Basic realm="CernerCare"

Access-Control-Allow-Origin: *

Access-Control-Allow-Methods: OPTIONS, POST

Access-Control-Allow-Headers: Content-Type, Authorization, Accept, Cerner-Correlation-Id

Cache-Control: no-store

Pragma: no-cache

Cerner-Correlation-ID: d7edfa4b-c18e-4b57-99bc-20f9c1ae6946

Content-Type: application/json;charset=UTF-8

Content-Length: 276

Date: Thu, 21 Jan 2021 21:45:14 GMT

Server: cloud_authorization_server1

Strict-Transport-Security: max-age=631138519; includeSubDomains

{
  "error": "invalid_client",
}

When I specify the Base64-encoded $SYSTEM_ACCOUNT_CLIENT_ID:$SYSTEM_ACCOUNT_CLIENT_SECRET manually, I also get an invalid_client error:

Expect-CT: enforce, max-age=30

WWW-Authenticate: Basic realm="CernerCare"

Access-Control-Allow-Origin: *

Access-Control-Allow-Methods: OPTIONS, POST

Access-Control-Allow-Headers: Content-Type, Authorization, Accept, Cerner-Correlation-Id

Cache-Control: no-store

Pragma: no-cache

Cerner-Correlation-ID: 9313675d-252c-4b6c-a8e6-fdc641596a10

Content-Type: application/json;charset=UTF-8

Content-Length: 276

Date: Thu, 21 Jan 2021 21:47:20 GMT

Server: cloud_authorization_server1

Strict-Transport-Security: max-age=631138519; includeSubDomains

{

  "error": "invalid_client",

  "error_uri": "https://authorization.cerner.com/errors/urn%3Acerner%3Aerror%3Aauthorization-server%3Aoauth2%3Atoken%3Ainvalid-client-credentials/instances/9313675d-252c-4b6c-a8e6-fdc641596a10?client=unknown&tenant=ec2458f2-1e24-41c8-b71b-0e701af7583d"

}

Sanitized output from verbose mode included below:

chriskavan@Chriss-MacBook-Pro ~ % curl -v -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 ##REDACTED##" \

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

Note: Unnecessary use of -X or --request, POST is already inferred.

*   Trying 159.140.206.14...

* TCP_NODELAY set

* Connected to authorization.cerner.com (159.140.206.14) port 443 (#0)

* ALPN, offering h2

* ALPN, offering http/1.1

* successfully set certificate verify locations:

*   CAfile: /etc/ssl/cert.pem

  CApath: none

* TLSv1.2 (OUT), TLS handshake, Client hello (1):

* TLSv1.2 (IN), TLS handshake, Server hello (2):

* TLSv1.2 (IN), TLS handshake, Certificate (11):

* TLSv1.2 (IN), TLS handshake, Server key exchange (12):

* TLSv1.2 (IN), TLS handshake, Server finished (14):

* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):

* TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1):

* TLSv1.2 (OUT), TLS handshake, Finished (20):

* TLSv1.2 (IN), TLS change cipher, Change cipher spec (1):

* TLSv1.2 (IN), TLS handshake, Finished (20):

* SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384

* ALPN, server did not agree to a protocol

* Server certificate:

*  subject: C=US; ST=Missouri; L=Kansas City; jurisdictionCountryName=US; jurisdictionStateOrProvinceName=Delaware; O=Cerner Corporation; businessCategory=Private Organization; serialNumber=2103665; CN=authorization.cerner.com

*  start date: Mar 11 17:27:37 2020 GMT

*  expire date: Mar 11 17:57:36 2022 GMT

*  subjectAltName: host "authorization.cerner.com" matched cert's "authorization.cerner.com"

*  issuer: C=US; O=Entrust, Inc.; OU=See www.entrust.net/legal-terms; OU=(c) 2014 Entrust, Inc. - for authorized use only; CN=Entrust Certification Authority - L1M

*  SSL certificate verify ok.

> POST /tenants/ec2458f2-1e24-41c8-b71b-0e701af7583d/protocols/oauth2/profiles/smart-v1/token HTTP/1.1

> Host: authorization.cerner.com

> User-Agent: curl/7.64.1

> Accept: application/json

> Authorization: Basic ##REDACTED##

> Content-Type: application/x-www-form-urlencoded

> cache-control: no-cache

> Content-Length: 85

> 

* upload completely sent off: 85 out of 85 bytes

< HTTP/1.1 401 

< Expect-CT: enforce, max-age=30

< WWW-Authenticate: Basic realm="CernerCare"

< Access-Control-Allow-Origin: *

< Access-Control-Allow-Methods: OPTIONS, POST

< Access-Control-Allow-Headers: Content-Type, Authorization, Accept, Cerner-Correlation-Id

< Cache-Control: no-store

< Pragma: no-cache

< Cerner-Correlation-ID: e72ed0ab-4d80-4063-b7c3-3ffa75f2a7e7

< Content-Type: application/json;charset=UTF-8

< Content-Length: 276

< Date: Thu, 21 Jan 2021 22:01:01 GMT

< Server: cloud_authorization_server1

< Strict-Transport-Security: max-age=631138519; includeSubDomains

< 

* Connection #0 to host authorization.cerner.com left intact

{"error":"invalid_client","error_uri":"https://authorization.cerner.com/errors/urn%3Acerner%3Aerror%3Aauthorization-server%3Aoauth2%3Atoken%3Ainvalid-client-credentials/instances/e72ed0ab-4d80-4063-b7c3-3ffa75f2a7e7?client=unknown&tenant=ec2458f2-1e24-41c8-b71b-0e701af7583d"}* Closing connection 0 


Aaron McGinn (Cerner)

unread,
Jan 21, 2021, 5:24:48 PM1/21/21
to Cerner FHIR Developers
The "invalid-client-credentials" indicates that the secret you are providing for your system account is not correct. You can verify (and rotate if needed) the secret in CernerCentral [1].


-Aaron (Cerner)

Chris Kavan

unread,
Jan 21, 2021, 5:41:03 PM1/21/21
to Cerner FHIR Developers
Do I need to use an account in https://cernercentral.com/system-accounts/ or is the account I created in https://sandboxcernercentral.com/system-accounts/ usable?

Aaron McGinn (Cerner)

unread,
Jan 21, 2021, 7:43:01 PM1/21/21
to Cerner FHIR Developers
For the current public sandbox (ec2458f2-1e24-41c8-b71b-0e701af7583d), you will use the cernercentral.com link. The previous domain was in sandboxcernercentral.com, but that account will still be used for client non-production domains.

-Aaron (Cerner)

Chris Kavan

unread,
Jan 22, 2021, 2:53:29 PM1/22/21
to Cerner FHIR Developers
Thanks, Aaron. Don't know how I misread the documentation on this one. 

I submitted a request in CernerCentral this morning. Do you know what kind of turnaround time I can expect for the request to be approved?

Aaron McGinn (Cerner)

unread,
Jan 22, 2021, 2:56:29 PM1/22/21
to Cerner FHIR Developers
It usually takes 2-3 business days for the approval to go through. For reference, here [1] is where our original announcement of the migration was made last year.


-Aaron (Cerner)

Chris Kavan

unread,
Jan 27, 2021, 4:18:56 PM1/27/21
to Cerner FHIR Developers
Everything's working now.

Recap of happy path for posterity:
  1. Requested system account here per the Registering a System Account instructions morning of 2021-01-22
  2. Account was authorized with "Created On" of 2021-01-27 6:19:26 AM GMT-0600. 
  3. Created secret.
  4. Created new system app, specifying Account ID from #2 as System GUID.
  5. Initially I received "error":"invalid_client" errors. But after ~10-20 minutes I was able to successfully request authorization on behalf of a system.
Reply all
Reply to author
Forward
This conversation is locked
You cannot reply and perform actions on locked conversations.
0 new messages