Skip to content

Test for HTTP POST support in the authorization endpoint for OIDCC basic OP

Marcus Almgren requested to merge 1293-missing-test-for-post-on-authorize-request into master

TL;DR: Test for HTTP POST support in the authorization endpoint for OIDCC Basic OP, ref #1293. Additionally, add POST capabilities to the browser automation.

This MR does the following:

  • For compatibility reasons, it adds urlsWithMethod and visitedUrlsWithMethod in BrowserControl. These reflect the URL strings already present in urls and visited, but adds the additional dimension of the intended HTTP request method to be used.
  • The UI (log-detail.html) is reworked to parse the URLs it's supposed to redirect to, and instead of having the "Proceed with test" button open a new window and load the URL there, it instead instructs the browser.html template to render a form and either GET or POST (by means of action) it to a new window (by means of target). This, of course, means that all UI "redirects" are now forms being sent, with either GET or POST.
  • The browser automation, WebRunner inside of BrowserControl, has been updated as well, in order to support POSTing.
  • And finally there's a new test added, oidcc-ensure-post-request-succeeds, which is included in the Basic OP test plan. This is an end-to-end test that extends AbstractOIDCCServerTest, but which will POST to the authorization endpoint and then expect the callback to the redirect_uri to happen within 30 seconds after "Proceed with test" is invoked. If an OP does not support POST on the authorization endpoint, the test will have result WARNING after it times out, as per the conclusion in #1293.
    • Note: There was a suggestion on Slack to prefer screenshot uploading over timeout, but that didn't seem to be a very good fit as I could not find a good way to combine the upload of a screenshot of a failed OP while at the same time having the test end in a WARNING (instead of REVIEW, which is the normal behavior for screenshot requiring tests).

UI change

The look of the suite UI for visiting URLs with GET is unchanged. For POST, the UI is altered to reflect the actual request that will be made:

image

Testing (happy)

In terms of testing this, we can have a look at this test log (from the CI pipeline):

image

and we see that this corresponds to what we get when explicitly curling it:

$ curl -d 'client_id=470519824180317&redirect_uri=https://review-app-dev-branch-4.certification.openid.net/test/a/oidf-authlete-core-2/callback&scope=openid&state=T2L4k5ZcKr&nonce=thgwMnqWZh&response_type=code' 'https://fapidev-www.authlete.net/api/authorization'

<!doctype html>
<!---->
<!---->
<html>
<head>
  <meta charset="UTF-8">
  <meta name="viewport" content="width=device-width, minimum-scale=1.0, initial-scale=1.0, user-scalable=yes">
  <title>FAPI Test Service | Authorization</title>
  <link rel="stylesheet" href="/css/authorization.css">
  <!--  //-->
</head>
<body class="font-default">
  <div id="page_title">FAPI Test Service</div>
  <div id="content">
    <h3 id="client-name">core conformance client secret basic</h3>
    <div class="indent">
      <img id="logo" src="https://button.heenan.me.uk/~joseph/authlete-150x150.png" alt="[Logo] (150x150)">
      <div id="client-summary">
        <p>core conformance client secret basic</p>
        ...

Testing (sad)

To verify the behavior when the authorization server does not support POST, we can do a suite OP vs RP test and supply an incorrect client_id to simulate an error on the OP side that does not result in a callback to the redirect_uri. Doing so yields the following result on the OP side:

image

and as we can see, the test ended in WARNING with the following reason:

ExpectRedirectUriHasBeenCalled: The OpenID Connect core specification states that 'Authorization Servers MUST support the use of the HTTP GET and POST methods defined in RFC 7231 at the Authorization Endpoint'. In the conformance suite, failure to correctly respond to an HTTP POST request to the authorization endpoint within 30 seconds is considered a WARNING.

Edited by Marcus Almgren

Merge request reports