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.

Hyperping sign-in screen with Google, SAML SSO, and email login options — The sign-in screen: Google, SAML SSO, or email and password

At a glance

Methods: 3 sign-in paths
SSO: SAML 2.0, Business plan
Providers: Any SAML 2.0 provider
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-On

Business plan

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

Best forTeams standardizing on one IdP, regulated environments, and centralized offboarding.

What you get

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

Works with

OktaMicrosoft Entra IDGoogle WorkspaceOneLoginAuth0JumpCloudSAML 2.0

Sign in with Google

All plans

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

Best forSmall teams on Google Workspace, or a simple fallback during SAML rollout.

What you get

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"

Email and password

All plans

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

Best forThe Owner fallback, or teams that do not have a central IdP yet.

What you get

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

Enable SAML SSO

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

Open the authentication tab
Go to Teammates and switch to the Authentication tab. Click Setup Authentication Provider (SSO).
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.
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 both methods

During rollout

Users choose SSO or email and password. Keep this while migrating, or when the team needs a break-glass path outside the IdP.

Require SSO

Recommended

Non-Owner users must use the IdP. The Owner keeps email and password as a lockout fallback, supporting SOC 2 and ISO 27001 controls.

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.

Invite-only
Most secure
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
Request access
Balanced
New users land on a pending screen. Admins get notified and approve or deny them from the Teammates page.
IdP login → pending → admin approval
Auto-provision
Frictionless
Anyone with a matching email domain joins automatically 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

Default

SSO users can be invited into any project in the account. This is the simplest access model.

Specific projects only

Scoped

Restrict SSO users to selected projects for contractors, isolated environments, or client work.

Change email

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

Roles and permissions

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

Invite teammates

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

Project setup

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

Notification channels

Configure how each role gets notified during incidents.

← Notification channels Roles and permissions →

Notification channels‹ Previous Set up SAML SSONext ›