Please. The need for authentication from external system (JomSocial on Joomla in my case) is what is keeping us from switching to Mattermost.

Being a nonprofit small website there is no way we can pay for the other editions.

Actually we would prefer a direct integration with Keycloak / OIDC, not just OAuth2.

It seems that two other requests that would be covered by having this feature - Microsoft ADFS [1] and Phabricator OAuth2 [2]

A PR was been submitted [3] and concerns of maintainability and testing [4] were raised. As the existing gitlab code can be removed in favour of the generic OAuth2, the maintenance and testing should be comparative if not identical.

The community can also help with the testing, if the MM team can tell us of the procedure and reporting they'd like to see.

It seems perfectly reasonable, right?

[1] https://mattermost.uservoice.com/forums/306457-general/suggestions/13397460-sso-with-microsoft-adfs
[2] https://mattermost.uservoice.com/forums/306457-general/suggestions/18550690-add-phabricator-oauth2-support
[3] https://github.com/mattermost/mattermost-server/pull/1938
[4] https://github.com/mattermost/mattermost-server/pull/1938#issuecomment-284324572

First of all - google, than jira, than generic oauth.

2. For the most popular Oauth setup used in companies (Google).
Must have!

Hello friends,

I'd like to add another use-case to this. I admin emlondon.ca, which is used by physicians, learners (residents, medical students) and other staff to keep up-to-date, etc.

While we have found that Drupal is an amazing CMS (replacing our previous joomla), we have added Discourse and Moodle for forums and LMS respectively. There is no visual integration - they are very much their own thing, but it is essential for us that people don't have to remember yet another login. We accomplish this with OAuth2, though we've looked at LDAP as well.

From the administrative point of view, OAuth2 is significantly easier to manage than LDAP (we use a drupal provider). Currently, mattermost is deployed, but used in a very, very limited way, since it's not reasonable to ask most users to take on an additional login/password.

I propose looking at Discourse for a sane way to approach this. One way would be to allow local login (for invitees, say) and to also offer login / authentication via OAuth2. This way, people can authenticate using either a local or remote login pathway.

It's obvious that we all have login fatigue, which is why I think this issue will continue to gain votes - up to 99 at the time of writing. This is the current model of login management, and I think MM will get stuck in terms of growth without it.

I use Django's allauth module to authenticate my users. https://github.com/pennersr/django-allauth

This allows them to link various accounts - Facebook, Google, Github, StackExchange, Shopify and SoundCloud are the ones I use. Giving users this ability to connect from various points is helpful because they can connect how they want. From an admin point of view, it takes a little bit of work for initial set up, but once done has been pretty painless.

Hello everyone!

This feature keeps gaining votes, at 47 now.

It would be a good idea to separate this suggestion into 2 different topics:
1. For generic oauth.
2. For the most popular Oauth setup used in companies (Google).

And work first on #2 which may be faster and help on getting to #1.

I'm a developer at a small software company, and Mattermost is one chat server under consideration for internal use.

Thanks Neil, highly appreciate the feedback. There's been a fair amount of internal discussion around this.

Your help sharing more details would extremely helpful. About how many users are you aiming to serve? Are you hosting for internal use, or opening this to clients/customers, etc.? May I ask which industry you're in?

I've been playing around with an OAuth implementation with Flask-OAuthlib using their demo documentation and I was able to authenticate to Mattermost using it - so I'm curious as to the hesitation to support further OAuth implementations since the support seems to be there already. The support tools, particularly MatterIRCd, not yet supporting OAuth and pointing to this as the reason, may actually hinder my uptake of Mattermost, and happens to be a concern for use of Mattermost amongst my colleagues.

I guess what I'm trying to say is, I think that supporting this will actually make Mattermost a more robust product, and encourage more uptake among those who want to use SSO to avoid creating more passwords and to leverage things like 2FA. Furthermore, I think that this would avoid a demand for Mattermost to support 2FA and OTP, as such support could be relegated to OAuth SSOs. Just my 2 cents.

Thanks for your response - I think I understand your concerns a little better now. I also agree that the user experience with oauth based SSO is tricky to get right so that it feels natural and easy. This also includes the administrative side of the user interface.

That said, I think it's possible to improve the automated test coverage of the SSO code paths - potentially to an extend that you can reduce the manual work quite a bit. Once/If I get the CLA signed from my employer then I'll see if I can contribute changes that demonstrate what I have in mind. But that doesn't help much with this particular item and our use-case:

I consider proposing the use of mattermost to a wider audience of contributors in the Qt project (qt-project.org). There are a couple of things on the way, but from a technical perspective the biggest hurdle right now is that we'd use OAuth based SSO. Every contributor in the Qt project has a so-called Qt Account and we have an oauth provider set up for that.

From an administrative side this is a matter of setting up mattermost and adding the oauth urls for the qt account into the system console settings (that the aforementioned github pull-request adds). After that it works and we're evaluating it at the moment.

In the long run I think that the ability to use external identity and authentication providers is crucial for large scale deployments of web applications. With projects like rocket chat this is already possible, hence my interested in seeing this generalization also in mattermost.

I really think that back-end wise this is a pretty straight-forward piece of work. From the perspective of the end-users the work flow is always the same, as mandated by oauth itself. What remains is the aspect of testing, how the administrator conveniently and forgivingly configures the SSO (I do like your design principles :) and lastly a step of verification against the external service ("does the userinfo api return all the correct values needed").

Thanks Simon, definitely appreciate your offer to help. While the question of direction involves the code, internally we also consider design and support.

Regarding (1) and (2) GitLab SSO is a single provider that's manually tested and verifed in each monthly release of Mattermost, and it's repeatedly a consideration in other features we build.

As a product, we're focused on the design principle of "fast, obvious, forgiving" (http://www.mattermost.org/design-principles/) and that sets a quality requirement on SSO.

A specific provider means we're able to test, document, verify, support, repro and help troubleshoot specific issues. A generic provider is significantly more expensive to support, and there's potential to expose Mattermost users to security issues in 3rd party OAuth implementations, especially if email validation isn't done correctly.

There's a corner case where the interface for the specific provider happens to be compatible with other providers, such as GitHub and GitHub Enterprise OAuth.

In this case, there's "unofficial" documentation for variations--for example, if you use GitHub SSO each user needs to make sure their email address is set to "public" whereas that's not a requirement in GitHub Enterprise--and these variations are documented, e.g. see Step 7 here: http://docs.mattermost.com/deployment/sso-gitlab.html#github-unofficial

Could you help share more about your use case? Curious what other approaches could be considered.

Would also welcome use case feedback from others who upvoted this feature,

Could you elaborate how (1) and (2) stand in the light of gitlab support? If you intend to support gitlab SSO in the apps, then you'll end up with pretty generic code in the ios/android apps anyway, won't you?

As far as I can see gitlab acts as oauth provider. As the pull request demonstrates, it's fairly easy to generalize the back-end code in mattermost to be provider agnostic. There is work to be done to simplify this on the front-end while maintaining the sso service branding, but that doesn't seem to be an insurmountable task :)

Just to clarify: I'm willing to put in time to work on this and contribute it. We just need to agree on the direction :). I see an opportunity to clean up code in MM most and I'm happy to contribute golang tests for the code.

Moving discussions on generic OAuth from different places to this feature idea forum post

Matterircd: https://github.com/42wim/matterircd/issues/29#issuecomment-176479267

Mattermost platform:
https://github.com/mattermost/platform/pull/1938#issuecomment-176077706

Forum:
https://forum.mattermost.org/t/mattermost-oauth/588

Mattermost core team discussed this at length and, right now, we're not ready to make a commitment to generic OAuth SSO.

Our thinking is that:

1) After its implementation, the core team would need to divert energy to test, document, support and troubleshoot generic OAuth means cutting other features.

2) Applications for Mattermost (e.g. native iOS and Android apps, connectors to XMPP, Matrix, IRC, etc.) may feel burdened to build support OAuth which could mean cutting their own planned features or even being discouraged to build in the first place.

This said, we're not experts on OAuth, and other applications do support it. We wanted to post here to get feedback from the community--and encourage upvotes from teams who would prioritize this over other features.