Job oauth2-sign-in-with-google-added-to-existing-login · revised 11 October 2026
Add Sign in with Google to your existing login without creating duplicate accounts
Users sign in with Google beside your existing login; first sign-in links to the right account only under a rule you approve, and a forged, replayed or code-injected sign-in is refused.
You might be seeing
- Customers ask for Sign in with Google and abandon sign-up at the password step
- A previous attempt created a second account when an existing customer used Google
- Nobody can say what happens when a Google user's email matches an existing account
No passwords, keys, card details or admin invites needed to start.
What usually happened
Adding a provider button is easy; deciding who a Google identity is in your user table is not. Matching on email alone can attach a stranger to a customer's account, ignoring the match creates duplicates, and a sign-in flow that does not check state, nonce and the token's audience, or does not tie the authorisation code to the browser that started the sign-in with PKCE, can be forged, replayed or fed a stolen code. The fault is the missing link between a provider identity and your accounts.
Who it’s for: A founder or product owner whose app has email-and-password accounts and whose customers ask for one-click Google sign-in, or whose sign-up drop-off suggests the password step is a barrier.
Usually starts when: Users already have accounts, so adding a Google button risks duplicate accounts, locked-out customers or someone taking over an account by registering with the same email at the provider.
The result: A new Google user gets one account and later sign-ins return to it. An existing user is linked only by the rule you approve before work starts. A tampered or replayed sign-in, a callback with a missing or wrong PKCE code verifier, and a token for another audience create no session, as shown by tests and a staging run with test Google accounts.
Check whether this job fits
Answer from what you know about your accounts and sign-in. It needs no secrets, user data or code.
Checks you can run yourself
Count how many accounts have unconfirmed emails
Ask your developer for the number of accounts whose email was never confirmed, as a count only. Do not send the list.
Look for: Whether the number is zero. Any other number changes which linking rules are safe.
What you get
- A pull request with the sign-in routes, the provider-identity table, the linking rule and tests
- A one-page note setting out the approved linking rule and what each failure shows the user
- Settings for your Google administrator: the staging and production redirect addresses and what to put on the consent screen
- A table of the callback failure cases tested (state, nonce, PKCE verifier, audience, expiry, an invalid code) and the response each returns
- Undo steps
Included
- Google as the single provider, using the server-side authorisation-code flow of OpenID Connect with PKCE (the S256 method) added next to the existing login
- A stored provider identity per user, keyed on Google's stable subject identifier, never on email alone
- One linking rule for existing accounts, chosen from the options we set out and approved by you in writing before work
- Checks of the state value, the nonce, the PKCE code verifier sent with the code exchange and the ID token's issuer, audience and expiry; state, nonce and verifier are created per sign-in attempt, stored on the server in the user's session, used once and cleared; tests use synthetic tokens and a stand-in token endpoint
- A way for a user to see and remove the Google link, and a path for a locked-out user that you approve
Not included
- Other providers: Microsoft, Apple, Facebook and single sign-on for company directories are separate jobs
- Repairing a Google or other social sign-in that already exists and fails with a redirect or callback error: see "Fix one social sign-in that fails with a redirect or callback error"
- Google's brand and app verification review, which your account holder completes
- Replacing your password system, adding two-step verification or redesigning sessions
- Merging or deleting existing duplicate accounts
- Restricting sign-in to one Google Workspace domain unless agreed in writing before work
- Legal or privacy advice on the data you collect
How we know it’s done
Agreed with you before work starts. Each check produces evidence you keep.
A test Google user not in your database signs in on staging, one account row is created with the provider subject identifier stored, and a second sign-in with the same Google user opens the same account.
Evidence: Database counts before and after both sign-ins and the account identifier shown in the session.
An existing test password account is linked under the approved rule, and a Google test account with the same email that does not satisfy the rule creates no link and no session for that account.
Evidence: Test output for both cases and the identity table before and after.
A sign-in callback with a missing or altered state value, a token with the wrong audience, a nonce that differs from the stored one, or an expired time creates no session, and a second callback carrying a state value that was already used also creates none.
Evidence: Test output for each case, showing the response and that no session exists.
With the token endpoint replaced by a stand-in that checks the S256 challenge the way an authorisation server does, a code exchange sent without the verifier, or with a verifier that does not match the challenge, is refused and the callback creates no session; the staging sign-in with your real Google test accounts sends the challenge and verifier and completes.
Evidence: Test output with the stand-in's log of each exchange and its answer, and the staging sign-in result.
With the token endpoint replaced by a stand-in that answers invalid_grant, the answer an authorisation server gives for an invalid or already-used code, the callback shows the agreed failure and creates no session. The app cannot detect a reused code by itself; the authorisation server rejects it and the app must handle that answer.
Evidence: Test output showing the stand-in's response, the page shown and that no session exists.
A synthetic token carrying the same subject but a different email maps to the same app account and creates no second account.
Evidence: Test output and the account count before and after.
Sign-off. You read the linking-rule note, the test output and the staging run, then sign off in writing and merge. Payment follows sign-off; your team deploys and completes the production Google configuration.
If it fails. If the agreed checks do not pass you do not pay for this fixed scope. If the cause is unverified emails with no confirmed-link route, a browser-only app or an excluded provider, we explain the evidence and stop. Wider work needs a new written agreement.
When it fits, and when we stop
It fits when
- The app is a server-side application with users in your own database and an existing session mechanism
- You can create a Google Cloud project and OAuth client, and a person can complete the consent screen
- The app's OpenID Connect or OAuth library can send a PKCE challenge and verifier, or a maintained library that can may be added
- A staging copy with an HTTPS address exists, so Google accepts the redirect address
- Your team can decide the linking rule and the lock-out path before work begins
- Your maintainer can review, merge and deploy the change
We stop and tell you if
- You want silent linking by email match for accounts whose emails were never verified; we decline that rule and offer a confirmed-link route instead
- The app has no server component, only a browser front end, so the code exchange cannot be done safely there
- Existing accounts have no unique, trustworthy identifier we can link to
- Nobody on your side can complete the Google consent configuration
- No maintained library that supports PKCE can be used and you do not want the small addition written and reviewed; or Google's endpoint rejects the PKCE challenge for your client type, in which case we stop and agree in writing whether to rely on state and nonce with the extra precautions in RFC 9700 section 4.5.3.2
What could go wrong
Before merge, closing the pull request changes nothing. After merge, reverting the commit removes the Google button and routes; accounts created through Google keep their data and can set a password through your normal reset. The Google client can be disabled by you at any time.
Scroll the table sideways to read it all.
| Risk | How we handle it |
|---|---|
| A stranger takes over an existing account by presenting the same email. | Identity is keyed on Google's subject identifier; linking needs the approved rule, and tests include a matching email that must not link. |
| A forged or replayed sign-in creates a session, or an authorisation code stolen from the browser is redeemed by someone else. | State, nonce, the PKCE verifier, issuer, audience and expiry are checked, each value is single-use, and tests send each failure with synthetic tokens and a stand-in token endpoint. |
| Google's endpoint does not accept PKCE for the client type in use. | Google's discovery document lists the S256 method but its web-server guide does not list the PKCE parameters, so the staging sign-in with your real test accounts sends the challenge and verifier and must succeed. If it does not, the job stops there and the next step is agreed in writing. |
| Users are locked out if Google access changes or is removed. | A lock-out path agreed before work, and a screen where a user can see and remove the link. |
A reviewer separate from the builder checks the diff, the linking rule against the written approval, the state, nonce, PKCE and audience checks and that no token, verifier or secret is logged. Your authorised maintainer merges and you complete the production Google configuration.
How we deliver
We arrange the work and independent review, then show you the result against the agreed checks. You keep authority over your systems.
- Agree the linking rule, the lock-out path and the staging and production redirect addresses in writing
- Read how accounts, sessions and password login work and where a provider identity fits
- Write the account-linking test cases first, including the negative cases
- Build the sign-in routes, identity table, token checks and link rule on a branch
- Run the cases with your test Google accounts on staging and with synthetic tokens, and capture the evidence
- Have an independent reviewer check the diff, the session handling and that no secret is logged, then hand over with undo steps
An enquiry books nothing and charges nothing. Scope, access route, linking rule and checks are agreed in writing first.
Need to keep it working?
If sign-in is business-critical, ask about the monthly service that checks credentials, consent-screen status and provider changes.
Ongoing work is separately scoped and quoted: no monitoring, response-time guarantee or automatic subscription is included in this job.
Explore an ongoing engineering lane, or mention the responsibility you need in your enquiry.
What you can check
This is a new service. We have not delivered this job for a client yet.
Other ways to get this done
- Your developer can follow Google's OpenID Connect guide, which sets out the flow, the state and nonce checks and token validation, and says to use the subject identifier rather than email. developers.google.com
- If your accounts live in a hosted identity or membership service, check whether it offers a Google connection setting before commissioning code.
Questions
Why not link accounts by email automatically?
An email at the provider is not proof that the person owns the account in your app, unless both sides have verified it. We use Google's stable subject identifier and link only by a rule you approve.
Will users be locked out of password login?
No. The password login stays unless you decide otherwise. A Google user can see and remove the link.
How is this different from fixing a sign-in that shows an error?
This job adds Google beside a password login and settles how Google users map to your accounts. If a Google or other social sign-in already exists and fails with a redirect or callback error, "Fix one social sign-in that fails with a redirect or callback error" is the smaller repair.
Why PKCE as well as state and nonce?
State ties the return to the browser that started the sign-in and the nonce ties the ID token to it. PKCE additionally ties the authorisation code to the app that asked for it, so a code taken from the browser cannot be redeemed elsewhere. RFC 9700 recommends it even for server-side apps with a client secret.
What about Microsoft or Apple sign-in?
Those are separate jobs. Each provider needs its own checks.
Do you need my Google client secret?
No. You create a staging client and keep the secret in your secret store.
Send an enquiry
Send us
- The app's language and framework, and how users sign in today
- Whether account emails are verified, as a yes, no or partly
- Whether you want Google sign-in for everyone or one company's staff only
- Do not send client secrets, user lists, session secrets or code in the first enquiry
Later, once you agree
- Read access to the code through a company-controlled repository or export, and a staging environment you control
- A Google OAuth client for staging, created by you; the client secret stays in your secret store
- Two or three test Google accounts that you own, and the staging redirect address added to the client
- Your written choice of linking rule
You own the app, the user table, the Google Cloud project, the OAuth client and its secret. We work on a branch through a company-controlled identity, with test Google accounts you own. Production credentials stay with you.
Email fallback: open your mail app
If website submission is unavailable, review and send the fallback email yourself. An email fallback is not a website receipt. Or write to hello@syntheticindustry.ai with “oauth2-sign-in-with-google-added-to-existing-login” as the subject.