Partner sign-on (silent SSO)

Lurno has no self-serve SAML or OIDC setup. What it does have is partner sign-on: your own system authenticates the person, then hands them across to Lurno with a code. Lurno exchanges that code for a session and drops them straight into their learning — they never see a Lurno sign-in form. You turn it on and manage its API key from Organization settings → Integration.

What this does

Enabling partner sign-on creates one partner identity rooted at your top-level organization, and it governs that organization and every sub-organization beneath it. Three things come out of it:

An API key — the secret your system authenticates with. It is shown once, at the moment you enable (or rotate) it, and can never be retrieved again.
An API base URL — where your system sends its calls.
An account code per organization — a short, non-secret code for your top-level organization and for each sub-organization. The account code tells Lurno which organization a person belongs to. New sub-organizations get a code automatically.

Your system uses the key and the relevant account code to create a person in Lurno, and gets an identifier back for them. To sign that person in later, your system exchanges that identifier for a Lurno session — the person arrives already signed in and never sees a Lurno sign-in form.

Partner sign-on provisions learners only. Requesting any other role is rejected, so admins and instructors are still invited the normal way. See Inviting people.

Talk to Lurno before you build against this. The API behind the key is a compatibility surface that Lurno maintains for existing partners and intends to replace with the signed-assertion handoff described below, so it’s worth confirming the direction with them first.

Open Organization settings → Sign-in methods to see what your members can currently use. Today only Email & password is enabled. Single sign-on (SSO/SAML), Passkeys / WebAuthn, and Multi-factor authentication are all listed as Coming soon — that panel is informational, and there is nothing to configure on it yet.

There is also a second, newer handoff that verifies a signed assertion from your identity system instead of a stored identifier. Instead of returning a session to your system, it redirects the person to Lurno with a single-use link that signs them in and drops them into their learning area. That flow is set up by Lurno, not self-serve — there is no screen for it in the product, and the Enable partner integration button does not create one. Contact Lurno if you want it.

Before you start

You need permission to update the organization.
You must be on your top-level organization. The Integration tab on a sub-organization is read-only: it shows that sub-organization’s account code and says key management lives at the parent.
You need a developer on your side. Everything past “copy the key” is server-to-server work in your own system.
Have somewhere secure to store the key before you click enable — you get exactly one chance to copy it.

Turn on partner sign-on

Go to Organization settings and open the Integration tab.
Select Enable partner integration.
The Your API key dialog appears with the warning “Copy this now — you won’t be able to see it again.” Copy the key and store it in your own secret manager, then select Done.
The panel now shows an Enabled status, the API base URL, and this organization’s Account code. Copy both to your developer.
Under Sub-organization account codes, copy the code for each sub-organization your system will place people into. If you have none yet, the panel says so — codes are minted automatically as you create sub-organizations.

If you lose the key before storing it, you cannot recover it. Rotate it (below) to get a new one.

Rotate the API key

Rotate on a schedule, or immediately if the key may have been exposed.

Open Organization settings → Integration.
Select Rotate API key.
Confirm in the Rotate the API key? dialog. Its warning is accurate: “A new key will be generated and shown once. The old key stops working immediately, so update your systems before rotating.”
Copy the new key from the reveal dialog and install it in your system.

Rotation is immediate and it is not staged. There is no grace period and no second active key. From the moment you confirm, every call your system makes with the old key fails until the new one is installed. Plan the rotation with whoever operates the integration and do it in a maintenance window.

Reference

Item	What it is
Enable partner integration	One-time action on a top-level organization. Creates the partner identity and the first API key.
API key	Secret, shown once on enable and once on each rotation. Stored only as a hash — Lurno cannot show it to you again.
API base URL	The address your system calls. Read-only, with a copy button.
Account code	Short non-secret code identifying one organization in your tree. Used to route a person to the right sub-organization.
Sub-organization account codes	Table of every sub-organization and its code, each copyable.
Rotate API key	Issues a new key and kills the old one immediately.

Troubleshooting

There’s no Integration tab in Organization settings. The tab only renders for people who can update that organization — and without that permission, Organization settings won’t open at all. Ask someone who has it, or see Roles & permissions.

The Enable button isn’t there and I only see an account code. You are on a sub-organization. The panel says “Key management lives at the parent organization.” Switch to your top-level organization to enable or rotate.

Your system started getting rejected right after a rotation. That is the expected behavior — the old key stopped working the instant you confirmed. Install the new key everywhere it is used.

You lost the API key. It cannot be recovered. Rotate to issue a new one, and be ready for the outage that rotation causes until the new key is deployed.

Sign-in is rejected as an unknown identifier. The identifier your system sent doesn’t match a person Lurno provisioned through this partner integration — usually because it was mistyped, truncated, or created against a different organization tree. Have your system store the identifier it received at sign-up and send it back unchanged.

Sign-in is rejected because the account isn’t active. The person exists but is no longer an active member of the organization their account code points at. Check their membership, and check that your system used the right account code. See Offboarding & data requests if they were removed.

Someone lands on the Lurno sign-in page with “Your sign-in link expired” or “Access unavailable”. Those messages come from the signed-assertion handoff, not from the setup on this page. The single-use link was already used or has passed its short lifetime, or the person isn’t an active member. Contact Lurno — that flow is configured by them.