Register Downstream Applications
EUnifyer is an identity provider in its own right. Any application that speaks OpenID Connect can authenticate its users against EUnifyer, exactly as it would against Okta, Auth0, or Microsoft Entra ID.
You register each application in Admin → Identity → Applications (the Outbound side of the Identity menu).
Inbound vs Outbound: which one do you need?
- Outbound (this page). EUnifyer as the IdP for other apps. Use when you want your portals, BI tools, or line-of-business apps to “Sign in with EUnifyer”.
- Inbound. another IdP signs users into EUnifyer. Use when your company already runs Entra ID, Okta, or Google Workspace and you want users to sign into EUnifyer with those credentials.
- Inbound roster sync. another IdP pushes the user list into EUnifyer. Complementary to inbound federation; covers offboarding, group sync, and just-in-time provisioning.
When to register an application
Register an app here when you want users to sign in to that app using their EUnifyer account. Common cases:
- An internal portal (HR, finance, asset management).
- A line-of-business tool that supports “Sign in with OIDC”.
- A custom dashboard, BI tool, or developer-facing console.
- A mobile or single-page app that needs the user’s identity.
This is the EUnifyer-as-IdP direction. For the opposite direction (EUnifyer signing in via your existing corporate IdP like Entra), see Federate Existing Providers.
Protocols supported
The wizard’s first question is the protocol:
| Protocol | When to pick | Notes |
|---|---|---|
| OpenID Connect | Default for modern apps, SPAs, mobile, anything cloud-native | Most apps; supports refresh tokens and userinfo lookup |
| SAML 2.0 | Legacy government / education / line-of-business apps | EUnifyer hands the app an Entity ID, SSO URL, and metadata URL |
OIDC: confidential vs public
For OIDC apps the wizard then asks for client type:
| Type | Use for | Has a client_secret | Auth flow |
|---|---|---|---|
| Confidential | Server-side web apps that keep secrets safely (most cases) | Yes | Authorisation Code |
| Public | Browser SPAs, mobile apps, anything where the secret would be visible to end users | No (uses PKCE) | Authorisation Code + PKCE |
If you are not sure, choose confidential and check whether the app supports a client secret.
Step 1: Register the application
In EUnifyer, open Admin → Applications, click Register application, and fill in:
| Field | What to put |
|---|---|
| Display name | Human-readable label (for example “Finance Portal”) |
| Client ID | A stable slug the application uses in OIDC requests (for example finance-portal). Lowercase letters, digits, and dashes only. We pre-fill from the display name. |
| Redirect URIs | One per line. Where the application receives the OIDC code after the user signs in. Example: https://finance.example.com/oidc/callback. Bare wildcards are rejected. Be specific. |
| Web origins | CORS / iframe origins. Required only for browser apps that call EUnifyer’s userinfo endpoint from JavaScript. |
| Public client | Tick this for SPAs / mobile apps. Leave unchecked for server-side apps. |
Click Register.
For confidential clients, the dialog immediately shows the Client secret once. Copy it now. You can fetch it again later from the application detail panel, but rotate it instead of relying on retrieval if you suspect it leaked.
Step 2: Plug the application into EUnifyer
The application detail panel shows the OIDC endpoints the downstream app needs:
| Endpoint | Used by the app to |
|---|---|
| Issuer | Identify EUnifyer in tokens. Most OIDC libraries take only this and derive everything else from the well-known document. |
| Authorization endpoint | Redirect users to log in |
| Token endpoint | Exchange the auth code for an access token + ID token |
| JWKS URI | Verify the signature on issued tokens |
| Userinfo endpoint | Look up the signed-in user’s profile |
| End-session endpoint | Sign the user out of EUnifyer |
Almost every OIDC library accepts just the Issuer URL and discovers the rest automatically by fetching <Issuer>/.well-known/openid-configuration. Prefer that wiring over hard-coding the individual endpoints.
The application’s OIDC configuration should look something like:
Issuer: https://<your-eunify-host>/realms/eunify
Client ID: finance-portal
Client secret: <value from EUnifyer>
Scopes: openid profile email
Auth flow: authorization_code (PKCE for public clients)
Redirect URI: https://finance.example.com/oidc/callbackStep 3: Verify
Open the downstream application in a private browser window:
- Click “Sign in with EUnifyer” (or whatever the app calls its OIDC button).
- You should land on the EUnifyer login screen.
- Authenticate. The app receives the OIDC code, exchanges it for tokens, and signs the user in.
If the app fails with redirect_uri_mismatch, double-check that the exact URI is listed under Redirect URIs in EUnifyer. Trailing slashes count.
Rotating the client secret
If a secret leaks (or as part of regular hygiene), open the application’s detail panel and click Rotate secret. The new secret is shown once. Update the downstream application’s configuration with it. Pending tokens issued with the old secret stay valid until they expire, so plan the rollout accordingly.
Removing an application
Click Remove on the application row. The OIDC client is deleted from EUnifyer. The downstream app can no longer obtain new tokens. Tokens already issued stay valid until they expire (typically one hour); use the End-session endpoint to invalidate them sooner.
SAML applications
The flow is the same: register, copy the endpoints, plug them into the downstream app.
For SAML the detail panel shows:
| Field | Value to give the downstream app |
|---|---|
| Entity ID | EUnifyer’s SAML issuer for this realm |
| SSO URL | Where the app should send AuthnRequests |
| Metadata URL | A fetch-this-once XML descriptor most SAML apps accept directly |
EUnifyer signs assertions by default, expects POST binding, and uses email as the NameID. If the downstream app needs a different NameID format or wants signed requests, contact your onboarding engineer.
Sign-in audit per application
The application detail panel has a Recent sign-in events section. Click Load events to fetch the last 50 Keycloak events scoped to this client, successful sign-ins, sign-in errors, sign-outs, and token exchanges. Use this to confirm that the integration is working end-to-end, or to investigate why a specific user can’t get in.
For organisation-wide audit (every action across every service), use Admin → Audit.
What is not yet self-service
A few advanced things still require an onboarding engineer (or direct Keycloak access). On the roadmap:
- Custom token claims: adding org-specific attributes (department, employee number) into ID tokens for the downstream app to read. Today the user profile attributes (set by Step 10 of the Entra guide) flow through but per-application claim shaping needs an engineer.
- Per-application role / scope mapping: defining custom OAuth scopes the application can request, and gating each scope on EUnifyer roles or groups.
If a rollout needs any of these, contact your EUnifyer onboarding engineer.