Read in:
English
Русский

OAuth sign-in (Google & GitHub)

By default, readers sign in via a magic link sent to their email. OAuth lets them sign in with Google or GitHub in one click — no waiting for email, no switching apps.

The trade-off: OAuth requires a one-time setup where you register an application with Google or GitHub and enter the keys in the trip2g admin panel.

How it works

OAuth does not grant access by itself. Access depends entirely on whether the provider email matches a user you have already registered in trip2g.

Two steps happen in sequence:

  1. You add the user in trip2g — enter their email address and assign a role (reader or admin).
  2. The user signs in via OAuth — their email at Google or GitHub must match the email you registered.

If the email matches, they get in. If it does not match any registered user, access is denied.

sequenceDiagram
    participant Admin
    participant trip2g as Trip2G
    participant Reader
    participant Provider as Google / GitHub

    Admin->>trip2g: Add user (email + role)
    Reader->>Provider: Sign in (one click)
    Provider-->>trip2g: Verified email
    alt Email matches a registered user
        trip2g->>Reader: Access granted
    else No matching email
        trip2g->>Reader: Access denied
    end

Set up Google OAuth

Step 1. Create a project

  1. Open Google Cloud Console.
  2. Create a new project or select an existing one.
  1. Go to APIs & Services → OAuth consent screen.
  2. Click Get started.
  3. Enter an app name (for example, the name of your site).
  4. Enter a support email address.
  5. Under Audience, choose External (any Google user) or Internal (your Google Workspace organisation only).
  6. Complete the remaining fields and save.

Step 3. Create credentials

  1. Go to APIs & Services → Credentials.
  2. Click Create credentials → OAuth client ID.
  3. Select Web application as the application type.
  4. Under Authorized redirect URIs, add: 
    https://your-domain.com/_system/auth/google/callback
  5. Click Create.
  6. Copy the Client ID and Client Secret.

Set up GitHub OAuth

  1. Open GitHub Developer Settings.
  2. Click New OAuth App.
  3. Fill in the form:
    • Application name: your site name
    • Homepage URL: https://your-domain.com
    • Authorization callback URL: 
      https://your-domain.com/_system/auth/github/callback
  4. Click Register application.
  5. Copy the Client ID.
  6. Click Generate a new client secret and copy the Client Secret.

Enter keys in the admin panel

  1. Sign in to the trip2g admin panel.
  2. Go to Admin panel → Google OAuth or GitHub OAuth.
  3. Enter the Client ID and Client Secret.
  4. Save and activate the provider.

Adding OAuth credentials in the admin panel — the homepage and callback URLs to copy, plus the Client ID and Client Secret fields and a Create button

Once activated, the sign-in screen shows a Sign in with Google or Sign in with GitHub button next to the email field. Deactivating the provider removes the button; users fall back to email magic links.

Turning off sign-in by email

The email field is the door trip2g keeps open by default, and dropping a provider sends everyone back to it. On an instance where accounts only ever come from a provider, that door opens for nobody: a reader who tries it gets a code for an account that does not exist, and blames you for it.

Set DISABLE_EMAIL_SIGNIN="true" in the environment and trip2g stops offering it. The email field, its button and the captcha disappear from the sign-in screen, and the API refuses an email code outright — no client can ask for one behind the screen's back. Only the provider buttons remain.

The admin config carries an email_signin_enabled switch for the same thing at runtime, without a restart. The environment variable is the stronger of the two: while it is set, the switch in the panel cannot bring email sign-in back.

Before you set it, make sure at least one provider actually works. With email sign-in off and every provider failing, nobody can sign in, and that includes you.

The Google and GitHub buttons always read "Sign in with Google" and "Sign in with GitHub" — the provider's own name is what a reader needs. An OIDC provider is the one that needs naming, since "SSO" names a protocol rather than a destination; see en/user/oidc for OIDC_DISPLAY_NAME.

Security

The Client Secret is stored encrypted in the database. Even if a database backup is exposed, the secrets remain unreadable without the encryption key.

Similar notes

Backlinks