> 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-enable-sign-in-with-google-and-apple.md). # How to enable sign-in with Google and Apple This guide is for brokers who want their clients to be able to log in or register using their Google or Apple account, in addition to (or instead of) email and password. It explains what you need to prepare on your side and what happens once you hand the information to B2Broker. {% hint style="info" %} This is a **joint setup**: you own the Google/Apple developer accounts and credentials, B2Broker wires them into your B2CORE instance. Nothing is enabled until both sides are done. {% 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 %} ## What you get * A "Sign in with Google" and/or "Sign in with Apple" button on your login and registration pages. * New users who sign up this way are created automatically — no separate registration form. * Users who already have a password account can also link a Google/Apple account later (linking is by email address). ## Before you start * Confirm with your B2Broker account manager that social sign-in is available for your B2CORE instance. This depends on you already running on the current identity platform. * Decide **which providers** you want: Google only, Apple only, or both. Apple requires a paid Apple Developer account, so plan for that if you want it. * You will need someone on your side with access to your company's Google Cloud / Apple Developer accounts (or the ability to create new ones). ## What you need to prepare — Google 1. **A Google Cloud project.** Use an existing company project or create a new one dedicated to sign-in. 2. **OAuth consent screen.** Configure: * App name, support email, logo (this is what your users will see on the Google consent prompt). * Scopes: `openid`, `email`, `profile`. * Publishing status: while the app is in **Testing**, only explicitly added test users can sign in — anyone else gets `access_denied`. Move the app to **Published** before go-live. 3. **An OAuth 2.0 Client ID** (application type: **Web application**). * We will give you the exact **Authorized redirect URI** to register — it is tied to your B2CORE instance's hostname and looks like: ``` https:///srvsz/auth/clients/v1/self-service/methods/oidc/callback/google ``` * Add the same host (no path) as an **Authorized JavaScript origin**. 4. Copy the resulting **Client ID** and **Client secret**. ## What you need to prepare — Apple Apple's setup has more moving parts and requires an active [Apple Developer Program](https://developer.apple.com/programs/) membership. 1. **An App ID** with the **Sign In with Apple** capability enabled (reuse an existing App ID if you have one, or create a new one). 2. **A Services ID** — this is the actual OAuth client Apple uses. When configuring it: * **Domain**: your B2CORE instance's API host (no scheme, no path). * **Return URL**: the Apple callback URL we provide, in the same shape as Google's above but ending in `/apple`. 3. **A "Sign in with Apple" private key (`.p8` file)** generated under Apple's **Keys** section, with the Sign In with Apple capability linked to your App ID.

This file is only downloadable once — save it immediately somewhere safe.

4. Your **Team ID** (10-character alphanumeric, shown in your Apple Developer account header). 5. The **Key ID** of the key you created in step 3. {% hint style="info" %} You'll end up with five pieces of information: Services ID (client ID), Team ID, Key ID, the `.p8` private key file, and — unlike Google — there is no separate "client secret" to copy; Apple's secret is derived from the other four. {% endhint %} ## Handing credentials to B2Broker Send us: * Google: Client ID + Client secret. * Apple: Services ID, Team ID, Key ID, and the `.p8` private key file. {% hint style="warning" %} **Treat these as secrets** — especially the Apple private key. Send them through a secure channel your account manager provides (a secrets share link or an encrypted attachment), not plain email or chat. We'll confirm once they're stored securely on our side and let you know when the buttons are live. {% endhint %} ## What happens next Once we have your credentials, we enable the feature on your B2CORE instance and deploy. {% hint style="info" %} This typically causes a brief restart of the login service — no downtime is expected, but avoid scheduling it during peak hours. {% endhint %} ## Testing after go-live 1. Open your login page — you should see the Google/Apple button(s). 2. Sign in with a real account for each enabled provider. 3. Confirm the user lands signed in, and that their email/name look correct in your admin panel. 4. If Google is still in **Testing** mode, only test users you added to the consent screen will be able to sign in — everyone else will see `access_denied`. Publish the app before advertising the feature to real users. ## Good to know {% hint style="info" %} **Apple only shares the user's name and email on their very first consent.** If a user revokes your app in their Apple ID settings and signs in again later, Apple will only send back an anonymous identifier — the name may be missing from then on. This is an Apple limitation, not a bug on our side. {% endhint %} {% hint style="info" %} **Apple emails may be "private relay" addresses** (`...@privaterelay.appleid.com`). These are real, working addresses — just routed through Apple. Treat them as the user's canonical email; they will not automatically match an existing password account that used the user's real email. {% endhint %} {% hint style="info" %} **Google requires a verified email.** If a Google account's email isn't verified, sign-in will fail by design — this protects your user base from unverified identities. {% endhint %} {% hint style="info" %} **Provider IDs are fixed** (`google`, `apple`). If you ever need to rotate credentials (for example, a leaked secret), contact B2Broker — we can update them without changing the login URLs your users already use. {% endhint %} ## Questions / support Reach out to your B2Broker account manager or support channel with your broker name and which provider(s) you're setting up. --- # 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-enable-sign-in-with-google-and-apple.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.