glue-agency / m2-glue-auth

1.2.1 2026-11-09 10:49 UTC

Requires

• php: >=7.4.0
• google/apiclient: ^2.6
• magento/magento2-base: ^2.3
• magento/module-backend: *
• magento/module-user: *

OSL-3.0

• security
• google
• tool
• magento

Published on Packagist.org on 2026-11-09 10:49 UTC

README

Signs administrators in to the Magento 2 Admin Panel with their Glue Google account.

Installation

composer require glue-agency/m2-glue-auth
php bin/magento module:enable GlueAgency_BackendGoogleSignOn
php bin/magento setup:upgrade

Configuration

Go to STORES > Settings > Configuration > SECURITY > Glue Backend Sign On.

Setting
Enable	Off by default.
Require 2-Step Verification	Off by default. An extra, per-install check: the proxy normally enforces 2-Step Verification for every install. See below.
Proxy URL	Where sign-on runs. Already filled in.
Google client ID	Already filled in.
Hosted domain	Which Google accounts may sign in. Already filled in.
Domain based rules	Maps an email domain to the admin role a new user is created in, e.g. glue.be => Administrators.

Only Enable and the domain rules normally need touching.

Before enabling, this install has to be registered with the sign-on service. The value to hand over is shown under the Enable setting; ask a maintainer to add it.

Requiring 2-Step Verification

2-Step Verification is enforced at the proxy: with GOOGLE_REQUIRE_TWO_STEP=true on oauth.glue.be, it refuses a sign-in without it on every install at once, whatever version of this module (or of the Craft and Laravel packages) it runs, and switching it off again is one .env change there. The proxy's request log names the refused account. From 1.2.1 this module recognises that refusal: the admin sees the 2-Step Verification message below instead of "The sign-in could not be completed.", and system.log gets a Glue sign-on: line saying the proxy refused it.

The module's own setting is an extra check for an install that wants it whatever the proxy does. Google reports how the user last signed in to their Google account in the id_token's amr claim. With Require 2-Step Verification on, a sign-in counts when it lists mfa (a second factor), hwk (a security key) or swk (a passkey), in any order; a password alone, or no amr at all, is refused. The check runs before the admin user is looked up, so a refused sign-in never creates one. Every sign-in's amr and auth_time are written to var/log/system.log (lines starting Glue sign-on:), and so is each refusal.

Either way, the admin is told: "This site requires 2-Step Verification, and your last Google sign-in did not use it. Sign out of Google, then sign in again with your second step or a passkey."

Both checks only work once all of these are in place, which is why the setting is off by default:

• The proxy asks Google for the claim: GOOGLE_SECURITY_CLAIMS=true on oauth.glue.be (implied by GOOGLE_REQUIRE_TWO_STEP=true).
• The Google OAuth client has Authentication strength claims and Session age claims ticked, under Google Auth Platform → Settings → Advanced settings.
• The glue.be Workspace enforces 2-Step Verification (Admin console → Security → Authentication → 2-step verification). Otherwise an account without it is refused on every install that requires it.
• Allow user to trust the device is off there, or a sign-in on a trusted device may skip the second step and be refused, however often the user signs in again. (Not tested yet.)

amr describes the user's last sign-in to Google in that browser, not this one, and Google cannot be asked to make them sign in again. A Google session that started before 2-Step Verification was turned on keeps reporting a password only: that user is refused until they sign out of Google and back in. A passkey-only sign-in is expected to report swk, but has not been tested yet.

This is Google's 2-Step Verification, checked at sign-on. It is separate from Magento's own Two-Factor Authentication module (Magento_TwoFactorAuth), which it neither needs nor switches off.

Usage

The login form gains a GLUE Login button. An admin user is created on first sign-in when a domain rule names a role, and signed in.

A user whose email domain has a rule signs in this way rather than with a password. Accounts created by sign-on have no usable password, so giving one out means an administrator setting it.