Members sign in with their Google account. On Android the sheet belongs to the operating system and the member never leaves your app; everywhere else it opens the browser and returns.
Before you start
Section titled “Before you start”| Console | Google Cloud Console |
| Endpoint group | Social Login |
| Returned, and verified — Google can match an existing account | |
| Signs in | Inside the app on Android, in the browser elsewhere |
Google is the one provider where the app and the website need separate OAuth clients. Read The Android client before you finish, because it is the step that has no field on the Memberside side and is therefore the one people skip.
Create the web client
Section titled “Create the web client”-
Open the Google Cloud Console and pick or create a project.
A project is a container for the credentials. One per site is tidy; one for everything you run is also fine.
-
Configure the OAuth consent screen.
Under APIs & Services → OAuth consent screen, choose External unless every member has an account in your Google Workspace. Fill in the app name, the support email and the developer contact email. These are what your members read on the consent screen, so use the community’s name, not yours.
-
Add the
emailandprofilescopes.Nothing more is needed. Asking for more triggers Google’s verification review for no benefit.
-
Create the credentials.
APIs & Services → Credentials → Create credentials → OAuth client ID, type Web application.
-
Add the redirect URI.
Under Authorized redirect URIs, paste the address from Memberside → API Keys → Social Login → Google. It looks like
https://yoursite.com/wp-json/memberside/v1/social/callback/google. See Redirect URLs. -
Copy the client ID and client secret.
Create the Android client
Section titled “Create the Android client”Do this second, in the same project.
-
Create another OAuth client ID, type Android.
-
Enter your package name.
The same application id your app is built with. It is on the app’s build settings in the builder.
-
Enter the SHA-1 certificate fingerprint.
The fingerprint of the certificate your app is signed with — see Android signing for where to find it.
-
Once the app is on Google Play, add the Play App Signing SHA-1 too.
Google Play re-signs your upload with its own key, so the certificate on members’ phones is not the one you signed with. Add both fingerprints to the same client.
The Android client
Section titled “The Android client”This is why Google sign-in works in the preview and fails on a real phone. The preview uses the browser flow and the web client; the built app uses the SDK and the certificate.
What to paste into Memberside
Section titled “What to paste into Memberside”Under Memberside → API Keys → Social Login → Google:
| Field | Value | Required |
|---|---|---|
| Client ID | The web client ID | Yes |
| Client secret | The web client secret | Yes |
| iOS client ID | The iOS OAuth client, if you created one | No |
| Android client ID | The Android client, for your records only | No |
The iOS client ID is only read by the in-app Google button on iOS. The browser flow uses the web client ID above it.
When it does not work
Section titled “When it does not work”| Symptom | Cause | Fix |
|---|---|---|
| Works in preview, fails in the built app | The SHA-1 is not registered against an Android client | Add it, then sign in again — no rebuild needed |
| Fails after the app went live on Google Play | Play re-signed the app with its own key | Add the Play App Signing SHA-1 as well |
| “redirect_uri_mismatch” | The registered URI differs from the one sent | Copy it again from the API Keys screen |
| “This app is blocked” or a verification warning | The consent screen is unpublished and the member is not a test user | Publish the consent screen |
| “Access blocked: authorization error” | The web client is of the wrong type | It must be Web application, not Android or iOS |
| The button is missing entirely | Not picked on the feature | Choosing providers |