Add Sign in with M7 to a website-managed login

The OIDC-Connect PHP example is the supported integration pattern for an independent website that wants to place Sign in with M7 beside its own GitHub, Discord, or other provider buttons. It uses the M7 Identity SDK Web/PHP backend-for-frontend (BFF) for the M7 branch while the website remains the identity broker for its own application.

This page is the public purpose guide for the example. Continue with the sanitized personal OAuth application registration card and the sanitized Apache SetEnv deployment template.

Choose the broker model

In the website-managed model, the website presents and operates each provider:

Website
├── Sign in with M7
├── Sign in with GitHub
└── Sign in with another provider

M7 authenticates the M7 branch and returns a verified OpenID Connect identity. The stable external identity key is the pair of the verified issuer (iss) and subject (sub). The website owns:

local accounts and application sessions;
application authorization and access policy;
provider-to-account mappings;
explicit account-linking decisions;
duplicate and collision handling; and
account recovery.

Do not use an email address alone as the provider identity key, and do not link accounts merely because two providers return the same email address.

The alternative is to use M7 as the website's sole identity broker:

Website
└── Sign in with M7
    ├── M7 account
    ├── GitHub
    └── Discord

In that model the website integrates with one M7 identity. M7 owns the upstream M7, GitHub, and Discord sign-in methods and returns one stable M7 issuer-and-subject identity. Choose this model when the website should not own multiple provider integrations or their account-linking policy.

What the PHP example supplies

The source example provides the M7 branch of the website-managed model:

a reusable Sign in with M7 button and page;
a same-origin Web/PHP BFF installation;
Authorization Code flow with PKCE and pushed authorization requests (PAR);
server-side code exchange, DPoP handling, token acknowledgement, refresh, UserInfo/profile access, and logout; and
browser calls to the BFF's same-origin session and profile routes.

The example does not create the website's user table, session model, authorization rules, provider registry, linking workflow, collision policy, or recovery process. Integrate the verified M7 issuer-and-subject result into those website-owned systems.

Deliberate nested installation

Install the example and its SDK bridge together below /oidc-connect/:

<DOCUMENT_ROOT>/
└── oidc-connect/
    ├── index.php
    ├── assets/
    └── m7_sso_session/
        ├── login.php
        ├── callback.php
        └── ...

The registered routes therefore use this exact layout:

login:         <HTTPS_ORIGIN>/oidc-connect/m7_sso_session/login
callback:      <HTTPS_ORIGIN>/oidc-connect/m7_sso_session/callback
post-logout:   <HTTPS_ORIGIN>/oidc-connect/

The nesting is intentional. It gives the example an independent /oidc-connect/m7_sso_session/ installation and callback without changing an M7 session bridge that may already exist at the website root.

Release status

The example is a supported reference pattern coordinated with the stable SDK release. It is not included in the immutable web-php 0.1.3 archive and is not a separately versioned package. Install the checksum-verified Web/PHP package for the m7_sso_session BFF. See the website installation guide for the current package and integrity-verification status.

The example's networked sign-in flow requires HTTPS, a deployment-specific M7 registration, and server-only secret configuration. Its repository smoke check is network-free and verifies the page contract, nested routes, sanitized configuration, and documentation links; it does not prove a live registration.