Sign in with Google
Google sign-in removes one more password from your team's life. Members sign in to freedam with the Google account they already use all day, admins stop fielding reset requests, and offboarding gets simpler - when someone leaves the Google Workspace, they lose the credential they were signing in with.
What it does
Google is one of the single sign-on providers built into freedam. When it is enabled for a workspace, the login screen offers Sign in with Google alongside the standard email-and-password form. Clicking it sends the user to Google's familiar sign-in screen and straight back into freedam.
Sign-in options are controlled per workspace: an administrator switches the Google option on or off in the workspace settings, and each user can see and manage the link between their freedam account and their Google identity from their own account settings.
How it works
freedam uses Google's standard, widely trusted sign-in mechanism and asks for the minimum: who the person is and their email address. It gets no access to Drive, Gmail, or anything else in the Google account.
Two thoughtful details:
- The right account, first try. When a workspace accepts members from a single email domain, freedam tells Google so - and the account picker steers people to their work account instead of a personal Gmail.
- Only verified emails. freedam checks that Google has actually verified the email address on the account, so an unverified address cannot slip in through single sign-on.
Self-hosted deployments use their own Google credentials: the operator creates them in their organization's Google Cloud account and adds them to the instance's configuration - the documentation walks through it. Once they are in place, workspace admins can switch the provider on.
Good to know
- freedam asks for identity, nothing more - no standing access to the account, no data beyond name, email, and profile picture.
- Steering is not gatekeeping. Guiding people toward their work account is a convenience; the workspace's own membership rules are what actually govern who can join.
- Providers are independent. Google and Microsoft sign-in are enabled per workspace, separately - offer one, the other, or both.
- Single sign-on is part of the Business plan (and of Tailored plans, and of the 30-day trial). On other plans a provider you had switched on keeps its setting and resumes on its own, enforcement included, as soon as the plan covers SSO again. You can still switch it off, but not back on until then. Meanwhile people sign in with a password, and anyone who only ever used Google can set one through the usual password reset.
- Self-hosted setups own their credentials. Sign-in runs between your instance and Google directly - it is never proxied through a third party.
Developer access for scripts and integrations uses API tokens rather than browser sign-in - see /developers. Setting up SSO on a self-hosted instance and want a sanity check? Get in touch.