Logout Conformance Testing for OPs
This is a historical page relating to the now-decommissioned old test suite – please see the current instructions.
This page describes how to run logout conformance tests for OpenID Providers (OPs).
Logout functionality for OpenID Connect is defined in three specifications:
- OpenID Connect Session Management 1.0: Defines RP-Initiated Logout functionality and iFrame-based Logout functionality.
- OpenID Connect Front-Channel Logout 1.0: Defines a logout mechanism that uses front-channel communication via the User Agent between the OP and RPs being logged out.
- OpenID Connect Back-Channel Logout 1.0: Defines a logout mechanism that uses direct back-channel communication between the OP and RPs being logged out.
Note that the RP-Initiated Logout mechanism is independent of the three mechanisms for communicating logout messages from OPs to RPs and can be used in combination with any of them. OP Logout Certification is therefore factored into four conformance profiles:
- RP-Initiated Logout OP: Tests OP logout initiated by an RP
- Session Management OP: Tests RP logout using iFrame-based messages from OPs to RPs
- Front-Channel Logout OP: Tests RP logout using User Agent-based Front-Channel logout messages from OPs to RPs
- Back-Channel Logout OP: Tests RP logout using Back-Channel logout messages from OPs to RPs
A logout certification submission must support RP-Initiated Logout OP and one or more of the other three logout profiles.
Establishing Your Testing Configuration
First, establish your testing configuration as described in the OP testing instructions. You must specify that “RP-Initiated Logout” tests are to be shown and one or more of the “Session Management”, “Front-Channel Logout”, and “Back-Channel Logout” test categories for the logout tests to be made available.
On your testing page, there will be sections titled RP-Initiated Logout, Session Management, Front-Channel Logout, and Back-Channel Logout, depending upon your selections. The tests for each of the four logout conformance profiles are listed in the corresponding section.
If you are not using Dynamic Client Registration, you will need to manually configure these values in your testing configuration. Recall that your testing site will be at a URL like https://op.certification.openid.net:61234/, but with a different port number. Use your port number in the actual values for the URLs below.
- post_logout_redirect_uris: https://https://op.certification.openid.net:61234/logout
- frontchannel_logout_uri: https://https://op.certification.openid.net:61234/frontchannel_logout
- frontchannel_logout_session_required: True
- backchannel_logout_uri: https://https://op.certification.openid.net:61234/backchannel_logout
- backchannel_logout_session_required: True
Note that you must use “True”, rather than “true” in the configuration user interface.
Submission of Results
Once you have finished testing, submit your results as described at Submission of Results for OPs. Note that separate submission files should be set for each of the four logout conformance profiles supported by your implementation. As described above, a successful logout certification application will contain at least two and up to four submissions – one for each of the supported logout profiles.
The logout conformance profiles require you to submit test runs for all the response_type values supported by your implementation.
Additional Notes on the Logout Profiles
RP-Initiated Logout (OP-RpInitLogout-*)
All the tests use RP-Initiated Logout to start the test. This means that the OP must publish an
The basic RP-Initiated Logout test consists of:
- The RP verifies that the OP publishes an
- The RP sends an End Session request to the
- If the OP accepts the request, it SHOULD display a webpage to the user asking for verification. (Verification must be given for the test to complete.)
- If a
post_logout_redirect_uriis published by the RP, the OP must redirect the user back to the
post_logout_redirect_uri. If no
post_logout_redirect_uriis provided, then the OP must redirect the user to a post logout page on the OP.
This flow is the same whether the OP supports Back-/Front-Channel Logout or Session Management using iFrames. For all the tests named OP-RpInitLogout-*, the above described flow is the flow of all the tests. Now, for some of the tests the test tool (an RP) intentionally sends an incorrect RP-Initiated Logout request, which means that the flow should never get past (2). For these tests, save a screen shot to show that the error was detected and handled.
Session management (OP-Session-*)
When testing session management, one step is added before (3), namely checking that the RP can get back a session
unchangedresponse from the OP’s iFrame. And after the user has been redirected to the
post_logout_redirect_uri, a test is added that verifies that the RP gets back a session
changed response from the OP’s iFrame.
Front-Channel Logout (OP-FrontChannel-*)
If the OP supports Front-Channel Logout then, in a similar manner as above, after (3) and before (4) this is added: The OP displays a webpage with an iFrame with a src based on
frontchannel_logout_uri. If the
iss are OK, then the RP replies with
Back-Channel Logout (OP-BackChannel-*)
If the OP supports Back-Channel Logout then after (3) and before (4), this is added: The OP does a POST to the
logout_token. If the
logout_token is OK, then the RP replies with