Sign in with Microsoft

Microsoft sign-in lets your team get into freedam with the account they already use for Microsoft 365 - one less password to manage, one less credential to revoke when someone leaves. For organizations built around Microsoft's identity platform (Entra ID, formerly Azure AD), it makes freedam feel like part of the existing setup rather than another island.

What it does

Microsoft is one of the single sign-on providers built into freedam, alongside Google. When an administrator enables it for a workspace, the login screen offers Sign in with Microsoft; clicking it sends the user to Microsoft's familiar sign-in screen and straight back into freedam. Each user can see and manage the link between their freedam account and their Microsoft identity from their own account settings.

Single sign-on is part of the Business plan, of Tailored plans, and of the 30-day trial. On other plans a setting you had switched on is kept and resumes by itself once the plan covers SSO again; you can still switch it off, but not back on until then. People sign in with a password in the meantime.

How it works

freedam uses Microsoft's standard, widely trusted sign-in mechanism, and it works for any organization's Microsoft accounts - whether your company runs one Microsoft directory or several. Who may actually join your workspace is governed by the workspace's own membership rules, so sign-in convenience never overrides your access control.

freedam asks Microsoft for the minimum: who the person is and their email address. It gets no access to mail, files, Teams, or anything else in the Microsoft account.

Two thoughtful details:

• The right login, first try. When a workspace accepts members from a single email domain, freedam tells Microsoft so - and people are steered straight to their organization's login screen instead of a generic account picker.
• Only trustworthy emails. freedam only accepts a Microsoft identity when Microsoft vouches for its email address, so an account without a verified organizational address is not let in through single sign-on.

Self-hosted deployments use their own Microsoft credentials: the operator registers the app in their organization's Microsoft account and adds the credentials 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

• Works across organizations. Accounts from any Microsoft directory can sign in; your workspace rules decide who gets in.
• Identity only - no standing access to the account, no reach into Microsoft 365 data.
• Providers are independent. Microsoft and Google sign-in are enabled per workspace, separately - offer either or both.
• Self-hosted setups own their credentials. Sign-in runs between your instance and Microsoft directly - it is never proxied through a third party.

API access for scripts and integrations uses token authentication rather than browser sign-in - see /developers. Rolling this out on a self-hosted instance? Get in touch if you want to talk through the setup.