> For the complete documentation index, see [llms.txt](https://docs.b2core.b2broker.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.b2core.b2broker.com/how-to-articles/manage-system-settings/how-to-use-b2core-as-a-trusted-identity-provider-oidc.md). # How to use B2CORE as a trusted identity provider (OIDC) 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. {% hint style="success" %} 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. {% endhint %} {% hint style="warning" %} 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. {% endhint %} ## 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](#good-to-know)). * The OIDC discovery URL for your B2CORE instance: ``` https:///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 1. Configure your OIDC client library with the discovery URL, Client ID, and Client Secret above. 2. Use the **Authorization Code flow with PKCE** if your library supports it (recommended for both web and mobile apps). 3. Request only the scopes you actually need — `openid` at minimum, plus `profile`, `email`, and `offline_access` as applicable. 4. 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. 5. 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`. {% hint style="info" %} **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. {% endhint %} ## Good to know {% hint style="info" %} **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. {% endhint %} {% hint style="info" %} **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. {% endhint %} {% hint style="warning" %} **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. {% endhint %} {% hint style="warning" %} **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. {% endhint %} ## Testing after setup 1. Trigger the login flow from your application (or your identity platform, if federating) and confirm it redirects through B2CORE's login page. 2. Log in with a real B2CORE account and confirm you land back in your app, signed in, with the expected user info. 3. If you requested `offline_access`, test a token refresh. 4. 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](#what-you-need-to-decide-before-requesting-access). --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.b2core.b2broker.com/how-to-articles/manage-system-settings/how-to-use-b2core-as-a-trusted-identity-provider-oidc.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.