Before you start

Before you write any integration code, you need a registered client. A client is the record EntryIdP holds for your app: its client_id, the exact redirect URIs it is allowed to use, the scopes it may request, and (for server-side apps) a client_secret. EntryIdP rejects any authorization request whose client_id, redirect_uri, or scopes do not match a registered client.

There is no self-service registration. We register clients for you. Email entryidp@synapser.com with the details below.

Don't have all the answers yet? Send what you know. If you're unsure about redirect URIs, scopes, or logout, say so — we'll help you figure them out. The only thing you truly need up front is your app name and which platforms you're building for.

Do you need a backend?

Not every app does. This is the single decision that shapes your registration — it determines whether you're a confidential client (gets a client_secret) or a public client (secured by PKCE instead), and whether refresh tokens are available to you. Find your case:

• Server-rendered web app (Next.js, ASP.NET Core, Express, Rails…) → you have a backend. You're a confidential client. You receive a client_secret, keep it server-side, and exchange the authorization code on your server.
• Native mobile app (iOS, Android, React Native, Flutter) → no backend needed. You're a public client. PKCE plus the OS secure store (Keychain / Keystore) safely hold your tokens, including a refresh token.
• Browser-only SPA (React, Vue, Svelte with no server of your own) → no backend required, but it's the limited path. You're a public client: PKCE runs in the browser, the access token lives in memory only, and offline_access / refresh tokens are not available — the user re-authenticates when the access token expires (after 15 minutes). If you want persistent sessions or need to call APIs from your own server, add a small backend (the backend-for-frontend / token-handler pattern); that makes you a confidential client and unlocks refresh tokens. See Integrate your app.

Why a backend isn't always required: PKCE replaces the client secret for public clients. It cryptographically proves the token request came from the same app that started the login flow — which is exactly why a mobile app or SPA can complete the flow without a confidential secret.

Prerequisites

Whatever your platform, you'll need:

• An HTTPS redirect endpoint. You must be able to host your registered redirect URI over HTTPS. http://localhost is allowed for local and test use only; everything else must be https. (Mobile apps use a custom URL scheme instead — see Redirect URIs below.)
• Somewhere safe to keep tokens. Use platform-appropriate secure storage: a server-side session (web backend), the OS secure store — Keychain / Keystore (mobile), or in memory only with no refresh token (browser-only SPA). The per-platform storage tables in Integrate your app spell this out.

What to send

App name and description

A short name and one line on what the app does.

Platform(s) and backend

Tell us where the app runs so we register the right kind of client:

• Web — server-rendered (Next.js, ASP.NET Core, Express…) — confidential client, gets a client_secret
• Web — SPA / browser-only (React, Vue, Svelte with no server of your own) — public client, PKCE only
• iOS — native (Swift)
• Android — native (Kotlin)
• Cross-platform — specify React Native (Expo or bare) or Flutter

Also tell us whether the client has a backend (see Do you need a backend? above). This is what lets us issue the right client type — confidential vs. public — and decide whether offline_access applies. If you're a SPA planning to add a backend-for-frontend later, say so.

Redirect URIs

The URL(s) EntryIdP sends the user back to after authentication. Exact match only — no wildcards, no prefix matching. What this means per platform:

• Web: a path on your server, e.g. https://myapp.com/auth/callback
• Mobile: a custom URL scheme your app registers, e.g. com.myapp://callback. You choose this string; it doesn't need to exist yet. EntryIdP does not support Universal Links (iOS) or App Links (Android) — mobile callbacks use custom schemes only.
• Unsure? Send what you have and we'll guide you.

Post-logout redirect URIs

Where to send the user after they sign out. Same format and exact-match rule as redirect URIs. Can be the same as your redirect URI or different. Fine to leave blank if you haven't designed logout yet.

Scopes

What user data your app needs. Request the minimum:

Scope	Plain English	Request when
openid	Required by every client.	Always include it.
profile	Name, email address, and phone number (self-declared).	You display or use the user's profile.
offline_access	Keeps the user signed in silently by issuing a refresh token.	You have a backend or native mobile secure storage (see Do you need a backend?). Not for browser-only SPAs.
identity:verified	Government-ID verification result, date of birth, and ID number.	Your app makes legal-identity decisions. Don't request it otherwise.

If unsure, just request openid profile — we can expand the list later.

Target environment

test, demo, or production. Most integrations start in test.

Template

Copy, fill in, and send to entryidp@synapser.com. If your app needs more than one client (see below), submit one block per client.

App name:
Description: (one line — what does the app do?)
Platform(s): (iOS / Android / Web — server-rendered / Web — SPA / React Native Expo / Flutter / other)
Backend: (yes / no)
Redirect URI(s):
Post-logout redirect URI(s): (leave blank if not designed yet)
Scopes: (if unsure, write "openid profile")
Environment: (test / demo / production)

Worked examples:

Server-rendered web app

App name: Acme Portal
Description: Customer self-service portal for Acme Ltd.
Platform(s): Web — server-rendered (Next.js)
Backend: Yes
Redirect URI(s): https://portal.acme.com/auth/callback
Post-logout redirect URI(s): https://portal.acme.com
Scopes: openid profile offline_access
Environment: test

Native mobile app (iOS + Android, single codebase)

App name: Acme
Description: Consumer onboarding app for Acme Ltd.
Platform(s): iOS + Android (React Native / Expo)
Backend: No
Redirect URI(s): com.acme.app://callback
Post-logout redirect URI(s): com.acme.app://logout
Scopes: openid profile offline_access
Environment: test

Expo app targeting iOS, Android, AND web — two clients required

Expo's web build runs as a browser SPA. SPAs and native apps use different redirect URI schemes and have different refresh-token rules, so they need separate client registrations:

--- Client 1: native (iOS + Android) ---
App name: Acme (native)
Platform(s): iOS + Android (React Native / Expo)
Backend: No
Redirect URI(s): com.acme.app://callback
Post-logout redirect URI(s): com.acme.app://logout
Scopes: openid profile offline_access
Environment: test

--- Client 2: web (browser SPA) ---
App name: Acme (web)
Platform(s): Web — SPA / browser-only
Backend: No
Redirect URI(s): https://acme.com/callback
Post-logout redirect URI(s): https://acme.com
Scopes: openid profile
Note: no refresh tokens — user re-authenticates after 15 min
Environment: test

Not sure whether you need one client or two? Tell us your platforms and framework and we'll advise.

What you'll receive back

• client_id — your public client identifier.
• client_secret — only for confidential (server-side) clients — i.e. those with a backend (see Do you need a backend?). Treat it as a secret: never put it in mobile or browser code, and never commit it. Public clients (SPAs and mobile apps) don't get one — they're secured by PKCE instead.
• The issuer URL for your environment (see the environments table).

Once you have these, head to Integrate your app.