Your360 Setup guide

SAML single sign-on

Let your team sign in to Your360 with Okta over SAML 2.0.

Supported features

FeatureNotes
SP-initiated SSO✓Sign-in starts at app.your360.ai/auth/signin — the single sign-on option routes people at your registered email domains to Okta.
IdP-initiated SSO✓Clicking the Your360 tile on the Okta End-User Dashboard signs the person straight in.
Just-in-time provisioning✓The first Okta sign-in creates the Your360 account — there is nothing to pre-create.
Universal Logout✓Okta’s Global Token Revocation, optional — see step 4.
Single Logout (SLO)—Not supported.

Prerequisites

In Okta, you need an admin role that can create app integrations and assign people to them — Super Administrator or Application Administrator.

In Your360, you need an Organization Admin account. There is no menu link to the settings page — sign in, then go directly to:

https://app.your360.ai/organization/settings

Everything below happens on the Authentication tab there, and in your Okta Admin Console.

Adding the Your360 app from the Okta catalog fills in the URLs Okta needs, so there is nothing to paste in that direction — you only bring Okta's own values back to Your360.

1. Add the Your360 app in Okta

  1. Add the Your360 app

    Find Your360 in the Okta App Catalog (Applications → Browse App Catalog), click + Add Integration, and give the app a label. The sign-on options page that follows is where the protocol is chosen: SAML 2.0 is the radio button selected by default — for SAML, leave it as it is. The app arrives with our ACS URL and entity ID already set — Okta fills them in from our published integration, so there is nothing to copy across.

    Don’t see Your360 in the catalog? Use the Manual setup at the bottom of this page instead — start there, then come back to step 2. A hand-built app is where you do have to paste our URLs yourself, and the manual section covers it.

2. Take the Okta metadata back to Your360

  1. Copy the IdP metadata from Okta

    On an OIN catalog app the SSO details live in the Authentication tab (hand-built apps show them under Sign On instead). There, under Metadata details, copy the Metadata URL and open it in a new tab — that’s the metadata document.

    On a hand-built app: Sign On tab → SAML Signing Certificates → on the active SHA-2 certificate, Actions → View IdP metadata.

    Okta SAML Signing Certificates — Actions menu with View IdP metadata highlighted
    Hand-built app → Sign On tab → SAML Signing Certificates → Actions → View IdP metadata.

  2. Create the connection in Your360

    Back on the settings page, open the Single sign-on card, click + Add, keep provider Okta and protocol SAML 2.0. Paste the whole metadata XML into Identity provider metadata — we read the issuer, sign-on URL and certificate from it. Add your email domains (e.g. acme.com) so people at those domains are routed to Okta, then click Save connection.

    Your360 SSO card in SAML mode with the metadata field and email domains
    Your360 → Organization Settings → Authentication → Single sign-on (SAML).

3. Attributes sent in the SAML assertion

The Your360 catalog app sends these attribute statements automatically — there is nothing to configure:

Attribute nameOkta value
email=user.email — required; identifies the account
firstName=user.firstName — optional; keeps the profile complete
lastName=user.lastName — optional; keeps the profile complete

If the email attribute is ever missing, we fall back to the Subject NameID when it carries an email address (the emailAddress format, or a value that is plainly one). Without a name source we can sign people in but cannot record their name, so keep the attribute statements in place on a hand-built app (see the manual setup below).

Attribute statements note in the Your360 SSO card
What the settings page tells you about attributes.

That’s it

Assign people to the Your360 app in Okta so they can use it, then test a real sign-in from app.your360.ai/auth/signin with an account at one of your registered domains — or straight from the app’s tile on the Okta End-User Dashboard.

Rolling out to your team

Saving the connection makes Okta available to everyone at the listed email domains — it doesn’t force anyone. Single sign-on is an explicit option on the regular sign-in page, so there is no separate backup sign-in URL to keep: email/password and the other sign-in methods stay where they always were.

Existing accounts move over on their own: the first successful Okta sign-in converts the account to SSO — including yours, so you can test the connection you just saved. The move is one-way; once converted, the account signs in through Okta from then on, and any old password is cleared.

Nothing forces the switch, though: someone who never uses the Okta option keeps signing in the way they always have, so a misconfigured connection locks nobody out — fix it under Organization Settings → Authentication and try again.

4. Set up Universal Logout (optional)

Universal Logout (Okta’s Global Token Revocation) lets Okta tell us to end a person’s Your360 sessions when Okta decides they should be signed out. Okta offers the same Logout section on SAML apps as on OIDC apps.

The catalog app arrives with the logout endpoint pre-configured — Okta fills it in from our published integration, so there is no URL to copy. You only enable it:

  1. Enable it in the Okta app

    In the Okta app, open the Logout section (under General settings; some orgs show it on the Sign On tab). Under Global token revocation, set App logs out when to Okta system or admin initiates logout and save — the endpoint URL, Signed JWT authentication and subject format are already filled in.

    Test it: in the Admin Console, go to Directory → People, pick a user, then More Actions → Clear User Sessions — their next request in Your360 then requires signing in again.

Only a hand-built app needs the endpoint pasted in yourself — the manual section covers it.

Signing in

SP-initiated SSO

  1. Go to app.your360.ai/auth/signin and click Sign in with single sign-on.

  2. Enter your work email address and click Continue — the email’s domain routes you to your Okta organization’s sign-in page.

  3. Authenticate with Okta (if you already have an Okta session, this is automatic). You land back in Your360 signed in; a first sign-in creates the account (just-in-time provisioning).

IdP-initiated SSO

  1. An Okta admin assigns the person (or their group) to the Your360 app — Assignments tab on the app.

  2. The person opens their Okta End-User Dashboard and clicks the Your360 tile.

  3. They land in Your360 signed in — no Your360 credentials are involved. A first sign-in creates the account (just-in-time provisioning).

IdP-initiated sign-in works as soon as the connection is saved — there is nothing extra to configure on either side.

Troubleshooting

“Single sign-on is not set up for that email domain.”

The address typed on the sign-in page belongs to a domain the connection doesn’t list. Add the domain under email domains on the connection and save — routing is by email domain, nothing else.

The sign-in comes back with an email attribute error

The assertion arrived without an email. The catalog app releases it automatically; on a hand-built app, add the Attribute Statements from the manual setup below — the email one is mandatory, the names keep profiles complete.

The assertion is rejected after Okta rotates or changes certificates

The metadata saved in Your360 carries the signing certificate, so it goes stale if the app’s certificate changes or the metadata came from a different Okta app. Re-copy the IdP metadata from the active SHA-2 certificate (step 2) and save the connection again.

“This email is already registered. Please sign in with …”

The account has already been converted to Okta single sign-on — a password, Google or Slack sign-in is refused after that. Use the single sign-on option on the sign-in page instead.

Okta says the user is not assigned to the application

Assign the person (or their group) to the Your360 app in Okta — Assignments tab on the app — and have them retry.

Manual setup — if Your360 isn’t in your Okta catalog

You can build the connection by hand with a generic SAML app; it behaves identically. The only difference is that you supply our two URLs yourself instead of Okta filling them in.

  1. In Okta: Applications → Create App Integration → SAML 2.0.

  2. Copy our two URLs: in Your360, open the Single sign-on card and expand Identity provider URLs. SAML apps need the first two. Nothing has to be created first — these exist before any connection is saved, and they are the same for every organization.

    Identity provider URLs section listing the ACS URL, entity ID and OIDC redirect URI
    Your360 → Organization Settings → Authentication → Single sign-on → Identity provider URLs.

  3. Paste them into the Okta app’s SAML settings:

    Okta fieldYour360 value
    Single sign-on URL←Single sign-on URL (ACS)
    Audience URI (SP Entity ID)←Audience URI (SP Entity ID)
    Okta Configure SAML page with the Single sign-on URL and Audience URI fields highlighted
    Okta app → Configure SAML. The pictured values are the real ones for app.your360.ai — copy from your own settings page if your Your360 lives on another host.

    In Your360, pick provider Other provider if you prefer generic wording.

  4. Add these Attribute Statements (Name → Value), since a hand-built app sends none by default:
    NameValue
    email=user.profile.email
    firstName=user.profile.firstName
    lastName=user.profile.lastName
  5. Copy the IdP metadata into Your360 (step 2 above), assign yourself to the app, and save.

  6. Universal Logout works the same on a manual SAML app, except the endpoint is not pre-filled — you paste it yourself. Copy the Logout request URL from Your360, listed under Identity provider URLs on the SSO card.

    In the Okta app, open the Logout section (under General settings; some orgs show it on the Sign On tab). Under Global token revocation:

    Okta fieldValue
    App logs out when=Okta system or admin initiates logout
    Endpoint URL←Logout request URL from Your360
    Endpoint authentication type=Signed JWT nothing to paste
    Subject format=Email Identifier

    On a hand-built app, this requires Okta Identity Threat Protection

    Unlike the catalog app, a hand-built integration only receives the logout call from Okta Identity Threat Protection (ITP) — its session-protection / entity-risk policies — or, with Adaptive MFA only, when an admin triggers it manually from the user’s risk profile. It is not sent by deactivating a user or clearing their sessions. Without ITP or AMFA you can save this endpoint, but Okta will never call it.