Conformance Testing for OpenID Connect OPs

This page describes how to run conformance tests and gather testing results for OpenID Providers (OPs). These instructions are for the new Java-based system (the previous python system used for OpenID Connect certifications was retired in August 2020, as described at Migration of OpenID Connect Certification Software.).

Available Certification Profiles

The first step in using the OpenID Provider tests is to decide which conformance profiles you plan to test. If you have problems starting testing, you can send questions to (Please include the log file if your question is about a test result.) 

The profiles are defined here: OpenID Connect Conformance Profiles

Most OPs will test the Basic OP profile and many will also test the Implicit OP and Hybrid OP profiles, depending on which response_type values their server supports. Most OPs will also test the Config OP profile, which tests your discovery information published at your .well-known/openid-configuration endpoint. Some OPs will also test the Dynamic OP profile, which tests your support for Dynamic Client Registration and related features. OPs that support response_mode=form_post can certify for the Form Post OP profile. The form post tests should be run for each authentication profile (Basic, Implicit, and/or Hybrid) that your OpenID Provider supports.

Separate instructions are available for the Logout OP tests:

The Third Party-Initiated Login OP profile tests are available as ‘OpenID Connect Core: 3rd party initiated login Certification Profile Authorization server test’.

Running Tests

For the Basic/Implicit/Hybrid profiles, if your server supports Dynamic Client Registration, you should use that when testing. If it does not, you are required to manually register three clients:

  1. A client that supports client_secret_basic.
  2. A second client that supports client_secret_basic; this required for a few tests, for example to test that authorization codes are correctly bound to a client.
  3. A client that supports client_secret_post; this may be the same client as the first one if your server permits one client to use either method.

In all cases, the client should have this redirect url registered:<ALIAS>/callback, where <ALIAS> is replaced with the unique “ALIAS” value you chose to use.

To test:

  1. Open
  2. Login using a Google or GitLab account
  3. Press “Create a new test plan”
  4. Select the test plan for the profile you want to test. Make sure to select a test plan in the “Test an OpenID Provider” section of the menu.
  5. Fill in the configuration form. The fields in the configuration form all have help values available by hovering your mouse pointer over the ‘i’ button.
  6. You must select an “ALIAS” to use. This will form part of the redirect uri and should be unique to yourself, for example your company name. (If you use the same alias as another user, yours tests will interfere with each other.) 
  7. Once you have created your test plan, you should run each test in the test plan. Please be sure to pay attention to the instructions in the blue box at the top of each test.

Certification of a profile requires that you have ‘PASSED’, ‘REVIEW’, ‘WARNING’ or ‘SKIPPED’ results for all tests in the profile. You cannot certify with any FAILED or INTERRUPTED results for the profile. In some cases, a screen capture is uploaded as evidence of passing the test. Once you have finished testing, proceed to Submission of Results for OPs. Any questions can be sent to (Please include the url of the log-detail.html page or the downloaded log file if your question is about a test result.)