Our organization has a Mattermost instance with >200 users which is our central service. That's the first (and sometimes the only) service that our members user, so it's the most natural choice for SSO identity provider.

Mattermost's current OAuth 2.0 implementation (https://developers.mattermost.com/integrate/apps/authentication/oauth2/) is NOT adequate as an identity provider, because the Userinfo endpoint is NOT an OpenID Connect compliant ID Token (https://openid.net/specs/openid-connect-core-1_0.html#IDToken) -- it's not a JWT, and doesn't provide a stable user identifier ('sub' claim).

Currently it's possible to integrate Mattermost OAuth 2.0 with some Service provides using some ad-hoc configuration (SP can be configured to pick certain JSON field from the Userinfo as the identifier). But if SP takes the Mattermost "username", then this is a *security vulnerability* because Mattermost allows users to change their username, so users can arbitrarily impersonate anyone else once redirected to the SP. So if the username is taken as the stable user identifier, then Mattermost must provide an option to *disallow* changing usernames.