Mattermost

Native Authelia SSO

Properties1
descriptionMattermost native OpenID retained under D-190 amendment 2, real-message persistence, and final same-user native re-entry/readback proven; source published.

11 min read

Native Authelia SSO

Runtime rechecked read-only on 2026-09-28 for D-190 amendment 2. Mattermost retains its supported OpenID Connect (Other) integration with Authelia. The existing non-trial Entry license enables OpenID; no licensing bypass, session bridge, password injection, or system-administrator grant was used. The 2026-09-27 identity/logout evidence below remains historical. The parent’s 2026-09-28 real-message and full-reload proof used a retained native application session. After the final additional IdP event on 2026-09-29 at WCHT, separate final Mattermost native re-entry/readback proved the same ordinary user and existing message.

Amendment 2 status

Mattermost is again in the priority scope alongside Fluxer, Lobe, chat.loca.zone, and WCHT, followed by rckt and team. Only Code/Coder and Open Notebook remain excluded/shared by design. The intervening Mattermost application rollback was staged but never activated; its historical activation instructions are superseded and must not be run. The native application files, container, client registration, and entry redirects remain active.

The forward wiki sources and original screenshots have been restored from protected withdrawals. This final Most source update retains the parent’s real-message/reload proof and adds the dated batch-3 receipt, final IdP event, and final Mattermost native re-entry/readback. The earlier source-freeze and preliminary digest receipts remain history and no longer describe these edited sources. These four forward pages and the new exact-copy screenshot have been published using the unchanged publisher workflow. Most acceptance is supported, while the overall mission remains BLOCKED / partial success: Chat lacks a supported integration, Rocket needs genuine administrator bootstrap, and Team needs a genuine owner’s invitation. Those blockers are not missing Most proofs.

The parent proved one real test message and persistence as the already-existing native pxl, using its retained Mattermost session without a new IdP submission for that proof. The original shared IdP session was observed no longer active when the first-factor form appeared at 04:33 UTC on 2026-09-28, before this message proof; no new submission occurred then and the cause was not established. A native app session can persist independently. The original first-factor event at 2026-09-27T21:15:36Z remains separate history: the record now contains one original submission plus one authorized final additional submission, not one login across the whole mission. Final Mattermost native re-entry/readback is now separately proven, with no additional password and no duplicate message. No system-admin grant, temporary user, password reset, Authelia user write, or custom identity bridge is authorized. The historical zero-team screenshots prove identity/onboarding only.

The dated auth-batch/batch-3/gatekeeper-receipt.json records APPLIED: Authelia restart issued at 2026-09-28T22:57:32Z, healthy at 22:57:35Z, and nginx reloaded at 22:57:41Z. Batch 3 records one auth restart and one nginx reload; the original batch’s one auth restart/two nginx reloads and the separate D-193 foreign zero auth restarts/one nginx reload are not batch-3 counts. Mattermost was retained. No Gatekeeper password was submitted. This is a dated application receipt, not verification of current live Authelia configuration parity. Main reports that the live configuration delta includes foreign exdr/collab rules, not merely template drift; parent reconciliation is separate from the proven Most native acceptance.

The parent’s browser/final-login.json records the actual authorized final additional pxl first-factor submission at 2026-09-29T07:19:22.199Z, HTTP 200, submissions: 1, and remember_me_checked: false. It landed at wcht.loca.zone /; WCHT’s native identity returned HTTP 200 for pxl. The genuine parent browser/final-login.png accompanies that event. That record alone proves the final IdP event after batch 3, not a Mattermost session; the separate final native proof below closes the Most acceptance gap.

Installed configuration

ItemVerified value
Mattermost version11.7.0
Imagemattermost/mattermost-enterprise-edition:11.7.0@sha256:b2e8b158deb693f0dbc00282e987631eef89b0ca580e59260a5edc4864cbe881
Build commita9e574a82633915f22071f0d7ca2b006f249ec2a
Native methodOpenID Connect (Other)
Issuerhttps://auth.loca.zone
Discoveryhttps://auth.loca.zone/.well-known/openid-configuration
Client IDmost
Callbackhttps://most.loca.zone/signup/openid/complete
FlowAuthorization code; confidential client using client_secret_post
Scopesopenid profile email; no groups scope
PKCENot sent by this native client; not required for this confidential client registration
ConsentImplicit, with the client’s one-factor authorization policy
Username settingUsePreferredUsername=true
Credential referenceProtected deployment environment key MM_OPENIDSETTINGS_SECRET; no value is published

The application remains on the same installed image, pinned by repository digest. The original forward change recreated only the Mattermost service; the database service and unrelated containers were not restarted. The 2026-09-28 check found that exact container still running, with the same application-file hashes as the staged-only reversal receipt. Effective native settings remain enabled for client most, and the effective secret matches its protected runtime environment.

Entry, identities, and preservation

Opening the site root without an app session initiates Mattermost’s own /oauth/openid/login route. Ordinary /login also enters the native flow. API, websocket, and native callback paths remain direct application routes: there is no proxy identity injection or blanket browser-auth gate over APIs.

Local password login remains available for existing local accounts. The existing email and username sign-in options were preserved.

The native preferred-username setting controls the visible username. Mattermost’s native provider account identity drives account lookup and provisioning; there is no custom per-user mapping. The public shared OAuth code looks up provider-derived authentication data plus service and creates a user if absent. The generic OpenID claims converter is an enterprise dependency, so its exact internal subject conversion is not represented here as publicly inspected source.

  • At the 2026-09-27 baseline, pxl had no pre-existing Mattermost username/email match. The first native flow provisioned the account. Amendment 2 reuses that existing account; it does not authorize another provisioning operation.
  • On 2026-09-28, the same account remained pxl, email pxl@loca.zone, authentication service openid, and role system_user. All four original accounts retained their IDs, usernames, emails, roles, authentication fields, creation times, and deletion states.
  • At 04:36 UTC on 2026-09-28, a read-only inventory found zero teams, zero pxl team/channel memberships, and zero pxl posts. This is a dated pre-message baseline, not a permanent zero-team claim.
  • Future users use the same enabled native provisioning path; no individual account configuration or group-to-admin mapping was added.
  • Existing local accounts with a matching email are not silently merged. Mattermost’s supported account-transfer flow requires the existing account’s authentication; direct user-database edits are not a substitute.

Historical loca limitation

The enabled Authelia identity loca used the same generic preferred-username/email configuration. No existing Mattermost account matched loca or its email at the original baseline, so existing-account linkage and its first live login were not established. That historical limitation is preserved rather than relabelled “config-proven”; amendment 2 targets the already-existing pxl identity, not a new loca proof.

Ordinary-user message proof — retained session, 2026-09-28

The installed build and current database-backed permissions support an ordinary pxl creating an isolated test team and private channel, then posting. system_user has create_team; team_user has create_private_channel; channel_user has create_post. The instance has no creation-domain restriction, requires no extra email verification, and already records pxl as email-verified. The existing non-Cloud Entry license does not invoke the Cloud team-count restriction.

The parent exercised the supported native browser flow with the existing pxl session. Exact evidence timestamps are UTC:

ObservationRecorded result
Team creation — 22:14:16.515Native /api/v4/teams returned HTTP 201: display name D190 SSO Test, ID u1hm1obw7fnu9k3nsmcoymfz1w, actual slug d190-sso-ted190-ssosync-aedc8b8ast, type O, allow_open_invite=false
Access readback — 22:16:20.602Team settings → Access showed “Allow any user with an account on this server to join this team” unchecked
Private-channel creation — 22:17:21.059Native /api/v4/channels returned HTTP 201: ssosync-test, ID oq1dd6ow43n1bjhyx749sp1jao, type P, team ID u1hm1obw7fnu9k3nsmcoymfz1w, creator sm9fczhfbty97m677mmhh18bnh
One real post — 22:17:57.554Native /api/v4/posts returned HTTP 201: ID jgrwwfssup8y8p9em8k4gayk3r, author sm9fczhfbty97m677mmhh18bnh, channel oq1dd6ow43n1bjhyx749sp1jao, normal post type (empty string)
Visible message — 22:18:17.939Native UI showed pxl and the exact message below in the private channel
Full reload/readback — 22:18:57.679Native user, post, channel, and team GETs each returned HTTP 200; the same post ID, exact text, author, channel, and team persisted; account remained pxl / system_user / openid; team still had allow_open_invite=false

Exact message text:

D190-SSOSYNC-aedc8b8a: pxl native Authelia SSO test message.

The actual team slug is intentionally recorded verbatim: typing selection did not replace the entire prior slug. No desired-slug substitution or rename is claimed. The observed path is /d190-sso-ted190-ssosync-aedc8b8ast/channels/ssosync-test. No users were invited or invitation links shared. Native type O with allow_open_invite=false is the invite-only/unlisted configuration, not a fabricated type-I flow.

Native creation automatically assigns the creator team-scoped team_admin/team_user and channel-scoped channel_admin/channel_user memberships. This is inherent creator ownership, not a separate administrator-issued grant or a change to the account’s global system_user role, which the reload readback confirms remains unchanged. Team creation also created the normal Town Square and Off-Topic channels; the real message is in the new private test channel. This isolates the test from unrelated ordinary users, not from system administrators.

Proof records are browser/most-test-team.json, browser/most-test-team-access.json, browser/most-test-message.json, and browser/most-message-persistence.json in the D-190 aedc8b8a evidence set. The screenshots below are exact copies of the supplied sanitized message/reload PNGs, not replacements for the historical images. Their matching SHA-256 digests are recorded in the separate preliminary source/asset receipt. The screenshot UI displays September 29 in its local timezone; the evidence timestamps above are September 28 UTC.

Native pxl real message in the private ssosync-test channel, captured 2026-09-28 UTC

The same native pxl message visible after full reload, captured 2026-09-28 UTC

This dated evidence proves retained-session real-message persistence. The separate final native re-entry/readback below proves that the same existing post survived the final shared-login flow. No team, channel, message, login, or application mutation was performed by this documentation worker.

Final native re-entry and existing-message readback — 2026-09-29

After the final shared IdP login, the parent opened Mattermost’s root and its native flow automatically returned the same ordinary pxl, without another password. browser/most-final-session-readback.json records 07:23:02.613 UTC, native user HTTP 200, user ID sm9fczhfbty97m677mmhh18bnh, username pxl, email pxl@loca.zone, global role system_user, and authentication service openid. The existing post GET also returned HTTP 200: jgrwwfssup8y8p9em8k4gayk3r, author sm9fczhfbty97m677mmhh18bnh, channel oq1dd6ow43n1bjhyx749sp1jao, and the exact original message text above. No resend was performed.

The JSON records the landing path /d190-sso-ted190-ssosync-aedc8b8ast/channels/town-square; the accompanying genuine screenshot shows the existing message in the private ssosync-test channel. These are distinct observations, not a claim that Town Square contains the test post. The image below is an exact copy of browser/most-final-session-readback.png; all prior screenshots are preserved.

Final native Mattermost session showing the existing pxl test message, 2026-09-29

final-oidc-issuance-redemption.json records, since 2026-09-29 07:19 UTC, exactly one issued code and one matching access-token row for each of flxr, lobe, most, and team. Most’s last access-token request is 2026-09-29 07:22:45.947405325+00:00. This correlates native issuance/redemption; it does not by itself prove another app’s acceptance or remove Team’s owner-invitation blocker.

browser/final-target-recovery.json, recorded at 07:25:20.169 UTC, describes the old owned browser carrier returning a detached frame and closed connection; its recovery attempt failed before creating a page. The cause is unknown, not proven idle expiry or browser crash. The parent used a fresh isolated successor target for the final evidence and did not touch the original shared browser target. This browser recovery record is not a second final login event.

Historical shared-session browser proof — 2026-09-27

In the shared Chrome 142 session on 2026-09-27, after the Authelia login, opening the Mattermost root required zero additional application-login clicks and zero additional password submissions.

ObservationResult
Native callback flowClient most, expected callback and scopes, no PKCE challenge
Native current-user APIHTTP 200; username pxl; email pxl@loca.zone; authentication service openid; role system_user
Authenticated rootApplication response followed by /select_team; no OAuth redirect loop
Anonymous APIHTTP 401 JSON, not an Authelia HTML redirect
Spoofed identity headers or fake session credentialNative current-user API still returned HTTP 401

At that dated zero-team observation, onboarding did not expose the ordinary profile menu or username. Source confirms that an ordinary authenticated user with no active teams is directed to /select_team; Profile is an account-menu modal, not a standalone teamless profile URL. The preserved evidence pairs the real onboarding UI with the application’s own current-user JSON. No team was created and no message was sent in that historical proof.

Mattermost native signed-in zero-team onboarding

Native Mattermost current-user response showing pxl, openid authentication, and system_user

The account-response image is the browser’s native JSON view. Open it at full size.

Historical logout and re-entry — 2026-09-27

At 21:24:16 UTC, the native POST /api/v4/users/logout request, with the application’s native CSRF handling, returned HTTP 200. The subsequent current-user request returned HTTP 401, proving revocation of that Mattermost session. The explicit local-login escape then displayed the native password form and Authelia button.

At 21:24:42 UTC, opening the root again returned a native pxl session with system_user and the same zero-team landing page, without another password submission. Mattermost logout and Authelia logout are separate: the still-active IdP session allowed transparent re-entry. Single logout was not configured.

The accepted logout evidence is the direct native endpoint plus the following HTTP 401. Earlier automated UI-logout waits timed out without retaining request status, so they are not claimed as proof of the UI-click path.

Backups and rollback boundary

Protected pre-change backups include the environment, Compose base and selected overlay, application configuration, and a PostgreSQL custom-format dump. The runtime backup directory is mode 0700 and its files are mode 0600; credential values and operator-only paths are not published. Documentation also has a pre-edit backup.

The amendment-1 configuration rollback was staged only and is superseded by amendment 2. Do not restore its pre-change environment or Compose configuration, disable the provider, or recreate the application for that obsolete plan. Retain all historical reversal evidence separately from current instructions.

If a future rollback is explicitly authorized, it must be coordinated with the shared authentication owner. Never restore the old database for an ordinary configuration rollback: that would remove accounts and data created after the backup. Disabling the provider leaves stored native accounts intact but prevents that provider login until re-enabled.

Sources

Graph View

Backlinks