Sign-in with Apple and Google
Published Updated
Readers sign in to a tenant's site with an email address and a password. Integrations › Sign-in adds two buttons beside that form, Continue with Apple and Continue with Google, so a reader can sign up and sign in with an account they already have. This page takes a Tenant admin through both providers for the site, and says what readers see once they are on. The app shares the same setup; what only the app needs is on In-app purchase and sign-in.
Only a Tenant admin sees Sign-in, and every save is recorded in Audit logs as Sign-in providers updated.
Before you start
- The site is served on its own domain, over HTTPS. Apple and Google send a reader back only to an HTTPS address registered with them, and that address is on the domain of the tenant's public site, not on the console host.
- For Apple, a membership of the Apple Developer Program, under the organisation the reader should see they are signing in to. The same membership the app is published under, if the tenant has an app.
- For Google, a Google Cloud project, again owned by the publisher. A Firebase project created for push notifications is a Google Cloud project and can be used.
- If the tenant has an app, fill in Integrations › App links first, as App links describes. Sign in with Apple trusts the apps named there.
Open Integrations › Sign-in and keep it open: each provider's section shows a Callback URL with a button to copy it, which you register with the provider in the steps below. It is built on the site's domain:
| Provider | Callback URL |
|---|---|
| Apple | https://comics.example.com/api/v1/auth/apple/callback |
https://comics.example.com/api/v1/auth/google/callback |
The Apple section shows a second address, the Android app callback URL, which only the Android app uses.
If the operator later moves the tenant to another domain, these addresses move with it, and the new ones have to be registered with both providers, as Tenants notes.
Sign in with Apple
Everything on Apple's side is created in the Apple Developer account, under Certificates, Identifiers & Profiles.
What to create in the Apple Developer account
- An App ID with Sign in with Apple. Under Identifiers, open the App ID of the tenant's iOS app, or register one if the tenant has no app, and turn on the Sign in with Apple capability. The other two identifiers are grouped under this one, which Apple calls the primary App ID.
- A Services ID. Under Identifiers, register a Services ID, with a description readers may see, such as the site's name, and an identifier such as
com.example.comics.web. Turn on Sign in with Apple for it and choose Configure:- Primary App ID: the App ID of step 1.
- Domains and Subdomains: the site's domain alone, such as
comics.example.com. - Return URLs: the Apple Callback URL from the console. If the tenant has an Android app, add the Android app callback URL here as well.
- A key. Under Keys, register a key with Sign in with Apple turned on, configured with the same primary App ID. Download the
.p8file it offers. Apple offers it once, so keep it somewhere safe; a lost key is replaced by registering a new one. The Key ID is shown beside the key. - The Team ID, shown in the account's membership details.
Entering it in the console
In the Apple section of Integrations › Sign-in:
- Services ID: the identifier of the Services ID, such as
com.example.comics.web. The site shows the Apple button only when this is filled in. Leave it empty only when the iOS app alone is to offer Apple. - Team ID and Key ID: the ten-character IDs of step 4 and step 3.
- Private key (.p8): choose the downloaded file, or paste its contents.
- iOS bundle ID is not entered here: it shows the iOS app named under App links.
Turn on Offer Sign in with Apple and choose Save the sign-in providers.
The key cannot be read back: on a later visit the console shows only that one is stored. Replace swaps it for a new one, and Remove deletes it when you save.
Sign in with Google
Everything on Google's side is created in the Google Cloud console, in the publisher's project, under Google Auth Platform.
What to create in the Google Cloud console
- The consent screen. Under Branding, enter the name readers see when they choose an account, a support email, and the site's domain under Authorized domains. Under Audience, choose External, so any Google account can sign in, and publish the app to production. Until it is published, only the test users listed there can sign in. Publira asks Google only for a reader's identity, email address, and name, which Google classes as non-sensitive, so publishing does not wait for a review of them.
- A Web application client. Under Clients, create an OAuth client of type Web application, and add the Google Callback URL from the console under Authorized redirect URIs. Nothing goes under Authorized JavaScript origins.
Google shows a client secret for the new client. Publira does not use it, and the console has nowhere to enter it.
Entering it in the console
In the Google section of Integrations › Sign-in:
- Web client ID: the client ID of the Web application client, ending in
.apps.googleusercontent.com. The site shows the Google button only when this is filled in, and the Android app signs in with the same client. - iOS client ID: the client ID of an iOS client, which only the iOS app uses. Leave it empty if the tenant has no iOS app.
Turn on Offer Sign in with Google and choose Save the sign-in providers.
Checking that it works
Each provider's section shows its state:
| State | Meaning |
|---|---|
| Offered | On and complete: readers can sign in with it |
| Incomplete | On, but something it needs is missing, so readers are not offered it |
| Off | Saved, but turned off |
| Not set | Nothing is saved for it |
An Offered provider also lists, under Where readers see its button, each place a reader can meet it: Site, iOS app, and Android app. Each says Shown, or what that place still needs before it shows the button:
| Apple | ||
|---|---|---|
| Site | A Services ID | A Web client ID |
| iOS app | The iOS app named under App links | An iOS client ID, and Apple shown in the iOS app, since the app offers Google only beside Apple |
| Android app | A Services ID, and the Android app named under App links | A Web client ID |
A provider can therefore be Offered and still say the site does not show it: Apple without a Services ID, or Google without a Web client ID, is set up for the apps alone. Shown for an app means the setup covers it; the app itself also has to be built for it, as the app's page describes. Google in the iOS app depends on the build more than the rest, since the app shows it only when built with the same iOS client ID, so that row says Shown in an iOS app built with this iOS client ID instead.
The site picks up a change moments after it is saved. Open the site's sign-in page in a private window, choose Continue with Apple or Continue with Google, and sign in. A provider that sends you back to an error page of its own usually has an address that does not match: compare the address it reports with the Callback URL, character for character.
What readers see
The site's Sign in and sign-up pages show Continue with Apple and Continue with Google below the email form, separated by or. A reader signing up this way does not choose a password and does not confirm their email address: the provider has already confirmed it. If the site asks readers to agree to its terms of service or privacy policy, a first sign-in stops on Finish signing up for them to agree before the account is created.
The site's Sign in page also offers Sign in with a passkey beside them, in every browser that can use a passkey, and needs nothing set up under Sign-in for it. A reader who holds a passkey for the site signs in with it alone, without typing an email address or a password: they choose the button, or pick the passkey where the browser offers it in the email field's suggestions. A passkey made for the tenant's console is a different one and does not sign in to the site. If the reader closes the prompt, or the site does not accept the passkey, the page says so and the email form stays as it was. A reader whose account is suspended, or whose email address was never confirmed, cannot sign in with a passkey either.
The app shows the same Apple and Google buttons, on each phone where the setup covers it, as the app's page describes, and Sign in with a passkey where the app is the one named under App links, as Sign in with a passkey there describes. An account works in both: a reader who signed up on the site with Apple signs in to the app with Apple, a passkey added on the site signs in to the app, and the other way round.
An existing account and an Apple or Google sign-in
An Apple or Google account is linked to one reader's account on the tenant. Which one is decided the first time the reader uses it:
- The reader already has an account with the same email address. The Apple or Google account is linked to it, and the reader is signed in to their existing account, with their purchases and history. There is no confirmation step: Apple and Google have confirmed the address, which is the same proof the site's own confirmation mail asks for.
- The reader has an account with that address, but never confirmed it. The Apple or Google account takes it over: the account is linked, its address counts as confirmed, and the password it was created with is removed. Whoever created it without being able to confirm the address loses it to the address's owner.
- No account has the address. A new account is created, with the address the provider gave and no password.
A reader who chose Hide My Email with Apple gives the site an address at privaterelay.appleid.com instead of their own. It matches no existing account, so it creates a new one, and so does a Google account under another address than the reader's account. A reader who already has an account and wants to keep it signs in with their email address and links the Apple or Google account to it from Linked accounts, as described below.
The tenant's refused email addresses under Settings do not apply to these sign-ins, since the provider supplies the address. A reader whose account is suspended cannot sign in with Apple or Google either.
What a reader can manage
Under Settings › Security on the site, and from the app's account screen, Linked accounts lists the Apple and Google accounts the reader can sign in with, each with Unlink, and offers Link for each provider the site or the app offers that the account has none of yet. Link sends the reader to sign in with that provider and links the account they sign in to, whatever address it carries, so a Hide My Email address links as well as the reader's own. From then on, signing in with it opens the same account, on the site and in the app.
A link is refused, with the reason on the screen, when the Apple or Google account already signs in to another account on the site, which has to unlink it first, and when the reader's account already has an account of that provider linked, which they unlink before linking another.
The same screen on the site lists the reader's Passkeys, each with when it was added and when it last signed them in, and Remove. Add a passkey asks the browser for a new one, kept by the device's screen lock, a password manager, or a security key, and then for a name to tell it apart by, which the reader may skip. From then on, Sign in with a passkey signs them in with it. The section is there in every browser that can use a passkey, whatever is set up under Sign-in, and a reader can hold up to 20 passkeys. Passkeys on the app's account screen lists the same passkeys, adds one, and renames and removes each.
An account created through Apple or Google has no password. The same screen offers Set a password, which mails a link to set one, after which the reader can sign in with their email address as well. Until then:
- The account keeps one way to sign in: its last linked account cannot be unlinked while it holds no passkey, and its last passkey cannot be removed while it has no linked account.
- Deleting the account and changing the email address are confirmed by signing in with Apple or Google again, through Confirm with Apple or Confirm with Google, or with one of the reader's passkeys, through Confirm with a passkey, in place of the password, on the site and in the app alike.
Mail to a Hide My Email address
Apple forwards mail sent to a privaterelay.appleid.com address only from senders the publisher has registered with it. Mail from any other sender, the site's own password reset mail included, never reaches the reader.
The Apple section of Integrations › Sign-in shows the address the tenant's mail is sent from as Email sender, with a button to copy it: the Sender email address under Integrations › Email while the tenant sends through its own server, and the platform's sending address otherwise. Register it in the Apple Developer account, under Certificates, Identifiers & Profiles › Services › Sign in with Apple for Email Communication. Apple also checks that the sending domain passes SPF, as described there. If the sender changes later, because the tenant starts or stops sending through its own server or changes its address, register the new one as well.
Turning a provider off
Turning Offer Sign in with Apple or Offer Sign in with Google off removes its button from the site and the app, and keeps everything saved for it, so it can be turned on again as it was. The readers' links stay as well.
A reader who has a password goes on signing in with their email address. A reader who signed up with the provider has none, and cannot sign in until they set one: Forgot your password? on the sign-in page mails them a link. Tell such readers before you turn a provider off, for instance with an announcement. A reader with a Hide My Email address receives that mail only if the sender is registered with Apple, as described above.