Register an Application
Before your application can authenticate users through SingleSign, you need to register it in the developer portal. This page walks you through every field and decision.
Prerequisites
- A SingleSign account (sign up at singlesign.com).
- Your Platform GUID (shown on the developer portal dashboard).
1. Open the Developer Portal
Log in at singlesign.com and navigate to Developer Portal → Applications. This is where you manage every app connected to your platform.
2. Create a New Application
Click Create Application and fill in the following fields:
Application Name
A human-readable name displayed to users on the consent screen. Choose something recognizable (e.g., "Acme Customer Portal").
Application Type
Select the type that best describes your app:
| Type | Description | Client Kind |
|---|---|---|
| Single-Page Application | JavaScript running in the browser (React, Vue, Angular, etc.) | Public — no client secret |
| Server Web Application | Backend-rendered app (Node.js, Rails, Django, etc.) | Confidential — receives a client secret |
| Mobile / Native | iOS, Android, or desktop app | Public — uses PKCE with custom URI scheme |
The application type determines whether SingleSign issues a client_secret and which PKCE enforcement rules apply.
Redirect URIs
Add every URI your app will use to receive the authorization callback. Rules:
- Must use HTTPS in production (HTTP is allowed only for
localhostduring development). - Must be an exact match — no wildcards, no query strings.
- Multiple URIs are supported (e.g., one for staging, one for production).
Examples of valid redirect URIs:
https://app.example.com/callback
https://staging.example.com/auth/callback
http://localhost:3000/callback
com.example.myapp://callback
See Redirect URIs Concepts for detailed rules and common mistakes.
Scopes
Select the scopes your application needs. You can always update these later. Start with the minimum set your app requires.
| Scope | Data Returned |
|---|---|
openid | Required — returns the sub (and human_guid) claim |
profile | Name, nickname, picture |
email | Email address, email_verified |
phone | Phone number, phone_verified |
address | Formatted mailing address |
offline_access | Issues a refresh token for long-lived sessions |
Tip: Only request scopes you actually use. The consent screen shows each scope to the user, and fewer permissions build more trust.
Post-Logout Redirect URIs (Optional)
If you plan to implement single logout, add the URIs where users should land after signing out.
3. Save and Copy Credentials
After saving, the portal displays:
- Client ID (
client_id) — a public identifier included in authorization requests. Safe to embed in client-side code. - Client Secret (
client_secret) — only shown for confidential (server) apps. Store this securely. Never commit it to version control or include it in frontend bundles.
Client ID: abc123-def456-ghi789
Client Secret: sk_live_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx (server apps only)
Copy these values into your application configuration.
4. Configure Your Application
With your credentials in hand, configure your app:
const singleSignConfig = {
platformGuid: "YOUR_PLATFORM_GUID",
clientId: "abc123-def456-ghi789",
redirectUri: "http://localhost:3000/callback",
scopes: "openid profile email",
// Endpoints
authorizationEndpoint: "https://api.singlesign.com/oauth/authorize",
tokenEndpoint: "https://api.singlesign.com/oauth/token",
userinfoEndpoint: "https://api.singlesign.com/oauth/userinfo",
discoveryEndpoint: "https://api.singlesign.com/.well-known/openid-configuration",
};
Alternatively, fetch all endpoint URLs dynamically from the Discovery endpoint:
const discoveryUrl =
`https://api.singlesign.com/.well-known/openid-configuration?platform_guid=${singleSignConfig.platformGuid}`;
const discovery = await fetch(discoveryUrl).then((r) => r.json());
// discovery.authorization_endpoint, discovery.token_endpoint, etc.
5. Test the Integration
Use the Quickstart Guide to confirm the full login flow works with your new app credentials.
Managing Your Application
Updating Settings
Return to Developer Portal → Applications → (your app) at any time to:
- Add or remove redirect URIs.
- Change requested scopes.
- Regenerate the client secret (confidential apps only — this invalidates the old secret immediately).
- Update the display name or logo.
Rotating Client Secrets
For confidential apps, rotate your client secret periodically:
- Generate a new secret in the portal.
- Update your server configuration to use the new secret.
- Deploy the change.
- Revoke the old secret in the portal.
Deleting an Application
Deleting an app immediately invalidates all tokens issued to it. Users will need to re-authenticate with any replacement app.
Next Steps
- Quickstart Guide — Authenticate your first user.
- SPA with PKCE Guide — Full browser-app integration.
- Server Web App Guide — Confidential client integration with Express.
- Scopes & Consent — Choose the right scopes.
Last updated: 2026-02-16
Related docs
- SingleSign Developer DocumentationLearn how to integrate SingleSign identity and authentication into your applications using OAuth 2.0 and OpenID Connect.
- free identity providerSingleSign pricing in one line: sign-in is free, with no monthly-active-user meter. See exactly what is included, and what SingleSign Mail costs for businesses.
- Identity provider alternativesIdentity provider alternatives, by the provider you are leaving: what actually has to change in your code, and what does not.
- 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.
- Okta comparisonSingleSign vs Okta: Okta is built for workforce identity inside a company, SingleSign for consumer sign-in across applications.
- Firebase Auth comparisonSingleSign vs Firebase Authentication on lock-in, portability and consent, plus the cases where staying on Firebase is right.
- SingleSign vs Google Sign-InSingleSign vs Google Sign-In: the same one-tap convenience, without an advertising business behind the identity.
- alternative to Auth0Auth0 alternatives compared, plus the part most listicles skip: what migrating off Auth0 actually involves, which code changes, and which does not.