Login methods

Updated April 15, 2026

Three ways to sign in to Hyperping. Pick what fits your security posture: SAML SSO for centralized identity, Google for one-click access, or email and password for the universal fallback. Combine them, or require the strongest.

📘Useful when

You're rolling out SSO across the team and need to decide the migration path.
You need to restrict contractors to a specific set of projects.
You're preparing for a SOC 2, ISO 27001, or vendor security review.

At a glance

Methods

3 sign-in paths

SSO

SAML 2.0, Business plan

Providers

Okta, Entra ID, Google

2FA

Available on all plans

The three login methods

Every user authenticates through one of these. SAML SSO is the strongest, the other two stay available as fallbacks.

SAML Single Sign-OnBusiness plan

Authenticate your team via your identity provider. Users sign in through your IdP, Hyperping trusts the assertion.

Works with Okta, Microsoft Entra ID (Azure AD), Google Workspace, OneLogin, Auth0, JumpCloud, and any SAML 2.0 provider
Tunable authentication policy, provisioning, and per-project access scope
Owner accounts stay accessible via email fallback so you never lock yourself out
Aligns with SOC 2 and ISO 27001 access-control controls

OktaMicrosoft Entra IDGoogle WorkspaceOneLoginAuth0JumpCloudSAML 2.0

Best for: teams standardizing on a single IdP, regulated environments, or anyone needing centralized offboarding.

One-click OAuth for teammates who already sign in with a Google account.

Zero configuration, just pick "Sign in with Google" on the login screen
Matches the email on file, no separate password to manage
Combines with SAML SSO when set to "allow both"

Best for: small teams on Google Workspace, or as a fallback during SAML rollout.

Email and passwordAll plans

Classic credentials backed by 2FA. Always available for the Owner as a lockout fallback.

Passwords stored with bcrypt, never logged or exposed in API responses
Two-factor authentication available on every plan
Can be disabled for non-Owner users via the "Require SSO" policy

Best for: the Owner fallback, or teams without a central IdP yet.

Enable SAML SSO

Three steps from an empty SSO tab to every teammate signing in through your IdP.

Step 01

Open the authentication tab

Go to Teammates and switch to the Authentication tab. Click Setup Authentication Provider (SSO).

Step 02

Exchange metadata

Copy Hyperping's ACS URL and entity ID into your IdP, paste back the IdP metadata URL or XML. The setup wizard walks through each field.

Step 03

Pick policies and test

Set your authentication, provisioning, and access-scope policies below. Run the built-in test login before flipping Require SSO.

Authentication policy

Decide whether SSO is optional or mandatory for non-Owner users.

∥Allow SSO and email/password

Users pick either method at the login screen. Useful during rollout, or for teams that need a break-glass path outside the IdP.

Flexible

◆Require SSORecommended

Non-Owner users must sign in through your IdP. Owner keeps email/password as a lockout fallback. Aligns with SOC 2 and ISO 27001 controls.

Strict

New user provisioning

Three ways to handle the first SSO login from a user you haven't invited yet. Pick the one that matches your trust model.

Most secure

Invite-only

SSO login fails unless an admin already invited the user. You keep full control over who can reach the account.

IdP login → not invited → rejected

Balanced

Request access

New users land on a pending screen. Admins get notified and approve or deny from the Teammates page.

IdP login → pending → admin approval

Frictionless

Auto-provision

Anyone with a matching email domain joins automatically. Best when your IdP is the source of truth for employment.

IdP login → domain match → member

SSO access scope

Control which projects SSO users reach once they're in.

∀All projects

SSO users can be invited into any project in the account. Default behavior, simplest model.

Default

◐Specific projects only

Restrict SSO users to a selected set of projects. Useful for contractor access, isolated environments, or per-client segregation.

Scoped

See roles and permissions for how project isolation interacts with SSO scope.

Change email

Account

To change the email on your Hyperping account, open account settings, edit the email field, and click Save. A confirmation link goes to the new address.

Troubleshooting

SSO login returns "user not found."

Your provisioning policy is set to Invite-only. Invite the user from the Teammates page, or switch provisioning to Request access or Auto-provision.

I enabled "Require SSO" and locked myself out.

Owner accounts are exempt by design and can always sign in with email and password. Log in as the Owner, go to Teammates → Authentication, and relax the policy.

An SSO user can see projects they shouldn't.

Check SSO access scope. If it's set to All projects, they inherit access per invite. Switch to Specific projects only and pick the allowed set.

My IdP doesn't appear in the supported list.

Any SAML 2.0 compliant provider works. Use the generic SAML configuration in the setup wizard. If you hit a snag, contact us with your IdP's metadata.

Next steps

Access

Roles and permissions →

Four roles, project-level isolation. How scope and role decide what each user sees.

Invite

Invite teammates →

Add people to your project and assign a role. Works for both SSO and email users.

Structure

Project setup →

Shape your workspace before inviting the team. Clients, teams, or environments.

Alerts

Notification channels →

Configure how each role gets notified during incidents.

← Notification channels Roles and permissions →