Identity provider security, by design
Identity provider security at SingleSign starts with the code exchange: every authorization code is protected by PKCE and every redirect destination is allow-listed.
How sign‑in works
SingleSign implements the OAuth 2.0 Authorization Code flow with Proof Key for Code Exchange (PKCE). When a user clicks "Sign in," the app redirects to SingleSign with a code challenge. After the user authenticates and consents, SingleSign issues an authorization code that can only be exchanged for tokens by presenting the original code verifier.
This ensures authorization codes are useless if intercepted, and tokens are only issued to the application that initiated the request.
Protecting accounts
Users can enable multi‑factor authentication (MFA) using TOTP authenticator apps. Backup recovery codes are available so users are never locked out, even if they lose their device.
Session and device management lets users see where they're logged in and end sessions remotely. Password requirements follow current best practices to balance security with usability.
Protecting integrations
Every registered application must define a redirect URI allow‑list. Authorization requests to URIs not on the list are rejected. Client credentials are hashed and never stored in plain text.
Scopes limit what data an app can request, and users see a clear consent screen before any information is shared. Access can be revoked at any time from the user's Connected Apps dashboard.
Data minimization
SingleSign collects only the data necessary to authenticate users and facilitate authorized access. Apps receive only the claims associated with the scopes the user approved.
We do not sell, rent, or share user data with third parties for advertising or marketing purposes.
Abuse protections
Rate limiting is applied to sensitive endpoints — including sign‑in, token exchange, and account recovery — to protect against brute‑force attacks and automated abuse.
Audit logging tracks security‑relevant events such as sign‑ins, MFA changes, and token issuance. These logs help users and administrators understand account activity.
Reporting security issues
If you discover a security vulnerability in SingleSign, please report it responsibly. Contact us at security@singlesign.com with details of the issue. We take every report seriously and will respond promptly.
Related
- redirect URIRules for redirect URIs in SingleSign: HTTPS requirements, exact matching, allow-listing, and common mistakes to avoid.
- Identity provider features, in fullThe identity provider features SingleSign ships: OAuth 2.0 and OpenID Connect endpoints, PKCE, scopes and consent, MFA, and instant revocation.
- Firebase Auth comparisonSingleSign vs Firebase Authentication on lock-in, portability and consent, plus the cases where staying on Firebase is right.
- Auth0 comparisonSingleSign vs Auth0 compared on the difference that matters: who owns the account. A side-by-side table, then the three cases where each one is the right call.
- SaaS single sign-onSSO for SaaS applications using OAuth 2.0 and OpenID Connect: the flow to pick, the scopes to request, and a working integration path with SingleSign.
- React authentication with PKCEReact authentication done the recommended way: Authorization Code with PKCE, and no client secret in your JavaScript bundle.
- mobile app authenticationMobile app authentication for iOS and Android: Authorization Code with PKCE in a system browser, custom scheme redirects, and secure token storage on device.
- Proof Key for Code Exchange (PKCE)Why PKCE exists, how the S256 challenge method works, and when to use it with SingleSign.