How do you connect Okta single sign-on to YAGNI?

What do you need before you start?

Three things: an Okta administrator, the YAGNI workspace owner (only the owner can change SSO settings; admins get a read-only view), and SSO switched on for your workspace. SSO (SAML) is part of the Orbit plan; if your Settings → Single sign-on page shows a locked state, talk to us and we will activate it for your rollout.

YAGNI speaks SAML 2.0, so the same steps work for Microsoft Entra ID and Google Workspace. This lesson uses Okta’s labels.

How do you create the Okta app?

1. In the Okta Admin Console, go to Applications → Create App Integration and choose SAML 2.0. Name it YAGNI.
2. Okta asks for service-provider URLs before YAGNI has generated them, so enter a placeholder (for example https://yagni.app/placeholder) for both Single sign on URL and Audience URI, and complete the app creation flow.
3. On the app’s Sign On tab, find the metadata: either copy the Metadata URL’s document or use “View SAML setup instructions”.

How do you exchange values between Okta and YAGNI?

In YAGNI, the owner opens Settings → Single sign-on and clicks Import from IdP metadata XML. Paste the metadata document and the entity ID, sign-in URL, and signing certificate fill themselves, with no hand-copying. (You can also paste the three values individually; the certificate is accepted as PEM or raw base64.)

Add your Allowed email domains (your company domain; public mailbox providers are not accepted), leave SSO enabled off, and Save. This draft save generates your workspace’s service-provider values in the section below the form:

YAGNI shows	Paste into Okta
ACS URL	Single sign on URL
Entity ID	Audience URI (SP Entity ID)

Edit the Okta app’s SAML settings, replace the placeholders with these two values, set Name ID format to EmailAddress and Application username to Email, and keep Okta’s defaults of signed assertions with SHA-256.

How do you map Okta groups to YAGNI roles?

Assign the app to Okta groups rather than individuals, for example yagni-users for everyone and yagni-admins for the people who should manage the workspace. Then, in the Okta app’s SAML settings, add a Group Attribute Statement named groups filtered to those group names.

In YAGNI, list the admin group under Admin groups. On every sign-in, people in that group arrive as workspace admins and everyone else as members: promotion and demotion follow your Okta groups automatically. Two safety rails: owners are never changed by SSO, and if an assertion carries no group attribute at all, YAGNI leaves roles exactly as they are.

Leave Admin groups empty if you would rather manage roles by hand in Settings → Members.

How do you enable and test it?

Flip SSO enabled and save. Enabling requires the workspace to already have a member with an email at each allowed domain, as proof the domain is really yours.

Then test from a private browser window: on the sign-in page choose Use single sign-on, enter a work email, and you are handed to Okta and back into YAGNI. New teammates are created on their first sign-in as members; someone who already has a YAGNI account at your domain joins automatically when Auto-join existing accounts is on (otherwise they need an invite first).

Two optional switches to finish the rollout:

• Allow IdP-initiated sign-in makes the YAGNI tile on the Okta dashboard work, so people can launch straight from Okta.
• Require SSO for members means members must use SSO from then on. Owners and admins keep Google sign-in as break-glass access, so an Okta outage can never lock the whole workspace out. Most teams flip this after a few days of clean sign-ins.

How do you handle certificate rotation and offboarding?

When Okta schedules a certificate rollover, paste the incoming certificate into Standby signing certificate ahead of time. YAGNI accepts assertions signed by either certificate, so nothing breaks at the switchover. The settings page shows each certificate’s expiry date and warns 30 days out.

To offboard someone, remove them from the app’s Okta group (new SSO sign-ins stop immediately), then remove their membership in Settings → Members. If they used YAGNI Code, revoke their device token from the same admin surface.