Discovery response not valid error
Hi,
I am trying to configure OAuth2 server to connect to Cerner Auth server to get FHIR API access token but I am getting the error "Discovery response not valid".
.png)
I can get the access token back okay from Cerner endpoint used in the OAuth configuration below via Postman and Manually sending the request via HTTP Operation from HealthShare, so the URLs I am using looks correct but the OAuth configuration is not working.
Not sure if this is issue from Cerner side or HealthShare side. I tried enabling debugging but nothing useful.
Comments
The URL that the discovery request gets sent to is:
[issuer-endpoint]/.well-known/openid-configuration
So you might try hitting that endpoint in Postman to see what comes back.
You might also try turning on ISCLOG to log what's happening. I'm not seeing anything in the doc specifically on ISCLOG, though it is mentioned in the context of other topics, for example:
https://docs.intersystems.com/iris20221/csp/docbook/Doc.View.cls?KEY=GR…
The value of ^%ISCLOG corresponds to the verbosity of the logs, where higher is more verbose. I'm not sure how high the scale goes, but I'm pretty sure it's less than 10, so I always just set it to 10.
You can skip setting the "Category" subscript to log all categories.
And don't forget to turn off ISCLOG when you're done!
kill ^%ISCLOG
or
set ^%ISCLOG=0
Thank you @Jorge de la Garza .
I tried the URL with /.well-known/openid-configuration and it failed. I manged to get the correct OpenID discovery url from the Cerner documentation and I can see the return parameter when I use the new URL in the browser but it not working in the HealthShare OAuth configuration. I am getting Unexpected issuer claim error
.png)
I enabled the ISCLog to 10 but it is not showing any useful information about the error.
Also can I please check, if the OAUth configuration in HealthShare can any option other than OpenID connect for discovery?
Thanks
It looks like the "Unexpected issuer claim" error is caused by the "issuer" property of the discovery response body not matching the "Issuer endpoint" value of the server description. So my question then would be, when you submit a discovery request from your REST client of choice, does the response "issuer" value match the issuer endpoint? If not, could it be an issue with the way the OAuth server is configured? Or are you accessing the OAuth server through a proxy so that the endpoint you're hitting is not the actual URL of the OAuth server?
@Jorge de la Garza Thank you so much for your help with this issue.
I think what I need to achieve is to get the HealthShare discovery functionality to use the specific URL for the auth server instead of the openID connect call with .well-known/openid.configuration , mainly because it will be the Integration engine which uses the access token to get the resources and transform it to HL7 or other format of message and send it to other systems.
Discovery URL for the authorization server I need to connect is https://xxxxx.cerner.com/r4/xxxxxxxxxxx/metadata but if by default the HealthShare OAuth discovery option is using the OpenID format (.well-known/openid.configuration) , this URL becomes invalid. Is there any way to specify the OAuth2.0 Client Discovery option to not use the openID connect and just use the URL provided in the Issuer endpoint ?
Apologies if I am asking silly question here . I am new to OAuth.
No worries, OAuth is a complicated subject. If the OAuth server you're trying to define in IRIS doesn't support the "well-known" endpoint, then I think you'll have to enter the server description manually, as opposed to having IRIS fetch it by discovery. You can read about how to do that here: https://docs.intersystems.com/iris20221/csp/docbook/DocBook.UI.Page.cls?KEY=GOAUTH_client#GOAUTH_client_config_ui_server_manual
Thank you so much for your help @Jorge.delaGarza6257.
I configured the endpoint manually and configured the client details but not getting the access token back. I have created a WRC ticket to get some help from the support team.
Thank you for help with this issue.
Mary