1What an OAuth client is
A client registration tells the IdP who can request tokens
An OAuth 2.0 client is a registration that identifies a specific application to EmpowerNow's identity provider. The registration defines what the application is allowed to do: which grant types it can use, which redirect URIs are permitted, how long its tokens last, and whether it requires a secret or uses PKCE.
Every application that needs to authenticate users through EmpowerNow, or call EmpowerNow APIs on behalf of users or services, must have a registered client.
| Client type | Typical use | Has client_secret? |
|---|---|---|
| SPA (Single-Page App) | React, Vue, Angular apps running in the browser. Uses PKCE — no secret needed. | No — uses PKCE instead |
| Web App (Confidential) | Server-rendered apps (Next.js SSR, Rails, etc.) that can keep a secret server-side. | Yes |
| Service / M2M | Backend services, CI/CD pipelines, crons. Use client_credentials grant type (no user). | Yes |
| Device Code | TVs, CLIs, or other devices with limited input. Uses device_code grant flow. | No |
2Open Clients Center
Administration → OAuth → Clients Center (/idp/clients-center)
| Client Name | Client ID | Type | Redirects | Status | Actions |
|---|---|---|---|---|---|
| My SPA App | spa_abc123 | SPA | 2 | ● Active | Configure |
| Backend Service | svc_xyz789 | M2M | — | ● Active | Configure |
The list shows all registered clients. Click + Register Client to start the template-driven registration wizard. Click Configure on an existing client to open its detail page.
3Choose a template
The first step is picking the right client type
The registration wizard opens with the Template Selector screen. Four templates are available. Each template pre-fills the correct grant types, security settings, and defaults for its client type.
For modern JavaScript frontends that authenticate users, SPA + PKCE is the most secure choice. It requires no secret in the browser and is the current best practice per OAuth 2.0 Security BCP.
4Basic settings
After selecting a template, fill in the basic settings form
| Field | Required | Notes |
|---|---|---|
| Client Name | Yes | Human-readable label. Appears in consent screens and admin logs. e.g. "My SPA App" or "Inventory Backend". |
| Application URI | No | The app's homepage URL. Shown in admin UIs; not functionally enforced in the auth flow. |
| Redirect URIs | Yes (for auth-code flows) | Newline-separated list of allowed callback URLs after login. Must exactly match what the app sends in the auth request. Required for SPA and Web App templates. |
| Post-Logout Redirect URIs | No | Where to send users after logout. Must be whitelisted here to avoid open redirect vulnerabilities. |
| Grant Types | Auto-filled | Pre-filled by template (e.g. authorization_code + PKCE for SPA). Editable but changing grant types changes the security model. |
The IdP does strict string matching on redirect URIs — no wildcards, no partial matches. If your app sends https://myapp.com/callback but you registered https://myapp.com/callback/ (trailing slash), the login will fail with an error.
5Live Preview Card
The right panel shows the JSON payload in real time
As you fill in the form, the Live Preview Card on the right side of the registration page updates in real time to show the exact JSON configuration that will be sent to the IdP when you click Register. This lets you verify every field before creating the client.
The Live Preview is especially useful for validating that redirect URIs are formatted correctly and that grant types match your expected flow. Compare against your IdP documentation before clicking Register.
6Copy credentials
Copy the client secret immediately — it will never be shown again
After clicking Register, the credentials modal appears showing:
After you close this modal, the secret cannot be retrieved — only rotated. Copy it now and store it in EmpowerNow Secrets Hub or another secure secrets manager. Never paste it into source code, config files committed to version control, or messaging apps.
7Post-creation checklist
Verify the client works before marking it production-ready
| Step | How to verify |
|---|---|
| 1. Update your application config | Set client_id in your app. For confidential clients, also set the client_secret from the credentials modal. |
| 2. Test the redirect URI | Initiate a login from your app. The browser should redirect to your app's callback URL after login. A redirect URI mismatch will show an error page. |
| 3. Configure allowed scopes | In the Client Configuration page (Scopes tab), add any custom scopes your app needs beyond the defaults (openid profile email). |
| 4. Enable PKCE enforcement (for SPAs) | In Security Settings, toggle Require PKCE to ON. This prevents auth-code interception attacks. |
| 5. Review token lifetimes | Default access token lifetime is 1 hour. For long-running services, consider increasing the refresh token lifetime in Advanced Settings. |
Register a separate client for each environment (staging, production). Staging and production clients should have different redirect URIs and separate secrets. Never share a client_id or secret across environments.