Outcome
By the end of this lesson, you will be able to choose between SAML and OAuth based on org requirements, explain the trade-offs of each method, and recognize when a customer needs multiple SSO methods simultaneously.
| Prerequisites | T0, Foundations · M4.1, RBAC fundamentals |
| Time | 9 minutes |
1. Concept
Single sign-on means people log in once, somewhere your company already trusts, and get into ZopNight without another password to forget.
That somewhere is called an identity provider. ZopNight accepts three kinds: SAML for the enterprise ones such as Okta, Azure AD and OneLogin, Google for companies on Google Workspace, and GitHub for engineering teams who already live there.
All three coexist. Google and GitHub sign-in are on for every org, and ZopDev adds SAML per email domain when you ask, so a typical setup is SAML for employees with Google or GitHub for a contractor pool. Each user picks the method that matches their account.
SSO METHOD BEST FOR TRADE-OFF──────────────────────────────────────────────────────────────────SAML Enterprises with a central IdP Per-domain config; (Okta, Azure AD, OneLogin, Auth0) cert management; compliance-friendly
Google OAuth Teams already on Google Workspace Any Google user can sign in; only org members see your data
GitHub OAuth Engineering teams on GitHub Enterprise GitHub account required; lighter compliance postureSelection criteria
The right choice usually falls out of three questions: where does identity already live, what compliance posture is the customer in, and how heterogeneous is the user population?
CRITERION BEST CHOICE──────────────────────────────────────────────────────────────────Org already has Okta / Azure AD / OneLogin SAML (centralizes)SOC 2 / ISO 27001 audit posture SAML (compliance trail)Mixed users (employees + contractors) SAML primary + OAuth for contractorsPure Google Workspace org Google OAuthJust engineering team, no enterprise IdP Google or GitHub OAuthWant shortest setup time OAuth (5 min vs 30 min)Don't want to manage SSO certs OAuth (no certs)SAML: the enterprise default
SAML 2.0 is the assertion-based protocol used by most enterprise IdPs. ZopDev sets up one entry per email domain for you; users signing in with jane@example.com are redirected to the IdP configured for example.com. The IdP authenticates, issues a signed XML assertion, and ZopNight validates the signature against the stored cert before creating a session.
SAML’s strengths are exactly what compliance teams care about: sign-in is tied to your IdP, so disabling a person there cuts off their SAML sign-in; signing certs are managed centrally; and email and name flow from the IdP. Roles and teams are still managed in ZopNight, not from IdP groups. The cost is operational: certs expire annually, metadata can drift, and clock skew between IdP and ZopNight produces puzzling intermittent failures.
OAuth: the lightweight default
OAuth (Google or GitHub) is faster to enable: there is nothing for you to set up. ZopNight turns the “Sign in with Google” and “Sign in with GitHub” buttons on for the whole platform, and the sign-in itself runs in ZopNight’s external auth service. No certs, no metadata XML, no per-domain configuration.
The trade-off: OAuth has no domain restriction, and ZopNight does not add one. Any Google or GitHub account can sign in. What protects your data is org membership: a person who signs in and has not been added to your org goes through onboarding, which creates a separate organisation for them, and they see nothing of yours. Only people an Admin adds in Settings → Organization, with a role, get into your org.
Multi-method coexistence
Most mid-size customers end up with one primary method and a secondary for edge cases:
PATTERN PRIMARY SECONDARY──────────────────────────────────────────────────────────────────Enterprise with mixed external partners SAML Google OAuth (contractors)Pure-Google Workspace mid-stage company Google OAuth GitHub OAuth (eng partners)Acquired-then-merged org SAML A SAML B (post-acquisition consolidation)The user picks the method at login. Membership and roles hang off the email address, so jane@example.com gets the same access whichever method she uses.
How ZopNight uses it
The combinations you will meet:
SSO STATE──────────────────────────────────────────────────────────────────SAML onlyGoogle OAuth onlySAML + Google OAuthSAML + GitHub OAuthSAML + Google + GitHubGitHub OAuth onlyThe “SAML primary + OAuth secondary” pattern is the most common stable configuration for mid-to-large customers. Google and GitHub buttons stay on the login page either way; if policy says employees must use SAML, enforce it in your onboarding guidance and access reviews.
2. Demo
Two customers, two methods, two different setup paths:
CUSTOMER A: B2B SaaS, 200 employees, on Azure AD CHOICE: SAML via Azure AD CONFIG: ZopDev sets up 1 SAML config (domain=example.com) EFFORT: ~30 minutes of your own work (IdP app, claims, test) plus the round trip with ZopDev RESULT: All users SSO via Azure AD; Admins add roles and teams in ZopNight; SOC 2 evidence collection simpler
CUSTOMER B: 8-person engineering team, no enterprise IdP CHOICE: Google OAuth (Workspace-backed) CONFIG: Nothing to configure; the Google button is already there EFFORT: ~5 minutes (tell the team to use it) RESULT: Engineers sign in with Google; MFA is whatever their Google account enforces; no cert managementDifferent needs, different methods, both correct.
3. Hands-on (6 min)
Map your org’s identity landscape:
PRIMARY IDP (where most user accounts live): __________
DO YOU HAVE: Enterprise IdP (Okta / Azure AD / OneLogin)? Yes / No Google Workspace? Yes / No GitHub Enterprise? Yes / No Compliance posture (SOC 2 / ISO / HIPAA / etc.)? __________
USER POPULATION: Full-time employees: _____ headcount Contractors/partners: _____ headcount Engineering-only? _____ Yes / No
RECOMMENDED SSO (based on criteria): Primary: __________ Secondary: __________ (or "none")
WHY: __________________________________________________________If your primary and secondary differ, that’s normal. The choice depends on user heterogeneity.
4. Knowledge check
Q1
A team with 500 employees, all on Okta, with a SOC 2 audit next quarter. Best SSO:
A. GitHub OAuth, since it is by far the simplest thing to set up and everyone already has an account with it
B. Mix all three of the methods, so that everyone has some route in regardless of which one they happen to already use today
C. Google OAuth, with everyone told to use their company Google account only, and nothing else set up
D. SAML via Okta, after confirming support with ZopDev; it centralizes identity in the IdP the auditors already review
Show answer
Correct: D. The setup effort pays back during the audit. SAML is the enterprise compliance choice. The config record is shaped around Azure AD, so confirm Okta with ZopDev first. SOC 2 evidence collection is trivial with SAML’s audit trail; OAuth requires more documentation to demonstrate the same controls.
Q2
A 5-person startup, all on Google Workspace, no compliance audit on the horizon. Best SSO:
A. SAML, since it is the documented best practice for an organisation of any size or shape
B. Google OAuth; simpler setup (5 min vs 30 min), no certs, MFA is whatever Google enforces
C. GitHub OAuth, since the engineers will all have accounts already anyway there
D. Password authentication, managed entirely inside ZopNight itself from the start
Show answer
Correct: B. Move to SAML later if the org grows into enterprise compliance. At small scale and low compliance burden, OAuth’s simplicity wins. Moving to SAML later is straightforward: membership and roles hang off the email address.
Q3
Can multiple SSO methods coexist in the same ZopNight org?
A. No, the organisation has to pick just one of them and stick to it
B. SAML always overrides all of the other methods configured
C. Only two of the methods may coexist at any single given moment
D. Yes: SAML + Google OAuth + GitHub OAuth can all be enabled at once
Show answer
Correct: D. Users pick the method at login, and access hangs off the email address. Common pattern: SAML for employees, OAuth for contractors. Google and GitHub are on for every org; SAML is added per email domain by ZopDev.
5. Apply
There is no authentication settings page in your org. Google and GitHub sign-in are on for every org; SAML is set up per email domain by ZopDev. Ask ZopDev to set up SAML for your email domain, then test sign-in with one admin account before rollout. Control who gets in through Settings → Organization, where Admins add members with a role.
A recommendation: keep one admin account able to sign in by another method (email or Google) as a break-glass route. SSO providers occasionally have outages; you want a way back in.
Related lessons
- L2: SAML per-email-domain (next)
- L3: Google + GitHub OAuth
- L4: Diagnosing SSO failures
- T4.M4.3.L1: Audit log: what gets recorded
Glossary terms touched
SAML · OAuth 2.0 · Identity Provider