Your360 Setup guide

OIDC single sign-on

Let your team sign in to Your360 with Okta over OIDC — and, optionally, sign people out of Your360 the moment an admin ends their Okta sessions.

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

Work on the Authentication tab there alongside your Okta Admin Console.

Adding the Your360 app from the Okta catalog fills in the redirect URI for you, 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 — and SAML 2.0 is selected by default: scroll past the SAML settings to the bottom of the page and select the OpenID Connect radio button instead. The app arrives with our redirect URI already registered — Okta fills it 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 register our redirect URI yourself, and the manual section covers it.

2. Give Your360 the client credentials

  1. Copy issuer + client ID/secret from Okta

    On an OIN catalog app the SSO details live in the Sign On tab, under Sign-on methods (hand-built apps show them under General → Client Credentials instead). Copy the Client ID and the Client secret (use the eye icon to reveal or the copy icon). Your issuer is your Okta domain, e.g. https://acme.okta.com.

    Okta OIN app Sign On tab — Client ID and Client secret highlighted under Sign-on methods
    OIN catalog app → Sign On tab → Sign-on methods (OpenID Connect) — Client ID and the Client secret row.

  2. Create the connection in Your360

    Open the Single sign-on card, click + Add, keep provider Okta, and choose protocol OIDC.

    Your360 SSO card in OIDC mode with the issuer, client ID and secret fields
    Your360 → Organization Settings → Authentication → Single sign-on (OIDC).
    Your360 fieldFrom Okta
    Issuer←Your Okta domain, e.g. https://acme.okta.com
    Client ID←Client ID
    Client secret←Client secret

    Add your email domains, then Save connection. Names arrive automatically from the OIDC profile scope. Test a sign-in from app.your360.ai/auth/signin.

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.

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

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

The catalog app ships with the Initiate login URI already set, so the tile works as soon as people are assigned. On a hand-built app, set it to https://app.your360.ai/api/sso/oidc/start — see the Manual setup.

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.

Okta shows a redirect_uri error (400)

The app’s registered Sign-in redirect URI doesn’t exactly match ours. On a hand-built app, re-copy it from Identity provider URLs in the Your360 SSO card — no trailing slash, no extra path. Catalog installs get it automatically.

“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 rejects the sign-in with an invalid client error (401)

The client secret or issuer saved in Your360 is wrong. The issuer must be your bare Okta domain — https://acme.okta.com — with no /oauth2/… path after it. Re-copy both from the Okta app’s Client Credentials section and save again.

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

Build it with a generic OIDC app; it works the same. The only difference is that you register our redirect URI yourself instead of Okta filling it in.

  1. In Okta: Applications → Create App Integration → OIDC — Web Application, grant type Authorization Code. For dashboard-tile launches, set Initiate login URI to https://app.your360.ai/api/sso/oidc/start — it is the same for every organization.

  2. Copy our redirect URI: in Your360, open the Single sign-on card and expand Identity provider URLs. OIDC apps need the third one. Nothing has to be created first — it exists before any connection is saved, and it is 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. Register it as the app's Sign-in redirect URI.

    Okta OIDC app General settings — Login section with the Sign-in redirect URIs field highlighted
    Okta app → General → General Settings → Edit → LOGIN → Sign-in redirect URIs (use + Add URI if needed). The pictured value is the real one for app.your360.ai — copy from your own settings page if your Your360 lives on another host.

    In Your360 you can pick provider Other provider for generic wording.

  4. Copy the client ID, client secret and your Okta domain into Your360 (step 2 above) and save.

  5. Universal Logout works the same on a manual OIDC 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.

    Saved OIDC connection row with the Universal Logout section
    The saved connection row, with the Universal Logout endpoint and setup steps.

    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
    Okta Logout → Global token revocation with the Endpoint URL and Email Identifier highlighted
    Okta app → Logout → Global token revocation. Okta calls the field Endpoint URL — paste Your360’s Logout request URL there.

    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.