Logout Conformance Testing for OpenID Connect RPs
This page describes how to run logout conformance tests for OpenID Relying Parties (RPs).
Background
Logout functionality for OpenID Connect is defined in four specifications:
- OpenID Connect RP-Initiated Logout 1.0: Defines how a Relying Party requests that an OpenID Provider log out the End-User
- 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. RP Logout Certification is therefore factored into four conformance profiles:
- RP-Initiated Logout RP: Tests OP logout initiated by an RP
- Session Management RP: Tests RP logout using iFrame-based messages from OPs to RPs
- Front-Channel Logout RP: Tests RP logout using User Agent-based Front-Channel logout messages from OPs to RPs
- Back-Channel Logout RP: Tests RP logout using Back-Channel logout messages from OPs to RPs
A logout certification submission must support RP-Initiated Logout RP and one or more of the other three logout profiles.
Establishing Your Testing Configuration
First, establish your testing configuration as described in the RP testing instructions. To run logout tests, select a test plan under “Test a Relying Party / OAuth2 Client Logout Support” section of the “Test Plan” dropdown.
Please note that additional client metadata such as post_logout_redirect_uri are needed to run these tests. Additional configuration fields will be displayed automatically when using static client configurations.
Running Tests
Running a test will typically require the following sequence of interactions with the test suite:
- OpenID Provider Discovery
- Dynamic Client Registration (if not using static client configuration)
- Authorization Request
- Token Request (if response type being tested uses the Token Endpoint)
- Userinfo request (optional, will not affect the test flow)
- RP-Initiated Logout Request: RP initiates logout by calling the end_session_endpoint
- Handle OP-Initiated Logout Request (the format of which will be one of Session Management, Front-Channel, or Back-Channel): In this step the conformance suite will send front-channel, back-channel or both front and back channel logout requests to the client.
- Handle Post Logout URI Redirect
For the session management test, oidcc-client-test-session-management, additional steps are required:
- OpenID Provider Discovery
- Dynamic Client Registration (if not using static clients)
- Authorization Request
- Token Request (if response type being tested uses the Token Endpoint)
- Userinfo request (optional, will not affect the test flow)
- Check session status expecting unchanged: Send at least one http request to check_session_iframe and send at least one postMessage call to the check session iframe
- RP-Initiated Logout Request: terminate the session by calling the end_session_endpoint
- Handle Post Logout URI Redirect
- Check session status expecting changed: Client sends a postMessage call to check_session_iframe and postMessage returns ‘changed’.
The test will transition into FINISHED state when the above sequence is completed.
Submission of Results
Once you have finished testing, submit your results as described at Submission of Results for RPs. Note that separate submission files should be created 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.