OIDC Authentication with Keycloak (and Auth0, Okta, Azure AD)

Question

If your team already runs an identity provider, the last thing you want is a second login system. You want your apps to trust the identity system you already have — whether that's Keycloak, Auth0, Okta, or Azure AD. OpenID Connect (OIDC) is the protocol that makes that possible, and a self-hosted WAF can speak it for you.

SafeLine supports OIDC out of the box. Instead of adding an OIDC client library to each app, you configure the identity provider once in the WAF, and it handles the redirect and the login gate in front of your applications. Here's the setup, straight from the docs.

What OIDC actually is

OpenID Connect is an identity layer built on top of OAuth 2.0. It lets a client application verify who a user is, based on the authentication result from an authorization server — and get back basic user information — without the client ever handling the user's credentials directly.

For a WAF, that's a clean fit: the WAF fronts your app, redirects unauthenticated visitors to your identity provider, and only lets approved users through.

Step 1: Prepare your OIDC provider

The docs walk through Keycloak as the reference example, since it's a common self-hosted choice. Here's how to get the parameters SafeLine needs:

1. Log in to the Keycloak admin console.
2. Select or create a Realm.
3. In the left menu, click Clients → Create to create a new client.
4. Fill in a Client ID — a unique identifier for the client.
5. In the Settings tab:
   • Valid Redirect URIs — add the application's callback address, for example https://example.com/.safeline/auth/api/callback/oidc.
   • Web Origins — add the application address, for example https://example.com.
6. Save, then switch to the Credentials tab and copy the Client Secret.

The key things to record:

Parameter	Example
OIDC Discovery URL	https://{keycloak-host}/realms/{realm-name}
Client ID	The client ID you created
Client Secret	The secret from the Credentials tab

The callback path is fixed: append /.safeline/auth/api/callback/oidc to your application URL.

Step 2: Configure SafeLine

In the SafeLine console, go to Auth → Settings → Login Configuration, find Third-Party Login, and select OIDC.

Fill in the form:

Field	What it's for
OIDC Server URL	Your provider's discovery URL. SafeLine appends .well-known/openid-configuration automatically
Client ID	From your OIDC provider
Client Secret	From your OIDC provider
Title Name	Shown on the blocking page — defaults to "Sign In - OIDC"
Use Proxy to Access	Check if your requests go through a proxy
Auto Merge Account	Automatically match incoming logins to existing accounts by email or phone number

Click Submit to save the binding.

Step 3: Enable OIDC on the application

1. Open Applications and pick the app you want to protect.
2. In that app's AUTH → Login Methods configuration, enable OIDC.
3. Save.

What the login flow looks like

Once OIDC is enabled for an application:

1. A visitor opens the app and sees the OIDC login option.
2. Clicking it redirects them to your identity provider's login page.
3. After authenticating there, they're redirected back to SafeLine.
4. First-time users need to be approved by a SafeLine administrator before they can access the app.
5. Approved users get authorized and don't need another review for later visits; unapproved users are blocked.

Managing users

On AUTH → User Management you can view which users are linked, review new users, manage access permissions, and manually merge accounts.

FAQ

Can't redirect to the OIDC provider after integration?

Check that the OIDC discovery URL is correct and that it's reachable from a browser and returns valid JSON.

Callback fails after the user authenticates with the provider?

Confirm the callback address is configured correctly — protocol (http/https), domain, and path all need to match.

What scopes does SafeLine request by default?

openid, profile, and email (optional, used to link accounts), plus phone (optional, for account linking).

Do I need to write OIDC code in my app?

Not for the login gate itself. The WAF handles the redirect flow. You'd only add app code if the application needs the authenticated user's identity — via the auth callback flow.

Which providers are supported?

The docs name Keycloak, Auth0, Okta, and Azure AD, and note the list isn't limited to those — anything speaking standard OIDC should work.

---

If you already run Keycloak, Auth0, Okta, or Azure AD — are your internal apps currently trusting it, or are you maintaining a second login system?

---

Ready to protect your sites without paying for a cloud WAF?

• ⭐ SafeLine WAF on GitHub — give it a star if you find it useful
• 🔗 Official Docs — installation guide, configuration, and API reference
• 🧪 Live Demo — see the dashboard in action (no login required)