Stream: CARIN IG for Blue Button®
Topic: 11/18-19 CARIN Connectathon - UPMC Server
Michele Mottini (Nov 18 2020 at 14:33):
@josh lamb could you register our client on your server? Name CareEvolution, redirect URLs
https://myfhr.careevolution.com/cfhrprovideraccounts/redirecttarget
http://localhost/WebClientTest.Adapter1.WebClient/cfhrprovideraccounts/redirecttarget ?
Josh Lamb (Nov 18 2020 at 14:38):
Hi @Michele Mottini will you be sending a client_secret or will you be sending a code challenge (PKCE)?
Michele Mottini (Nov 18 2020 at 14:41):
Client secret
Josh Lamb (Nov 18 2020 at 14:44):
Got it, will PM you shortly when application is registered.
Michele Mottini (Nov 18 2020 at 15:07):
Registered and can login, but then I got a 500 trying to retrieve the token
Michele Mottini (Nov 18 2020 at 15:08):
The response body is
{
"message": "Unknown error. Please contact your system administrator",
"errors": []
}
Josh Lamb (Nov 18 2020 at 15:08):
can you send me your post command to the token endpoint, with the body?
Michele Mottini (Nov 18 2020 at 15:09):
Response headers:
Request-Context : appId=cid-v1:5d6547b3-3149-424f-9022-ae624cd65780
tracestate : cid-v1:5d6547b3-3149-424f-9022-ae624cd65780
Michele Mottini (Nov 18 2020 at 15:09):
Here is the body:
grant_type=authorization_code&redirect_uri=https%3A%2F%2Fmyfhr.careevolution.com%2Fcfhrprovideraccounts%2Fredirecttarget&code=eyJraWQiOiJUcE4taldPZ216VWMxTjB5OHY2b3Rqa25lNlRGdlJ1Sm9nazB1akJwUmtFIiwidmVyIjoiMS4wIiwiemlwIjoiRGVmbGF0ZSIsInNlciI6IjEuMCJ9.Axfo5Hr08-rfSScujBJdXBKUn021enX02y353Oogae6tQXFX9NBSQEUZQQSVFdBitazEjNNs6KQnLy7Odvv2zO5eztaCjkcDGd1D_9hMz61e5dhI5E_moww6gTmrBu34gf5J33SGqAo-Sf34eb-NX9fz2XQ9v174Yb-tqK5Jybr8InWAOXObFiRDg-G0lxfouICMN5IGh6TA3yhRjnklGJ3eoQ2YsQmjjLcLmGwli-ps8Or0QAjY5DGClVjM5druxsFphD7gM8qjlXUaMKn3MjHpONjqpqhsPHcWOCokJ9qD8QVOgms9WemE7IWW-UAL-JZzcCX_fFNb_tsiBg4c5A.k5AveE3B6XV4Qx0a.mTaM2gVO4v9M4nr7GQkvMIz6DtbXyBYaL56ZGYq4nhtqrzbXHpooS4kd7ytjjuKTd5mCeocj43eIfntIPyPoDgyfxIKJC419a2FrPni0HDgFZme3Qd3yKyI7Ibx74yvIyVfpD7b7UlfQAkYY_rKDcZPHKQ5YfnBYFTZUdNvcxCpQXSJJeFZUDyZflwW8BWttjQ34cuhT8OGOTqhKeBX-j9lkfjnAJnIswfMGlbPLenX6qC9vK8uxJZEqW2ozuVfnxPRoEBsdlPkUuH3hB21normgYZye7QXsiLhcCliaZQL4CDLBm3PJ8mH217lD6PJcQn-xQLtZhW70F5pXgYorpF_B0SW0v8Dl6tIXvY-lK8JiSjVoHHvtU-CmRvaS-0aWl1vifSFA17tnQaNsyqIYrcz8uVvQJDwtCt6SKWhS9wUF8yo8dsymGukeILfLMLUnkpPg8LfvhNSGK2MGLIzo8MllC5Z3gpWyQkpWXAvmJ27QD1zALmCX7OWW_bWFuxgsEYGn6hjyFYEocEVPVPoMUbFIW8_BHUTG4EN1DP0IskQya0BTpMw5z-ovB-c4KxdJkjj-8TvcWpyvxpfhzYTgFcMuvCB7urUMY7hSvxa0HbzxD8UDIszDfLcoEudteHMpDdFbL5QSoxoPdqgOg79VP41zn-GVLgOwZ8_ENkCX1JXJYSs3MgTrfUNSLiFGWE9Un-4LNydqrGRYF8-vtcte4L22YbDmCY7327_ZiCK32n9nbenGM2maRQeb2vvIJdE6rnE7V1oWMyrl85TTshrbjdTRE4an7MScs0kCvEoLMUcJD1S3BtStMZwwLnnpCY92LSoNRCOSnIEq8ITLUUZkXgZybPgP5fP8GzQtV6SuKtT-EHaAH9stSi1wwHlJJ7UT8UQgVLboo8HuQLLSIow.En0EKtWYLr-rHbg2bG9b5Q
Josh Lamb (Nov 18 2020 at 15:12):
I am expecting a basic auth header of a base64 encoded string that will have this format "{client_Id}:{client_secret}" if you are including the client secret as part of the auth header. I do not see the secret in the body you posted.
Michele Mottini (Nov 18 2020 at 15:13):
Here are the request headers:
Accept : application/json
Authorization : Basic NzExMTVkYmUtNWMwYS00Zjk1LTg4OGYtZGFiM2Q0Yzc3ODJmOjk1NzhuOUJmd2ZRNk03fm52a1N+d01LWTVCcC14fi5Xflo=
Content-Type : application/x-www-form-urlencoded
Content-Length : 1549
Josh Lamb (Nov 18 2020 at 15:18):
I was expecting the client_id to also be included in the post body. Is this not standard? I can pull this from the auth header when present instead...
Michele Mottini (Nov 18 2020 at 15:23):
Don't believe that's standard, but I have a setting for that on our client
Josh Lamb (Nov 18 2020 at 15:25):
Okay, let me know if that works. I will add logic to account for client_id in header.
Michele Mottini (Nov 18 2020 at 15:38):
Yes, I can connect now with the client id in the body. Getting errors on the data, looking into that
Michele Mottini (Nov 18 2020 at 15:43):
Coverage resources contain an invalid beneficiary reference:
"beneficiary": {
"reference": "88800307601"
},
Josh Lamb (Nov 18 2020 at 15:53):
Good catch, fix for both of the issues you identified are now live in Sandbox @Michele Mottini
Michele Mottini (Nov 18 2020 at 16:36):
OK, it works now, but there are three missing Practitioner: ExamplePractitioner1, ExamplePractitioner2, ExamplePractitioner4
Ryan Conley (Nov 18 2020 at 16:38):
Michele Mottini said:
Don't believe that's standard, but I have a setting for that on our client
https://tools.ietf.org/html/rfc6749
2.3.1. Client Password
Clients in possession of a client password MAY use the HTTP Basic
authentication scheme as defined in [RFC2617] to authenticate with
the authorization server. The client identifier is encoded using the
"application/x-www-form-urlencoded" encoding algorithm per
Appendix B, and the encoded value is used as the username; the client
password is encoded using the same algorithm and used as the
password. The authorization server MUST support the HTTP Basic
authentication scheme for authenticating clients that were issued a
client password.
For example (with extra line breaks for display purposes only):
Authorization: Basic czZCaGRSa3F0Mzo3RmpmcDBaQnIxS3REUmJuZlZkbUl3
Alternatively, the authorization server MAY support including the
client credentials in the request-body using the following
parameters:
client_id
REQUIRED. The client identifier issued to the client during
the registration process described by Section 2.2.
client_secret
REQUIRED. The client secret. The client MAY omit the
parameter if the client secret is an empty string.
So in the auth header is standard, with being in the body is optional.
@josh lamb @Michele Mottini
Josh Lamb (Nov 18 2020 at 16:49):
Michele Mottini said:
OK, it works now, but there are three missing Practitioner: ExamplePractitioner1, ExamplePractitioner2, ExamplePractitioner4
What includes did you run, "*" or care-team?
Michele Mottini (Nov 18 2020 at 16:53):
No includes, I am looking at the references in the resources and go get them individually
Josh Lamb (Nov 18 2020 at 17:01):
Got it, we found issue. Fix is incoming.
Ryan Conley (Nov 18 2020 at 17:43):
Michele Mottini said:
No includes, I am looking at the references in the resources and go get them individually
Sorry about that and thanks for bringing it to our attention. A fix is currently deploying, so it should be rectified in our sandbox in 15 minutes or so.
Edit: Fix is live.
Tone Southerland (Nov 18 2020 at 19:54):
@josh lamb do you have the reference to the includes "*" in the FHIR spec? It seems not all servers are supporting this?
Josh Lamb (Nov 18 2020 at 20:10):
https://build.fhir.org/ig/HL7/carin-bb/branches/v0.1.11/CapabilityStatement-c4bb.html#resource--details the table will list the includes and searches that are in scope for CARIN IG. I have interpreted "*" to indicate that all references should be resolvable within the bundle.
Josh Mandel (Nov 18 2020 at 20:16):
Re: client_id, SMART is specific and prescriptive here beyond what the base OAuth spec says: http://hl7.org/fhir/smart-app-launch/#step-3-app-exchanges-authorization-code-for-access-token
Required [as a POST body param] for public apps. Omit for confidential apps
Josh Lamb (Nov 18 2020 at 20:30):
Hey, thanks for the feedback @Josh Mandel .
Michele Mottini (Nov 18 2020 at 21:22):
Tried again and it worked nicely, here is the data in our app:
Michele Mottini (Nov 18 2020 at 21:24):
Attempt to refresh the access token failed with a 500 though. Request body:
grant_type=refresh_token&refresh_token=eyJraWQiOiJUcE4taldPZ216VWMxTjB5OHY2b3Rqa25lNlRGdlJ1Sm9nazB1akJwUmtFIiwidmVyIjoiMS4wIiwiemlwIjoiRGVmbGF0ZSIsInNlciI6IjEuMCJ9.j7_08kqZNZ4RbHMsMlCk2U8ms1xzM3PWA54qtNTFEqbL3iqnKO0rZc4OP1VZmkYE3vVqjPWfB7osM_-4hsAPpKugmyD3kARnwbUI1uy7KMvbvYGDvSQz0vYGTr1dqo6FYVkG1pfsE8C_1bp34dfClN92zZumfCVpqRKvwXEu1S4B1jzVoDHAo5UphciaJ9MwJJkzlK4nLo9P8ZzZR9C79-dEXVmTFn5Riwv2Tt9ukTGxP7pblKjhhzCrdFAEoYMY3ZBCxT7J9SlySVTC9UEQRoWKNyMv0KOeJT3xiuQW9ezEYqVGkMZb7bwDz-wpL95wyLZoKe91xeh8LU6CJsWcBg.8YcpQhz7Ggeq3GjF.MJs-a-UnBH3b1NowOYKrwaBO5pw5j2DJK5qGeQubGR_qfK_83hD0IcWsMyJ50RlGN5NFs-dv1QVBwjztWvuHsOSGktERRiaKXQTx5JBl766tiFRPGyYvQiVFvZDYa5v0UJ9H7G-hMGptiWku9FZTBFPVm8yqSzwCcMtdQe16NsOFHuRrHToJOLigxRo1hVmd3ftnkyTgGoAVqfMl2WXprC5XKvTkSV5f-Ut0uquhuqyGwdcUKqkzjVZfH7s4qBHhticx2C8Pv8ayLUEcu_8eMyECGRIH2_s_UOx_qixXDbSXGxAgmSFxyGrqhEhDBq8uF4akskUDnE1ImIJ6agSi7L7mmh29-Bea5_SglM2zri933WaSLr9M73PYNI0PkoN4qKqQ6AfmaAblcIUt1oSmDJZEl3E6gI2_Sfc_CZ3B8GrbkI4f_JAWQ7G44J4TFa_DpkFVg4ymBL2yN4KDTs6aSub0JFVml1X8tlVmSwpwT-H7XAQ6V2J4okGcPpASXNnTl5gktKOBl1Gc8GliTfHcuqg-22zLGMKRudMYlPTrJ9QJAtPvqaDjUwJt4wn_reG1jm5LY27IVrNFyKmIWjfvsa9Gei9cpzBdJMQoSzUaDGYDZ9S0KNniXyvPaKjSEczRVWLK5mWd3sdgzxrF60pG3CK1ekyrzqIoOvHPWDzfCfDHQutyOXUBG78yVk5dh7Kh-zL_fb8xnOiR2PVr9yZl8t40UOPudnwY4ejTEX4zyGo5vEfMQrtTpwBpiQPRXZ5Wl51KGsBlrNGAJPf2P9OpG_iauXu4MVyIIGyCmOKYSHIsLnLq5BYtcerGWtzyZUzFXrTSMrvR0IPTqcjca3GW30UGC6GGuMXrzWWWCbPYk_gpnklYaNd0WS6FveLNEkz-_zCqNoOoTGtA9SjyGwzC2ADEs_ojrEw5s1c.WMIof8sFmdJTwnjlr8NnBw
Michele Mottini (Nov 18 2020 at 21:24):
Headers:
Accept : application/json
Authorization : Basic NzExMTVkYmUtNWMwYS00Zjk1LTg4OGYtZGFiM2Q0Yzc3ODJmOjk1NzhuOUJmd2ZRNk03JTdlbnZrUyU3ZXdNS1k1QnAteCU3ZS5XJTdlWg==
Content-Type : application/x-www-form-urlencoded
Content-Length : 1478
Michele Mottini (Nov 18 2020 at 21:24):
Response body:
{
"message": "Unknown error. Please contact your system administrator",
"errors": []
}
Michele Mottini (Nov 18 2020 at 21:25):
Possibly because there is no client_id in the body?
Josh Lamb (Nov 18 2020 at 21:25):
Can anyone join the breakout channel as an application developer so that we can see how the UPMC Health Plan sandbox data displays?
Michele Mottini (Nov 18 2020 at 21:29):
I am joining (or trying to)
Michele Mottini (Nov 18 2020 at 21:41):
CareEvolution production app: https://myfhr.careevolution.com - or look for 'MyFHR' in Apple Store or Google Play
Michele Mottini (Nov 18 2020 at 21:53):
And yes, there is a problem on our side: we did non import correctly the amounts, so they are not displayed
Josh Lamb (Nov 19 2020 at 15:20):
Hello, Would anyone like to jump into room 3 to connect with UPMC?
Michele Mottini (Nov 19 2020 at 21:47):
...if the token request has the wrong client secret the server returns a 500 - should return a 400 with some error description in the body (see OAuth2 specs)
Josh Lamb (Nov 24 2020 at 19:55):
Alignment with OAuth2 Http Status Codes and error details will be available at next Connectathon.
Regarding the issue with the token refresh, it appears that the provided authorization header is not encoded correctly:
What you provided above is encoded as:
71115dbe-5c0a-4f95-888f-dab3d4c7782f:9578n9BfwfQ6M7%7envkS%7ewMKY5Bp-x%7e.W%7eZ
We are expecting:
71115dbe-5c0a-4f95-888f-dab3d4c7782f:9578n9BfwfQ6M7~nvkS~wMKY5Bp-x~.W~Z
('~' is showing as '%7e')
Thanks @Michele Mottini
Michele Mottini (Nov 24 2020 at 21:27):
@josh lamb encoding the secret is correct: 'The client identifier is encoded using the
"application/x-www-form-urlencoded" encoding algorithm per
Appendix B, and the encoded value is used as the username; the client
password is encoded using the same algorithm and used as the
password. ' https://tools.ietf.org/html/rfc6749#section-2.3.1
Last updated: Apr 12 2022 at 19:14 UTC
