How to enable sign-in with Google and Apple

Learn how to prepare Google and Apple developer credentials so your clients can sign in or register in B2CORE using their Google or Apple account

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.

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.

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.

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

A Google Cloud project. Use an existing company project or create a new one dedicated to sign-in.
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.
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://<your-api-host>/srvsz/auth/clients/v1/self-service/methods/oidc/callback/google
```
- Add the same host (no path) as an Authorized JavaScript origin.
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 membership.

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).
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.
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.

Your Team ID (10-character alphanumeric, shown in your Apple Developer account header).
The Key ID of the key you created in step 3.

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.

Handing credentials to B2Broker

Send us:

Google: Client ID + Client secret.
Apple: Services ID, Team ID, Key ID, and the .p8 private key file.

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.

What happens next

Once we have your credentials, we enable the feature on your B2CORE instance and deploy.

This typically causes a brief restart of the login service — no downtime is expected, but avoid scheduling it during peak hours.

Testing after go-live

Open your login page — you should see the Google/Apple button(s).
Sign in with a real account for each enabled provider.
Confirm the user lands signed in, and that their email/name look correct in your admin panel.
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

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.

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.

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.

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.

Questions / support

Reach out to your B2Broker account manager or support channel with your broker name and which provider(s) you're setting up.

How to enable sign-in with Google and Apple

On this page