Test 18: Client Authentication (Authorization Code Flow)

110 views
Skip to first unread message

Sumant Shintre

unread,
Nov 4, 2020, 5:24:26 AM11/4/20
to UDAP
Hi Team,

We are done with "Test 16: Trust Dynamic Client Registration" successfully. 
Now we are trying "Test 18: Client Authentication (Authorization Code Flow)" and "Test 20: Client Authentication (Client Credentials Flow)"

But we are stuck when the test script tries to call the authorize request. Please find the attachment. Can we please let us know, how the GET request looks like for the authorize?

Regards,
Sumant RS
UDAP Test Tool_test18.png

UDAP

unread,
Nov 4, 2020, 12:52:36 PM11/4/20
to UDAP
Hello Sumant,

For Test 18, the test tool makes a series of invalid authorization endpoint GET requests followed by a valid one. The valid GET request URL is formatted as per RFC 6749 Section 4.1.1.  

Here is an example URL adapted from Section 3.1 of UDAP JWT-Based Client Authentication: 


The test tool is expecting your server to complete the user authorization in the second browser window that opens for Test 18 within 5 minutes and then to redirect the user back to the test tool's registered redirect URI. A count-down timer is displayed on the main test page with the remaining time. 

Thank you,
The UDAP Team
UDAP.org 


Sumant Shintre

unread,
Nov 4, 2020, 1:49:39 PM11/4/20
to UDAP
Team,

As shown in the above screen, test  IIB2c - authorization endpoint accepts GET requests not getting executed and we are not seeing any exception for this test case. As you mentioned in the above example, form where the URL parameters will be fetched? also, can we use any redirect URL or it should be the same as what has been provided in the request of Test 16. 

UDAP

unread,
Nov 4, 2020, 3:01:18 PM11/4/20
to UDAP
Hello Sumant,

Test IIB2c results are populated only after all invalid and valid tests are completed, so if it says "NOT_TESTED" that means the test tool did not finish the test sequence. If the 5 minute timer runs out before a redirect request is received, the test report will show a failure for IIB2c, so it appears that the test is being interrupted while it is running.

The URL will be fetched from the second window opened automatically on your browser when you launch Test 18. 

The authorization endpoint handling is per the standard RFC 6749 requirements, so you should not use any arbitrary redirect_uri provided by the client. Your server must validate the request as per Section 4.1.2 of RFC 6749. This includes verifying that the redirect_uri matches one of the URIs that the client included in its most recent registration request. Please see the Section 4.1.2.1 of RFC 6749 for handling requirements for invalid authorization requests.

Sumant Shintre

unread,
Nov 5, 2020, 9:30:45 AM11/5/20
to UDAP
Hi Team,

We are following the steps mentioned in the document. But we are suspecting "Test 18 and Test20" are not executing any other request apart from " fhir/r4/.well-known/udap as shown below. 



How will get to know that other requests/API's are getting called, as we don't see any request in the server related to authorize?
and also, from where the URL parameters are fetched and sent as part of authorize requests like client_id, redirect_url etc.  

Sumant Shintre

unread,
Nov 5, 2020, 10:44:50 AM11/5/20
to UDAP
Team,

In addition to the above-mentioned details, we are passing both "/token" and "/authorize" endpoint the metadata, do we need any additional parameters to be passed/set in metadata for "Test 18"?  Please find the attachment.
UDAP Test Tool_metadata_test18.png

UDAP

unread,
Nov 5, 2020, 11:50:09 AM11/5/20
to UDAP
Hello Sumant,

Invalid authorization requests are originating directly from the test tool to the authorization endpoint identified in the metadata. The valid request originates from the browser you are using to run the test tool using the second Test 18 window that opens when you start the test. During the test, the test tool causes that window to make the authorization request, so you should be able to see the authorization request URL appear in the browser address bar and visually confirm that your browser is actually making the request. Make sure you don't close the second window during the test -- the test tool will close it automatically when it is no longer needed.

Regarding metadata, the registration_endpoint is also required. As noted in the test description, after retrieving the metadata, the test tool performs UDAP DCR 
to obtain the client_id and register the redirect URI that it will use for that run of Test 18.

Sumant Shintre

unread,
Nov 5, 2020, 12:58:01 PM11/5/20
to UDAP
Team,

Thanks for providing the details.
We tried adding registration_endpoint in the metadata but still, the UDAP tool is not performing the UDAP DCR.  Also, in the browser, we are seeing below URL  "https://www.udap.org/UDAPTestTool/redirect/1" and a new window is getting closed within a few seconds. 
Please let us know what else we are missing. 

UDAP

unread,
Nov 5, 2020, 2:00:09 PM11/5/20
to UDAP
Hello Sumant,

The second window closes if the test tool aborts, such as due to a problem with your metadata. This was occurring almost immediately because your FHIR metadata does not have the token endpoint in the expected location. The test tool looks for this information as per Section 3.1 of the SMART app launch framework. Note that this should no longer abort the test if the token endpoint is properly populated in the .well-known/udap metadata. Please try again now.

Note that this test tool is not intended to validate that your FHIR metadata is properly structured overall, only whether or not certain UDAP-related elements are in the expected locations within the returned JSON.

Sumant Shintre

unread,
Nov 5, 2020, 3:23:16 PM11/5/20
to UDAP
Team,

Thanks for the info, we are able to proceed now. 
But for Test 18 and Test 20 we are seeing the below issue. (PFA)
FHIR CapabilityStatement optionally includes matching token URL  --> token endpoint not present in CapabilityStatement 

Kindly let us know what we are missing.
UDAP Test Tool_test20.png

UDAP

unread,
Nov 5, 2020, 3:36:38 PM11/5/20
to UDAP
Hello Sumant,

FHIR metadata is not structured in the same way as UDAP metadata.

Does your FHIR metadata look like the example at the link we provided in our last reply in this thread (http://hl7.org/fhir/smart-app-launch/conformance/index.html#declaring-support-for-oauth2-endpoints)? 

Sumant Shintre

unread,
Nov 5, 2020, 4:12:38 PM11/5/20
to UDAP

We are following the same as what you mentioned. Kindly find the attachment for both metadata we are using
fhircapabilitystatement_get.py
udapmetadata.py

UDAP

unread,
Nov 5, 2020, 5:20:38 PM11/5/20
to UDAP
Hello Sumant,

You  should confirm that same JSON data (and with actual values specific to your site rather than api-example.com, etc.) is what is listed in the test report (the first several hundred characters of the FHIR metadata as received are included in the report ). 
Reply all
Reply to author
Forward
0 new messages