Single sign-on

What you get

• Sign-in through your own OpenID Connect provider
• Microsoft Entra ID, Google and other standard providers
• Every email at your domain sent to your provider
• Domain ownership proved with a DNS record
• No separate Whisk code or password for your staff
• The same roles, groups and app access as before

How it works

An owner enters the provider's issuer address, client ID and client secret in the dashboard settings, with the company's email domain. Whisk checks a DNS TXT record to confirm the business owns that domain before company sign-in is turned on. The client secret is kept as an encrypted secret.

From then on, anyone who types an email at that domain is sent to the company's provider to sign in. Whisk uses OpenID Connect, the open standard most identity providers support, with PKCE, a check that stops an intercepted sign-in code being reused. Passkeys, passwords and emailed codes are refused for that domain, so the company's own directory decides who can sign in.

Apps do not change. They receive the same identity headers, and access to each app is still set by role, group or person in Whisk.

Example

An accounting practice already manages its staff in Microsoft 365. Once single sign-on is on, staff open the client onboarding app and sign in with their usual work account. When a staff member leaves and IT disables their Microsoft account, they can no longer sign in to any of the practice's apps.

For your coding agent

whisk access show

Single sign-on is an owner's setting in the dashboard, and app code stays the same: the app reads the headers in the headers reference. whisk access show lists who may open the app, as it does with team sign-in.