MountainGoat · Single Sign-On

Sign in with Okta (OIDC): MountainGoat Configuration Guide

For Okta administrators connecting an Okta org to a MountainGoat instance.

This guide walks you through enabling Sign in with Okta for your MountainGoat instance using OpenID Connect (OIDC). At a glance:

Okta authenticates your users. MountainGoat authorizes them through its own roles, with optional mapping from your Okta groups.
You configure the integration in two places: the Okta Admin Console (add the app, assign users) and the MountainGoat Admin UI (paste the OIDC credentials).
Standard MountainGoat email and password login keeps working alongside SSO.

1.Overview

MountainGoat supports Okta as an OIDC single sign-on provider. When SSO is enabled, your users see a Sign in with Okta button on the MountainGoat login page and can also launch MountainGoat from their Okta dashboard tile.

Two systems share the work:

Okta handles authentication. It verifies who the user is and returns a signed ID token to MountainGoat.
MountainGoat handles authorization. Every user's access is governed by a MountainGoat role. You can assign those roles inside MountainGoat, and optionally let a user's Okta group membership set or raise their role automatically.

2.Prerequisites

Okta administrator access to add an application from the catalog and assign users or groups.
Your MountainGoat subdomain. Each production MountainGoat instance is reachable at https://{app.subdomain}.mountaingoat.ai. Throughout this guide, {app.subdomain} is a placeholder for your subdomain label. Replace it everywhere it appears with your own label (for example acme, producing acme.mountaingoat.ai).
A MountainGoat administrator account to enter the OIDC credentials in the MountainGoat Admin UI.

3.Supported features

The Okta and MountainGoat OIDC integration supports the following features:

SP-initiated SSO. Users start sign-in from the MountainGoat login page and authenticate with Okta.
IdP-initiated SSO. Users start sign-in from the MountainGoat tile on their Okta End-User Dashboard.
Just-In-Time (JIT) provisioning. When enabled, MountainGoat accounts are created automatically on first sign-in (see section 8).

The following features are not supported: Single Logout (SLO), SCIM provisioning, and force authentication.

4.Add MountainGoat from the Okta catalog

In the Okta Admin Console, browse the application catalog and add MountainGoat.
When prompted for your subdomain (sometimes labeled tenant), enter only your subdomain label. For example, enter acme, not the full domain acme.mountaingoat.ai and not a URL.
Assign the application to the users and groups who should have access.

Entering your subdomain label lets Okta generate the correct sign-in redirect and initiate login URIs automatically, so you never type those by hand. Replace {app.subdomain} in the values below with your own subdomain label (for example acme, producing acme.mountaingoat.ai):

Sign-in redirect URI https://{app.subdomain}.mountaingoat.ai/auth/okta/callback
Initiate login URI https://{app.subdomain}.mountaingoat.ai/auth/okta/initiate
SP-initiated login URL (open this to start SSO) https://{app.subdomain}.mountaingoat.ai/auth/okta/login

No Single Logout. MountainGoat does not support Single Logout, so no post-logout or sign-out redirect URI is required.

Test instance. The shared instance for review and testing is demo.mountaingoat.ai (for example, start SSO at https://demo.mountaingoat.ai/auth/okta/login). Production clients each use their own {app.subdomain}.mountaingoat.ai host.

Most setups need no claim configuration: users start as View only and your MountainGoat administrator assigns roles (see section 7). Only the optional automatic role mapping requires the ID token to carry a role or groups claim.

5.Get your OIDC credentials

From the application you just created, collect three values. You will paste them into MountainGoat in the next step.

Value	Where it comes from
Client ID	The application's client credentials.
Client Secret	The application's client credentials. The secret is shown once, so copy it now and store it securely. You can generate a new secret later if you lose it.
Okta org URL (Issuer)	Your Okta organization URL, for example `https://your-org.okta.com`. If your app uses a custom authorization server, use that issuer URL instead.

6.Enter the credentials in MountainGoat

Click Settings under the user profile.
Select the Admin tab → API & Credentials → SSO Credentials.

Fill in the fields below, then set Enabled to Yes.

MountainGoat field	What to enter
Enabled	Set to Yes to show the Sign in with Okta button. Set this last, after the required fields below are filled.
Issuer	Your Okta org URL, for example `https://your-org.okta.com`. No trailing path or slash.
Client ID	The Client ID from your Okta application.
Client Secret	The Client Secret from your Okta application. Stored encrypted and never displayed back. See the note below.
Redirect URI	`https://{app.subdomain}.mountaingoat.ai/auth/okta/callback`. Must match the sign-in redirect URI in Okta.
Initiate Login URI (optional)	`https://{app.subdomain}.mountaingoat.ai/auth/okta/initiate`. Set this to enable launching MountainGoat from the Okta dashboard tile.
Allowed Email Domains (optional)	Comma-separated domains, for example `acme.com, partner.com`. See section 9.
Default Role	Fallback role for auto-created users. Default is `view_only`. See section 7 and section 8.
JIT Mode	Controls whether unknown users can be created on first sign-in. Default is `strict`. See section 8.
Group Mappings (JSON) (optional)	Maps Okta groups to MountainGoat roles for optional automatic role mapping. Available on request; see section 7.

About the Client Secret. The secret is write-only in the Admin UI: you can enter or replace it, but MountainGoat never displays it back and stores it encrypted. On a later edit, leave the Client Secret blank to keep the existing secret. Only type in the field when you intend to replace it.

At minimum, Enabled, Issuer, Client ID, Client Secret, and Redirect URI must be set before the Sign in with Okta button appears. Save the form when you are done.

7.User roles and access

MountainGoat has five access roles: No access, View only, PO edit, Manager, and Full admin.

Role tiers

Role	What it grants
Full admin `full_admin`	Full administrator. All Admin tabs, PO Dashboard edit, and PO assignment rights.
Manager `manager`	PO Dashboard edit plus PO assignment management. No Admin access.
PO edit `po_edit`	PO Dashboard edit and can be assigned POs. No Admin or manager access.
View only `view_only`	PO Dashboard view-only access. Cannot be assigned POs.
No access `none`	No default application access.

How roles are assigned (recommended)

By default, everyone who signs in through Okta is created as View only. Your MountainGoat administrator then grants higher access as needed under Settings → Admin → Users. No Okta group configuration is required. Okta confirms who the person is, and MountainGoat controls what they can do.

Removing or unassigning a user in Okta stops them from signing in to MountainGoat, so offboarding stays centralized in Okta even though role levels are managed inside MountainGoat.

Optional: let Okta assign roles automatically

MountainGoat can assign role tiers automatically from Okta instead of having your administrator set each one by hand. This is available on request and, depending on your Okta configuration, may require working directly with Okta to set up.

8.Provisioning modes

The JIT Mode field controls what happens the first time someone signs in with Okta who does not yet have a MountainGoat account.

Recommended: set JIT Mode to view_only and Default Role to view_only. New users are created automatically as View only on first sign-in, and your MountainGoat administrator promotes them as needed (see section 7).

JIT Mode	Behavior
`view_only` recommended	Unknown users are created automatically on first sign-in and receive the Default Role, which is View only unless you change it. Your administrator promotes them as needed.
`mapped`	Unknown users are created automatically on first sign-in. Their role comes from the optional automatic mapping in section 7. If nothing matches, they receive the Default Role.
`strict` default	Only people who already have a MountainGoat account can sign in; unknown users are rejected. On first Okta sign-in, MountainGoat links the Okta identity to the existing account by verified email. Use this if you pre-create every account manually.

9.Restrict access by email domain (optional)

Use the Allowed Email Domains field to limit sign-in to specific email domains. Enter one or more domains separated by commas, for example acme.com, partner.com.

When this field is set, only users whose verified email domain appears in the list may sign in. Everyone else is denied with email_domain_not_allowed. Leave the field blank to allow any domain your Okta assignment permits.

This is a coarse allow-list. It complements, and does not replace, your Okta application assignments and MountainGoat roles.

10.Test sign-in

Verify the integration from both entry points:

From the MountainGoat login page. Open https://{app.subdomain}.mountaingoat.ai/ and choose Sign in with Okta. You should be redirected to Okta, authenticate, and land back in MountainGoat.
From the Okta dashboard. Click the MountainGoat tile. This uses the initiate login URI and requires the Initiate Login URI field to be set in MountainGoat.

With the recommended setup, a first-time Okta user appears as View only until an administrator promotes them (see section 7). That is expected, not an error.

Signing out of MountainGoat returns the user to the MountainGoat login page.

11.Troubleshooting

If a sign-in fails, MountainGoat shows a short error code. The customer-relevant codes are below.

Error code	Cause	Fix
`okta_not_configured`	SSO is disabled or a required field is missing.	Fill Issuer, Client ID, Client Secret, and Redirect URI, then set Enabled to Yes.
`unknown_user_strict_mode`	JIT Mode is `strict` and this Okta user has no matching MountainGoat account.	Create the user in MountainGoat first (matching their email), or switch JIT Mode to `view_only` or `mapped`.
`email_domain_not_allowed`	The user's email domain is not in Allowed Email Domains.	Add the domain to Allowed Email Domains, or clear the restriction.
`invalid_issuer`	The Issuer in MountainGoat does not match the token issuer from Okta.	Set Issuer to your exact Okta org URL, with no trailing path or slash.
`invalid_audience`	The Client ID in MountainGoat does not match the application that issued the token.	Confirm the Client ID matches the Okta application assigned to the user.
`account_link_conflict`	The MountainGoat account for this email is already linked to a different Okta identity.	Contact MountainGoat support to reconcile the account link.
`inactive_user`	The matched MountainGoat account is deactivated.	Reactivate the user in MountainGoat, or have an administrator grant access.
`email_not_verified`	Okta sent an email claim marked as unverified.	Verify the user's email in Okta, then sign in again.
`expired_token`	The ID token had already expired when it reached MountainGoat.	Start sign-in again. If it keeps happening, confirm the system clocks are accurate.
`token_exchange_auth_failed`	Okta rejected MountainGoat's client credentials during the token exchange.	Re-check the Client ID, and re-enter the Client Secret in MountainGoat.
`invalid_state`, `invalid_nonce`	The sign-in session did not match, often from an old or reused callback link.	Start sign-in again from the MountainGoat login page.

12.Security and privacy notes

The Client Secret stays on the backend. In the Admin UI the Client Secret field is write-only. MountainGoat never displays the secret and stores it encrypted at rest.
Authorization is enforced by MountainGoat roles. Okta establishes identity; a user's actual access is always determined by their MountainGoat role, whether it was assigned directly or through a group mapping.
Every sign-in is validated. MountainGoat verifies the ID token signature, issuer, audience, nonce, and expiry before creating a session.
Local login coexists. Email and password sign-in continues to work alongside Okta SSO, so administrators keep a recovery path.
Deactivating a user in Okta blocks future SSO sign-in. Once you unassign or deactivate a user in Okta, they can no longer sign in through Okta. Review their MountainGoat account as well if you also want to remove existing local access.
Least scope. MountainGoat requests only the openid, email, and profile scopes.

13.Support

For help configuring Sign in with Okta for MountainGoat, contact:

help@mountaingoat.ai