How to use B2CORE as a trusted identity provider (OIDC)

Learn how to let a third-party application offer "Log in with B2CORE" by connecting to B2CORE as an OpenID Connect (OIDC) identity provider

This guide is for brokers who want another application — your own product, a partner's app, or an identity platform like Keycloak — to let users sign in with their existing B2CORE account, instead of building a separate login.

B2CORE acts as the OpenID Connect (OIDC) identity provider. Your application (the relying party) redirects users to B2CORE to log in, and gets back a token proving who they are. Users authenticate once against their B2CORE identity; they do not create a separate account for your app.

This enables single sign-on (SSO): users sign in once with their B2CORE account and gain access to your connected application without a separate login.

This feature has a one-time setup fee. Contact your account manager or our support team to confirm the fee and availability before requesting access.

Is this the right fit?

Use this if:

You have a web or mobile app and want a "Sign in with B2CORE" option.
You want to federate B2CORE into another identity system you already run (for example, add B2CORE as an identity provider inside your own Keycloak realm).

This is standard OAuth2 / OIDC — any mainstream library or identity platform (Keycloak, Auth0, oidc-client-ts, openid-client, go-oidc, Passport, NextAuth, and others) can consume it, since everything the client needs is published in one discovery document.

What you need to decide before requesting access

Have answers to these ready — your account manager will ask for them when registering your application:

Item	What we need
Application name	A short, human-readable name (for our records and any consent screen).
Redirect URI(s)	The exact URL(s) in your app that should receive the login response, for example `https://app.example.com/auth/callback`. Must be exact — scheme, host, path, and trailing slash all matter.
Post-logout redirect URI(s)	Where users land after logging out, for example `https://app.example.com/`.
Scopes	`openid` is always required. Add `profile` and `email` if you need the user's name/email. Add `offline_access` only if you need long-lived refresh tokens.

What you'll receive from us

Once your application is registered, you'll receive:

A Client ID (matches the application name you provided).
A Client Secret, delivered through a secure channel. Store it the way you'd store a database password; it does not expire but can be rotated on request (see Good to know).
The OIDC discovery URL for your B2CORE instance:
```
https://<your-api-host>/srvsz/auth/hydra/v1/.well-known/openid-configuration
```
Point your OIDC library at this single URL — it will discover the authorization, token, userinfo, JWKS, and logout endpoints on its own. You should not need to hard-code any of the individual endpoints.

Integrating your application

Configure your OIDC client library with the discovery URL, Client ID, and Client Secret above.
Use the Authorization Code flow with PKCE if your library supports it (recommended for both web and mobile apps).
Request only the scopes you actually need — openid at minimum, plus profile, email, and offline_access as applicable.
For the user's profile info, call the /userinfo endpoint (or decode the id_token) rather than trying to read anything out of the access_token — the access token is opaque and not meant to be parsed.
To log a user out, redirect them to the discovery document's end_session_endpoint with id_token_hint and your registered post_logout_redirect_uri.

Federating instead of integrating a custom app? If you're adding B2CORE as an identity provider inside another identity platform you run (for example, Keycloak) rather than a custom app, configure it as a generic OpenID Connect provider using the same discovery URL, Client ID, and Client Secret above — the exact steps depend on your platform. Some platforms use a fixed callback URL tied to a provider alias you choose (Keycloak's broker endpoint is one example); if yours does, agree on that alias with us before we register your redirect URIs, since they must match exactly.

Good to know

Logout is local only. Redirecting to the logout endpoint ends the session for your app; it does not sign the user out of B2CORE itself or any other app they're signed into. There is no cross-app "logout everywhere" today.

Refresh tokens are one-shot. Each refresh returns a new refresh token that replaces the previous one — don't reuse an old one after refreshing.

Redirect URIs must match exactly. Add any local/dev URLs you need during testing to your initial request; changing them later means contacting us again.

Rotating your Client Secret requires contacting B2Broker support. There is a short window between us generating the new secret and you updating your app where logins with the old secret will fail — plan the swap for low-traffic hours.

Testing after setup

Trigger the login flow from your application (or your identity platform, if federating) and confirm it redirects through B2CORE's login page.
Log in with a real B2CORE account and confirm you land back in your app, signed in, with the expected user info.
If you requested offline_access, test a token refresh.
Test the logout flow and confirm it clears your app's session.

Questions / support

Reach out to your B2Broker account manager or support channel with your broker name and the application details from the table above.