Beta

Create a tenant

A new tenant starts with its own users, OAuth settings, audit history and logs. You are its first Tenant Admin.

BTL Admin

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.

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.

  1. Create the conformance test clients

    Recorded as tenant.oauth.clients.create succeeded.

  2. Complete a suite sign-in as the test user

    Recorded as oauth.authorize succeeded (code_issued) for lab-tmp-conformance-1.

  3. Answer the suite's prompt=none test with login_required

    Recorded as oauth.authorize rejected (login_required) for lab-tmp-conformance-1.

  4. Refuse the suite's reused code

    Recorded as oauth.token rejected (code_replayed) for lab-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.

  1. 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.dev is public HTTPS, the suite calls discovery, JWKS, token and UserInfo from its own servers, and the authorization step runs in your browser.

  2. 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 429 with Retry-After means run the modules one at a time.

  3. Press Start. In Lab Photos, create lab-tmp-conformance-1 and lab-tmp-conformance-2 from the Web preset: confidential, client_secret_basic, scopes openid 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.

  4. Give one test user a full profile: first name, last name and email.

Walkthrough

  1. 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 type code.

Why it matters: a plan tests one profile in one configuration, and its result says nothing about the others.

  1. 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=login or a short max_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.

  1. For each test, find the tenant's evidence in Audit for lab-tmp-conformance-1, by time: code_replayed for the reused-code test, login_required for prompt=none without a session, and a real user_signed_in for the max_age test.

Why it matters: the suite judges the messages; your Audit shows what the tenant decided and why.

  1. 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.

  1. 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.

  1. 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, aud or nonce, no sub. 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.

  1. 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

  1. 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

  1. Delete lab-tmp-conformance-1 and lab-tmp-conformance-2: their secrets were entered into a third-party tool.

  2. 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/register answers 501 today.

  • G17 (OIDC logout). The RP-initiated, session management, front-channel and back-channel Logout profiles each need their logout mechanism.

Back to all labs

We value your privacy

We use cookies and similar technologies to enhance your browsing experience, and analytics to understand our traffic. By clicking "Allow All", you consent to optional analytics. Cookie Policy

The Lab