# Switch from Google to signo: Auth.js (NextAuth)

Tested on 20 Oct 2026 with Auth.js (`@auth/core` 0.41.3, through `@auth/express` 0.12.3) against a running signo. A new person signed up and signed in, and a person who had signed up with Google kept their account.

The examples use `login.example.com` for signo and `example.com` for your site.

## 1. Register your site with signo

On the public signo, sign in at https://usesigno.co.uk/account/sites and add your site with the redirect URI below. The page shows the issuer (`https://usesigno.co.uk`), a client ID and a client secret.

On your own signo, run this on its server instead:

```
docker compose exec signo signo clients add --name "Example" --redirect-uri https://example.com/api/auth/callback/signo
```

It prints the issuer, a client ID and a client secret. The redirect URI is Auth.js's callback for a provider whose `id` is `signo`: `/api/auth/callback/signo` in Next.js, or `<your Auth.js base path>/callback/signo` in other frameworks.

## 2. Replace the Google provider

In `auth.ts`:

```diff
 import NextAuth from "next-auth"
-import Google from "next-auth/providers/google"

 export const { handlers, auth, signIn, signOut } = NextAuth({
-  providers: [Google],
+  providers: [
+    {
+      id: "signo",
+      name: "signo",
+      type: "oidc",
+      issuer: process.env.AUTH_SIGNO_ISSUER,
+      clientId: process.env.AUTH_SIGNO_ID,
+      clientSecret: process.env.AUTH_SIGNO_SECRET,
+    },
+  ],
 })
```

In `.env`:

```diff
-AUTH_GOOGLE_ID=...
-AUTH_GOOGLE_SECRET=...
+AUTH_SIGNO_ISSUER=https://login.example.com
+AUTH_SIGNO_ID=<client id>
+AUTH_SIGNO_SECRET=<client secret>
```

If your code calls `signIn("google")`, change it to `signIn("signo")`. Auth.js's built-in sign-in page shows a "Sign in with signo" button without further changes.

Nothing else changes. Auth.js uses PKCE by default, which signo requires. It reads the person's email and name from the ID token, and signo puts them there, as Google does.

## 3. Keep the people who signed up with Google

If your site stores users through an Auth.js adapter (a database), a person who signed up with Google arrives from signo with a new identity. By default Auth.js refuses to attach it to the existing user with the same email and shows the error `OAuthAccountNotLinked`. In the test, that is what happened.

Add one line to the signo provider:

```diff
     {
       id: "signo",
       ...
       clientSecret: process.env.AUTH_SIGNO_SECRET,
+      allowDangerousEmailAccountLinking: true,
     },
```

With it, the person signs in to their existing account; in the test they landed on the same user ID as before. Auth.js calls the option "dangerous" because some providers send email addresses they never checked. signo only signs people in after they have opened a link sent to their address, so every email it sends is verified. Leave the option off for any provider you don't know does the same.

Without an adapter, Auth.js keeps no user records, so there is nothing to link. If your own tables store data under the person's Google ID (`sub`), look those rows up by email the first time someone signs in with signo, because their signo `sub` is different.