This page describes how to run conformance tests and gather testing results for OpenID Providers (OPs). As described at Migration of OpenID Connect Certification Software, there are currently two live test suites for OpenID Connect certification testing. These instructions are for the new Java-based system. During the migration period, testers are highly encouraged to test with both systems (and have a financial incentive to do so).
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 email@example.com.
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
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: https://openid.net/certification/connect_op_logout_testing/
The Third Party-Initiated Login OP profile tests are available as ‘OpenID Connect Core: 3rd party initiated login Certification Profile Authorization server test’.
Open https://www.certification.openid.net/. Login using a Google or GitLab account, or any OpenID Connect OP that supports WebFinger.
First press “Create a new test plan”, then 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. The fields in the configuration form all have help values available by hovering your mouse pointer over the ‘i’ button.
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.)
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:
- A client that supports client_secret_basic.
- 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.
- 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:
where <ALIAS> is replaced with the unique “ALIAS” value you chose to use.
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.