OPENID CONNECT · LAB
Run the OpenID conformance suite against your tenant
Run the Basic OpenID Provider test plan against your tenant, match each test to the tenant's Audit and Logs, and optionally test your own callback handler with the suite playing the provider.
Partly readyUses your lab tenant
The lesson
Builds on: Implementing a relying party.
New to the labs? Start with the lab toolkit and the shared cast and names every lab uses.
Partly ready. Most of this lab runs today. Steps that wait on platform features are marked, and Missing infrastructure says what they need.
- G9 Dynamic client registration and registration management
- G17 OIDC logout: RP-initiated, front-channel, back-channel, session management
Your progress
Press Start before you begin. Only events your tenant records after that count, in the order below. Checking reads your tenant's Audit, so you need Audit read access in it.
Sign in to start this lab and check your progress. Log in or create an account.
Create the conformance test clients
Recorded as
tenant.oauth.clients.createsucceeded.Complete a suite sign-in as the test user
Recorded as
oauth.authorizesucceeded (code_issued) forlab-tmp-conformance-1.Answer the suite's prompt=none test with login_required
Recorded as
oauth.authorizerejected (login_required) forlab-tmp-conformance-1.Refuse the suite's reused code
Recorded as
oauth.tokenrejected (code_replayed) forlab-tmp-conformance-1.
Setup
The OpenID Foundation's conformance suite is an external tool, and this lab has not yet been run end to end against a tenant, so treat the first run as an exploration. The Dynamic profile (G9) and the Logout profiles (G17) cannot pass today.
Choose the suite: the hosted instance at
https://www.certification.openid.net/, where you sign in with your own account, or a local copy of the suite's open-source repository run with Docker. Both can reach your tenant:*.beyondthelogin.devis public HTTPS, the suite calls discovery, JWKS, token and UserInfo from its own servers, and the authorization step runs in your browser.Two things to watch on the first run: server-to-server calls from the suite must not be challenged by bot protection in front of the tenant, and long plans must stay within the tenant's protocol rate limits. A
429withRetry-Aftermeans run the modules one at a time.Press Start. In Lab Photos, create
lab-tmp-conformance-1andlab-tmp-conformance-2from the Web preset: confidential,client_secret_basic, scopesopenid profile email, each with the exact redirect URI the suite shows for your test alias. These secrets go into a third-party tool, so use only these temporary clients.Give one test user a full profile: first name, last name and email.
Walkthrough
Create a test plan for the OpenID Connect Core Basic provider profile: server metadata from discovery (
$ISSUER/.well-known/openid-configuration), static client registration,client_secret_basic, and response typecode.
Why it matters: a plan tests one profile in one configuration, and its result says nothing about the others.
Run the plan. Each browser test opens your tenant's authorization endpoint, and you sign in as the test user. Tests whose correct result is a page, such as a forced sign-in for
prompt=loginor a shortmax_age, ask you to upload a screenshot.
Why it matters: some correct behavior is a page only a person can see, and the result waits for review.
For each test, find the tenant's evidence in Audit for
lab-tmp-conformance-1, by time:code_replayedfor the reused-code test,login_requiredforprompt=nonewithout a session, and a realuser_signed_infor themax_agetest.
Why it matters: the suite judges the messages; your Audit shows what the tenant decided and why.
Record which tests the suite skips or warns on, and match each to discovery:
curl -s "$ISSUER/.well-known/openid-configuration" | jq '{claims_parameter_supported, request_parameter_supported, scopes_supported}'
claims_parameter_supported and request_parameter_supported are false, and there are no address or phone scopes.
Why it matters: a provider is tested only against what it advertises, so honest metadata shapes the result.
Run the Config and Form Post plans. With the settings from Deliver one sign-in by query, fragment and form post re-enabled on Flow policy and
lab-tmp-conformance-1, run the Implicit and Hybrid plans too.
Restore: remove the implicit and hybrid response types and the implicit grant from Flow policy and lab-tmp-conformance-1 when those plans finish.
Optional, the relying-party side. Point your callback handler at the suite as its provider (the suite issues the discovery URL, the client and the keys) and run the Basic relying-party plan. The suite sends deliberately wrong ID tokens: a bad signature, the wrong
iss,audornonce, nosub. A test passes when your handler makes no further request.
Why it matters: a relying party's most important job is to refuse, and here someone else wrote the cases.
Write down what a pass would and would not prove for your tenant: this configuration, this date, the protocol only, not accounts or sessions.
Break it
Change the configuration and see a result go stale. Before a re-run, set
lab-tmp-conformance-1's consent mode to Always and see which tests now need extra screenshots or time out.
Restore: set the consent mode back to Remember. A configuration change is what invalidates an earlier result.
Check your work
Press Check my progress. The checks look for the two temporary clients, a sign-in the suite completed, the tenant's login_required answer to its silent test, and its refusal of the reused code.
Keep the suite's exported results locally, with your list of skipped tests tied to discovery fields.
Cleanup
Delete
lab-tmp-conformance-1andlab-tmp-conformance-2: their secrets were entered into a third-party tool.Restore Flow policy if you changed it for the Implicit and Hybrid plans.
Missing infrastructure
G9 (dynamic client registration). The Dynamic profile needs a registration endpoint;
/oauth/registeranswers 501 today.G17 (OIDC logout). The RP-initiated, session management, front-channel and back-channel Logout profiles each need their logout mechanism.