Outcome
By the end of this lesson, you will be able to explain how Google and GitHub sign-in work in ZopNight, control who reaches your org’s data through membership, and understand when OAuth is the right tool versus when SAML’s stronger controls are required.
| Prerequisites | M4.2.L1, Pick your SSO · M4.2.L2, SAML config (for contrast) |
| Time | 9 minutes |
1. Concept
Signing in through Google or GitHub is the quick option. There is nothing for you to set up: the “Continue with Google” and “Continue with GitHub” buttons are part of the ZopNight platform build and appear on every org’s login page.
What you give up is control over who can sign in. Neither provider restricts which email domains are allowed, and ZopNight does not add a domain allowlist. Any Google or GitHub account can complete the sign-in. What protects your data is org membership: signing in proves who someone is, and only membership in your org decides what they see.
What is configured, and by whom
SETTING WHO CONTROLS IT──────────────────────────────────────────────────────────────────Google and GitHub buttons ZopDev, in the platform build (on for every org)OAuth client ID and secret ZopDev; you never create oneWhere the sign-in runs ZopNight's external auth serviceSAML per email domain ZopDev, on request (L2)Who is a member of your org Your Admins, in Settings →and with which role OrganizationWhich teams a member is in Your Admins, on the Teams pageThe last two rows are yours. Everything above them is platform-level, so there is no authentication settings page in your org.
What happens at first sign-in
CASE A: An Admin already added jane@example.com with a role Jane clicks "Continue with Google" Google confirms she is jane@example.com She lands in your org with the role the Admin chose
CASE B: Nobody added sam@gmail.com Sam clicks "Continue with Google" Google confirms he is sam@gmail.com He has no organisation, so onboarding creates a new one for him He sees his own empty org, nothing of yoursCase B is why a missing allowlist does not leak data. A stranger can create an account, but the account is not in your org. The gate that matters is the member list.
Adding members
Admins add people in Settings → Organization: one or more email addresses plus a role. A role choice is required (or an explicit “No role”), so nobody lands in the org with access by accident. Team membership is a separate step on the Teams page, and it decides which resources a team-scoped role can see (M4.1).
The OAuth flow in detail
T+0 User clicks "Continue with Google" on the login pageT+0.1s Browser goes to Google with ZopNight's client ID, scope "openid email profile", and the callback /zopnight/app/auth/callback/googleT+1s User picks an account and authenticates (whatever MFA the Google account enforces applies here)T+2s Google redirects back to the callback with an ID tokenT+2.1s ZopNight's auth service verifies the token and finds or creates the user by emailT+2.3s User lands in their org, or in onboarding if they have none
GitHub works the same way, with scope "user:email" and thecallback /zopnight/app/auth/callback/github.The provider’s tokens are used only to establish identity. After that, the session runs on ZopNight’s own token, refreshed independently.
When OAuth is the right choice
SCENARIO OAUTH FITS?──────────────────────────────────────────────────────────Small team on Google Workspace YesEngineering team on GitHub YesContractor pool (secondary method) YesCompliance audit requires SAML No → use SAMLMultiple email domains needing different IdPs No → use SAMLSign-in must stop when IT disables a person SAML strongerMature enterprise IT with existing IdP SAML primary; OAuth secondaryMulti-method coexistence
OAuth and SAML coexist. A typical setup:
PRIMARY: SAML for full-time employees (example.com), set up by ZopDevSECONDARY: Google for contractors, added as members by emailALSO ON: GitHub, available to anyone, useful for engineers
The login page shows Google, GitHub and "Continue with SSO". TheSSO button asks for the email domain and routes to that domain'sIdP.How ZopNight uses OAuth
Access hangs off the email address. If an Admin added jane@example.com, she gets the same membership and role whether she signs in with Google, GitHub or SAML. Roles are never assigned automatically on sign-in; Admin is always a deliberate grant.
2. Demo
A 25-person engineering team rolling out Google sign-in:
SETUP: Method: Google (already on the login page) ZopNight config: none Admin action: add 25 emails in Settings → Organization, role Editor; add each to the right team
ROLLOUT TIMELINE: Day 1: 2 admins sign in, confirm they land in the org Day 1: Admin bulk-adds the 25 engineers with the Editor role Day 2: Engineers sign in with Google; their Google account's MFA applies, if it enforces any Day 3: Admin checks the member list against HR's roster
OUTCOMES: - Setup time: minutes, all of it member management - MFA is whatever the Google Workspace account enforces; ZopNight adds no MFA requirement of its own - A stray sign-up from outside the company lands in its own empty org and never sees this oneIf they needed a contractor next month with a different email, an Admin would add that email as a member with a narrow role. If the contractor’s company has its own IdP, ZopDev can set up SAML for that domain instead.
3. Hands-on (6 min)
Decide if OAuth fits your team’s needs, and plan the membership side:
PROPOSED METHOD: Google / GitHub / Both / SAML first
MEMBERS TO ADD: Employees: _____ emails, role __________ (Viewer / Editor) Contractors: _____ emails, role __________ Admins: __________ (named people, kept few)
TEAMS: Which team does each group join? __________
BREAK-GLASS: Which admin can sign in another way if the provider is down? __________
A test checklist (before announcing): □ An added member signs in → lands in the org with the right role □ A non-member signs in → lands in onboarding, sees nothing of yours □ A team-scoped member sees only the team's resources □ Member list matches your roster4. Knowledge check
Q1
A team uses Google Workspace exclusively, with no enterprise IdP. Best SSO:
A. SAML, configured against Google Workspace as the identity provider
B. Password authentication, managed entirely inside ZopNight itself
C. Google OAuth: no setup, no certs, and MFA is whatever Google enforces
D. GitHub OAuth, since most of the engineers already have an account
Show answer
Correct: C. SAML is the choice if compliance audits demand stronger controls or if the team has multiple domains. Google sign-in is already on the login page, so the only work is adding members. MFA is whatever the user’s Google account enforces; ZopNight sets no MFA requirement.
Q2
You want only your company’s people to see your org’s data. The mechanism:
A. Org membership: only people an Admin adds see your data
B. It is not possible at all without setting up SAML first
C. It is set on the OAuth provider’s consent screen
D. A domain allowlist on the org’s authentication page
Show answer
Correct: A. Anyone can sign in with Google or GitHub, but a person who is not a member lands in an org of their own. There is no domain allowlist or authentication page; the member list in Settings → Organization is the control.
Q3
A new user signs in with Google for the first time, and nobody has added their email to your org. What happens?
A. They join your org automatically with the Viewer role
B. They are blocked by Google at the account picker step
C. An Admin of your org gets an approval request to review first
D. Onboarding gives them their own org, with none of your data
Show answer
Correct: D. Sign-in only proves identity. With no membership, the user has no organisation, so onboarding creates one for them. To bring them into yours, an Admin adds their email with a role.
5. Apply
There is nothing to configure for Google or GitHub sign-in: both are on for every org. Control access in Settings → Organization, where Admins add members by email with a role, and on Teams. Test with one added member and one non-member before announcing to the team.
Recommended: review the member list monthly against your HR roster, and remove anyone who has left. With OAuth, leaving the company does not always end someone’s Google or GitHub account.
Related lessons
- L1: Pick your SSO
- L2: SAML per-email-domain
- L4: Diagnosing SSO failures (next)
- T4.M4.3.L1: Audit log: what gets recorded