Prepare enterprise SSO

Use this checklist to prepare company sign-in to Gosset. Your identity provider confirms who you are; Gosset controls which account and products you can access.

Setting up a new company connection? Start with the access checklist below. For Keycloak, prepare a pilot. For Google Workspace or Microsoft Entra ID, follow the setup steps once Gosset supplies your redirect URI. If your connection is already active, use the sign-in link from Gosset. Individual users do not register an application.

Availability

Custom enterprise OIDC connections, including Keycloak, require additional implementation and Gosset activation. Creating an identity-provider application does not enable access. Gosset confirms availability and the test plan before production setup.

1. Tell us who needs access

Contact [email protected]. Share the following privately through the agreed onboarding channel:

Who	What we need
Your business owner	Gosset organization/account or contract, initial users and approximate seat count, required products/features, and whether contractors or guests are eligible.
Your IT team	Identity-provider product, preferred protocol, test/production environment, technical contact and any mandatory MFA, network or access restrictions.
Users, or your business owner	Work email and existing Gosset login email, if any. No passwords or technical SSO configuration are needed from users.

Your business owner confirms eligibility; IT configures the identity provider. Gosset sets up the connection and organization mapping, provisions agreed product access, and approves new accounts and account links. Customer administrators cannot currently approve Gosset requests themselves.

OpenID Connect (OIDC) is the proposed route for Keycloak. If SAML is required, confirm availability with Gosset before registering an application.

2. Prepare the connection details

For Google Workspace and Microsoft Entra ID, use the provider steps below. For a custom OIDC provider, your IT team also supplies these details:

Detail	What to provide
Identity provider	Exact issuer and OIDC discovery URL for each environment; any private-network or IP-allowlist requirements.
Application	Client ID, required client authentication method and ID-token signing algorithm. Arrange secure delivery of any client secret or other credential.
User information	A stable user identifier (sub), email and its verification status, and name; whether these appear in the ID token or UserInfo response. If eligibility relies on claims, specify the exact names, values and rules.
Testing	A nominated tester and a user who should be denied access. Testers use their own credentials.

Users' browsers must reach the provider's sign-in page. Gosset's servers must reach its token and signing-key endpoints, plus discovery/UserInfo where used. Agree any network restrictions before testing.

Tell us which existing accounts must be retained. Linking needs verified ownership and Gosset approval; a matching email alone is insufficient. Gosset must confirm a supported linking method if the provider's email is missing, unverified or different from the existing login.

Keep credentials and your completed connection details out of public documents and issue trackers. Gosset will agree a secure credential-transfer method with your IT team.

3. Register the application with your IT team

After Gosset confirms the connection design, register a confidential web application using the authorization code flow with PKCE (S256). Confirm the client authentication and signing configuration with Gosset. Start with the openid profile email scopes; agree any additional claims before adding them.

Gosset supplies the exact redirect URI for each environment. Register it exactly as provided, using separate test and production clients and credentials. Signing out of Gosset does not currently sign you out of your identity provider.

Google Workspace

1. In Google Cloud Console, select a project owned by your Workspace organization. Under Google Auth Platform → Branding, set the application name and support contact. For sign-in within your organization, select Internal under Audience.
2. Go to Clients → Create client → Web application. Under Authorized redirect URIs, add the exact URI Gosset supplied for this environment. Gosset requests only the openid, email and profile scopes; no Gmail or Drive access is needed.
3. Give Gosset the client ID and the Workspace hosted domains to allow. Transfer the client secret through the agreed secure channel. Gosset checks Google's verified email and signed hosted domain; an email suffix alone does not establish company membership.
4. Test with an eligible Workspace account and confirm a personal Gmail account cannot use the company connection. First-time access still requires Gosset approval.

Google instructions: Configure the consent screen · Create a web client.

Microsoft Entra ID

1. In the Microsoft Entra admin center, switch to your company directory. Go to Entra ID → App registrations → New registration, name the app (for example, Gosset Sign-in), and select Multiple Entra ID tenants (work or school accounts in any organizational directory). Gosset's current flow does not support single-tenant registrations or personal Microsoft accounts.
2. For Redirect URI, select Web and paste the exact URI Gosset supplied for this connection and environment. Register the app. Gosset requests only openid, email and profile; no Microsoft Graph business-data permissions or implicit grant are needed. If user consent is restricted, ask your tenant administrator to review these sign-in permissions.
3. From Overview, give Gosset the Application (client) ID and Directory (tenant) ID for the company connection. Under Certificates & secrets → Client secrets → New client secret, choose an expiry and copy the Value (not the Secret ID) when shown. Transfer the value through the agreed secure channel and provide its expiry. Certificate-based client authentication is not currently supported.
4. Gosset restricts the company connection to the agreed tenant IDs; the general Microsoft sign-in button does not assign company membership. A tenant can include guests. For a limited pilot, restrict the enterprise app to assigned users or groups. Test an eligible work account and an account from a different, unapproved tenant. Gosset still reviews first-time access.

Microsoft instructions: Register an application · Add client credentials.

Keycloak: prepare a pilot

Keycloak is your identity provider; OpenID Connect (OIDC) is the standard it uses to confirm a user's identity to Gosset. Gosset approves access. A Keycloak connection requires implementation and activation by Gosset before sign-in can be tested.

1. IT: Share your technical contact, who should have pilot access, and the test realm's discovery URL. It usually ends in /realms/{realm-name}/.well-known/openid-configuration.
2. Gosset: Review the realm settings with IT, confirm compatibility, and supply the exact test redirect URI and agreed client authentication method.
3. IT: In the test realm, create an OpenID Connect client under Clients → Create client. Turn Client authentication and Standard flow on; keep Implicit flow and Direct access grants off. Set PKCE method to S256 and enter the exact Gosset URI under Valid redirect URIs. Give Gosset the client ID and transfer the agreed credential through the secure channel.
4. Together: After Gosset implements and activates the test connection, check that an eligible user can sign in after Gosset approval and that an ineligible user cannot access the organization.

4. Test and activate together

Together, verify sign-in, administrator approval, existing-account linking, the correct organization and required product features. Confirm an ineligible user is denied and IT's MFA policy is enforced by the identity provider. Gosset confirms activation after these checks pass.

For users: Gosset supplies the sign-in link and provider choice. If you see Awaiting admin approval, share the request ID with support. Once Gosset confirms approval, return and sign in with the same identity.

Before activation, name the contacts who report departures and coordinate client-credential expiry or rotation. Agree how Gosset access, active sessions and API keys will be revoked. Disabling someone at the identity provider alone does not revoke their existing Gosset sessions or API keys.

Raise requirements for enforced SSO, group-to-role mapping, single logout or automated user removal during onboarding. These require separate agreement and may need implementation. Include API keys and MCP connections explicitly in offboarding requirements.