Connecting Google sign-in to freedam removes one more password from your team's life. Members authenticate 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 through Google's OAuth consent flow and back to freedam, authenticated.

SSO is controlled per workspace: an administrator enables or disables the Google provider in the workspace's settings, and individual users can see and manage the link between their freedam account and their Google identity from their own account settings.

How it works

Under the hood, freedam uses the standard OAuth authorization-code flow (via Laravel Socialite). At the consent screen, freedam requests only the openid, email, and profile scopes — identity, nothing more. It has no access to Drive, Gmail, or anything else in the Google account.

Two details are worth knowing about how the flow is tuned:

• Domain hint. When the workspace is configured with exactly one allowed email domain, freedam passes Google's hd parameter in the authorization request, so the account picker steers users to their work account instead of a personal Gmail.
• Verified email. freedam checks Google's explicit email_verified claim on the returned identity, so an unverified address cannot ride in through SSO.

For self-hosted deployments, the operator supplies a Google OAuth client: set GOOGLE_OAUTH_CLIENT_ID and GOOGLE_OAUTH_CLIENT_SECRET in the environment, and register the callback path /auth/google/callback (on your instance's domain) as the authorized redirect URI in the Google Cloud Console. Once the credentials are in place, workspace admins can switch the provider on.

Good to know

• Scopes are minimal by design — openid, email, profile. No offline access, no refresh-token hoarding, no data scopes.
• The domain hint is a hint, not a lock. The hd parameter steers the Google account chooser; workspace-level email domain rules in freedam are what actually govern who can join.
• Enablement is per provider, per workspace. Google and Microsoft sign-in are configured independently, so you can offer one, the other, or both.
• Self-hosted setups need their own OAuth client. The client ID and secret are yours, created in your Google Cloud project — freedam does not proxy authentication through any third party.

Developer-facing authentication — API tokens rather than browser sign-in — is a separate system, covered at /developers. Setting up SSO on a self-hosted instance and want a sanity check? Get in touch.