How to Set Up SSO for Your Engineering Team

# How to Set Up SSO for Your Engineering Team

Every tool your team uses is one more password, one more place to be phished, and one more account someone forgets to revoke when an engineer leaves. Single sign-on (SSO) fixes this by letting people authenticate once against a central identity provider (IdP) and use that identity everywhere. This tutorial walks through getting SSO working for your team.

SAML vs OIDC: which protocol?

There are two protocols you will encounter. Both work; they suit different eras and stacks.

If your IdP and your app both support OIDC, prefer it — the tooling is friendlier and JWTs are easier to debug than signed XML. SAML remains the lingua franca of enterprise IT, so many tools still default to it. Both achieve the same goal.

Pick your identity provider

Common IdPs include Okta, Microsoft Entra ID (formerly Azure AD), Google Workspace, and JumpCloud. If your company already runs Google Workspace or Microsoft 365, you have an IdP — start there rather than introducing a new vendor.

The setup flow (generic)

The steps are nearly identical across providers. You are establishing trust between two parties: the Service Provider (the app, e.g. PandaStack) and the Identity Provider.

1. Create the application in your IdP

In your IdP admin console, create a new SAML or OIDC application. You will be asked for two values from the service provider:

• ACS URL (Assertion Consumer Service) / Redirect URI — where the IdP sends the user back after auth.
• Entity ID / Audience — a unique identifier for the service provider.

2. Exchange metadata

For SAML, the IdP gives you a metadata XML document (or individual values):

IdP SSO URL:      https://idp.example.com/sso/saml
IdP Entity ID:    https://idp.example.com/
X.509 Certificate: -----BEGIN CERTIFICATE----- ...

For OIDC, you exchange a client ID and client secret, plus the IdP's discovery document:

https://idp.example.com/.well-known/openid-configuration

3. Map attributes

Decide what the IdP sends in the assertion. At minimum you want email and name. If you want SSO to drive role assignment, map a groups claim too:

{
  "email": "jane@example.com",
  "name": "Jane Doe",
  "groups": ["engineering", "payments-admins"]
}

4. Test with one account first

Before enforcing SSO org-wide, test the full login loop with a single non-admin account. Confirm the user lands in the right org with the right role.

Just-in-time provisioning vs SCIM

Two ways to get users into the app:

• JIT provisioning — a user account is created on first SSO login. Simple, no extra integration. The downside: deprovisioning is manual unless you also enforce SSO-only login.
• SCIM — the IdP actively pushes create/update/delete events. When you disable a user in Okta, SCIM deletes them downstream automatically. This is the gold standard for offboarding.

Start with JIT to get value fast; add SCIM when compliance or scale demands automated deprovisioning.

The golden rule: do not lock yourself out

The most common SSO disaster is enforcing SSO-only login and then discovering your IdP config is broken — and now *nobody*, including admins, can log in.

Always keep a break-glass account. Practical safeguards:

• Keep at least one owner who can log in with email/password as a fallback.
• Test SSO end-to-end before enabling enforcement.
• Document the recovery path before you need it.

[ ] SSO tested with a real test user
[ ] At least one break-glass admin retains password login
[ ] Attribute mapping verified (email, name, groups)
[ ] Recovery procedure documented
[ ] THEN enable "require SSO"

Common pitfalls

• Clock skew breaks SAML assertions (they are time-bound). Keep servers on NTP.
• Wrong ACS URL sends users into a redirect loop. Copy-paste, do not retype.
• Mismatched certificates after an IdP cert rotation silently break logins — set a calendar reminder before expiry.
• Email changes can orphan accounts if you key identity on email instead of a stable subject identifier.

SSO on PandaStack

PandaStack supports SSO for teams and organizations, so your engineers authenticate through your existing IdP and inherit the owner/admin/member roles you have configured. Combined with RBAC, that means onboarding and offboarding happen in one place — your identity provider — instead of being chased across every tool.

References

• [OpenID Connect Core specification](https://openid.net/specs/openid-connect-core-1_0.html)
• [OASIS SAML 2.0 specification](https://docs.oasis-open.org/security/saml/v2.0/)
• [SCIM 2.0 RFC 7644](https://datatracker.ietf.org/doc/html/rfc7644)
• [Okta developer SSO guide](https://developer.okta.com/docs/concepts/saml/)
• [Microsoft Entra ID SSO docs](https://learn.microsoft.com/en-us/entra/identity/enterprise-apps/what-is-single-sign-on)

---

SSO turns identity into a solved problem instead of a per-tool chore. PandaStack includes team SSO and RBAC so your org can centralize login from day one — get started on the free tier at [dashboard.pandastack.io](https://dashboard.pandastack.io).