Skip to content

Get a client ​

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 are two ways to get one, depending on what you are doing.

Trying EntryIdP out? Register your own clients yourself, in a sandbox — your own tenant on the Demo or Test environment, created in one face scan at {issuer}/tenant. It arrives with a working app already registered, so you can watch a real sign-in complete before writing any code. Sandboxes are not available on Production.

Going live? We register production 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, .NET MAUI) → 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), Flutter, or .NET MAUI

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:

ScopePlain EnglishRequest when
openidRequired by every client.Always include it.
profileName, email address, and phone number (self-declared).You display or use the user's profile.
offline_accessKeeps 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:verifiedGovernment-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 / .NET MAUI / 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
More examples — native mobile, and Expo targeting web too

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.

EntryIdP — Synapser