Summary
Add team-level SSO enforcement for dashboard access.
Problem
Organizations that use HitKeep with multiple team members often need authentication to flow through their identity provider, but team owners currently manage access through local accounts, invitations, passwords, MFA, and passkeys. That works for smaller teams, but it leaves larger organizations without a clear way to require centralized sign-in, prove which members are covered by SSO, or disable local password access for managed team members.
Who Benefits
Team admins, managed cloud customers, and self-hosted operators who need centralized access control for dashboard users.
Proposed Solution
Add a team security setting that lets team owners or admins require SSO for members of that team once an SSO provider is connected. The smallest useful version should cover verified-domain matching, invite acceptance through SSO, member SSO status, a safe enforcement grace period, and an explicit break-glass path for instance owners or designated recovery admins.
User Workflow
- A team owner connects or selects an approved SSO provider for the team.
- The owner reviews matching email domains and enables SSO enforcement with a grace period.
- Existing and invited members sign in through the SSO option before accessing that team.
Success Criteria
- Team owners can see whether SSO is disabled, optional, or required for the active team.
- Team admins can enable SSO enforcement only after the provider and verified-domain checks are valid.
- Existing team invitations can be accepted through SSO without creating duplicate users.
- Members who are required to use SSO cannot access the protected team through password-only login after the grace period.
- Instance owner or recovery access remains possible when the IdP is unavailable.
- SSO enforcement changes are recorded in team or system audit views.
Alternatives Considered
Teams can rely on strong local passwords, TOTP, passkeys, recovery codes, and manual member removal today. That does not provide centralized offboarding or an enforceable organization identity policy.
Constraints
SSO enforcement must preserve HitKeep's single-binary deployment model and should not require a separate identity broker service. It must work with existing sessions, MFA, passkeys, team roles, invitations, and audit behavior. It should avoid storing raw identity provider tokens and should collect only the claims needed to match a HitKeep user to a team member.
Release Notes
Add team-level SSO enforcement so admins can require members to authenticate through an approved identity provider.
Additional Context
Depends on #225. This is the policy and team-management layer, and should build on provider support from the bring-your-own SSO work instead of hardcoding a specific identity provider into team settings.
Docs needed: team security guide, self-hosted configuration notes, recovery access guidance, and release notes.
Summary
Add team-level SSO enforcement for dashboard access.
Problem
Organizations that use HitKeep with multiple team members often need authentication to flow through their identity provider, but team owners currently manage access through local accounts, invitations, passwords, MFA, and passkeys. That works for smaller teams, but it leaves larger organizations without a clear way to require centralized sign-in, prove which members are covered by SSO, or disable local password access for managed team members.
Who Benefits
Team admins, managed cloud customers, and self-hosted operators who need centralized access control for dashboard users.
Proposed Solution
Add a team security setting that lets team owners or admins require SSO for members of that team once an SSO provider is connected. The smallest useful version should cover verified-domain matching, invite acceptance through SSO, member SSO status, a safe enforcement grace period, and an explicit break-glass path for instance owners or designated recovery admins.
User Workflow
Success Criteria
Alternatives Considered
Teams can rely on strong local passwords, TOTP, passkeys, recovery codes, and manual member removal today. That does not provide centralized offboarding or an enforceable organization identity policy.
Constraints
SSO enforcement must preserve HitKeep's single-binary deployment model and should not require a separate identity broker service. It must work with existing sessions, MFA, passkeys, team roles, invitations, and audit behavior. It should avoid storing raw identity provider tokens and should collect only the claims needed to match a HitKeep user to a team member.
Release Notes
Add team-level SSO enforcement so admins can require members to authenticate through an approved identity provider.
Additional Context
Depends on #225. This is the policy and team-management layer, and should build on provider support from the bring-your-own SSO work instead of hardcoding a specific identity provider into team settings.
Docs needed: team security guide, self-hosted configuration notes, recovery access guidance, and release notes.