Currently our application works as an OAuth provider, this is the behaviour we expect related to chat integration into our platform:
The user sign-in in our platform by first time using his credentials.
The user then log-in in chat using our OAuth service, chat system should automatically procede to create a new user inside chat DB without requesting credentials or any form fill, instead it should use the data provided by our custom OAuth procedure.
Any time this user sign-in in our platform in the future, the chat app should automatically sign-in as well.
My question is: does Mattermost has a single sign-on (SSO) method based on custom oAuth that allow us to perform a procedure as described above?.
If not, are you planning to implement that?, if true, will you make this available only for the comercial version?
This feature idea is under review right now. Could you share more about your use case? Who are the users (employees, customers, both?) and about how many are there? Would you have a link to your platform if it’s public?
I’m in need of a similar feature. We already have our our user DB and user authentication. We would love to integrate with Mattermost for a single-sign-on solution. We could implement an Oauth setup (or something similar) on our side and then have Mattermost authenticate against our users db. Currently we’ve built a workaround with the web-service APIs and cookie tricks, but it’s obviously not the best way to do it. We would love the ability to do a standardized integration for people with existing user databases instead.
@Nick can you elaborate on the workaround you’ve built?
Sure. It’s by no means a proper way to do authentication, but was the only way we found to get it to work without a proper Oauth API. Essentially we have to manage users in our system and the MM system separately. First, you need an API token from an authorized user. The flow basically works like this:
- User registers on our platform (proprietary login)
- On registration, we hit the Mattermost API to create a user/password, then we store this encrypted in our DB. This API isn’t documented, but you can sniff all the calls in a network console pretty easily.
- On login, we use the stored/encrypted credentials to hit the MM API to log the user in and get an auth token.
- Set the MMTOKEN cookie to that auth token. Since MM uses the cookie for auth, the user is now logged in.
Since we used different domains, we had to set the cookie to the base domain path so it would be accessible to write from our app and then accessible on the subdomain for MM. I recommend SSL and encryption across the board since user/passwords are being send across the wire. Also, there is the pain of keeping passwords in sync across your platform and MM you need to account for.
Hope that helps!