...

1. Support OpenId Connect standard for Authentication

2. Support Discovery Document

3. Support retrieving user fields currently supported in OAuth2 implementations

   1. Either from IdToken or additional userinfo_endpoint call

   2. Email, First Name, Last Name, Username (from Email), Nickname, AuthData

4. Ensure OpenId Connect works with existing OAuth providers. (Office365, Google, GitLab)

5. Migrate Existing OAuth2.0 providers to OpenId Connect

SCOPE

In:

• OpenId Connect Authentication Provider

• System Console Setup for OpenId Connect Provider

• Support of OpenId Connect in Mobile/Desktop/WebApp

Out:

• Google Support on Mobile

• Multiple Provider Support

• Plugin Interactivity

...

• Account Settings

  • Restrict user from setting

    • Username

    • Email

    • Similar to other OAuth providers

• Logging In

  • WebApp -

    • login_controller.jsx

    • Add OpenIdConnect section

      • Is user restricted to OpenId Connect or OAuth?

      • Currently OAuth limited to one being turned on at a time.

      • I don’t think it is a technical limitation.

  • Mobile

    • loginOptions.js

    • Add OpenIdConnect Option

    • Google OAuth not supported on mobile,

      • Need to understand why

      • Will this affect OpenIdConnect?

    • Update to login flow

Mobile Migration -
w/ old server

• New OpenId won’t be available as server won’t support.

• Existing OAuth Connections will continue to work as is.

w/ new server

• New OpenId will be available if configured and enabled on the server.

• Existing OAuth Connections will continue to work as is.

  • Same endpoints, change is on server side.

Old app w/ new server

• New OpenId will not be available

  • If that is users login method, they would not be able to login.

• Existing OAuth Connections will continue to work as is.

Migration

Once an OAuth System has been migrated to OIDC, we need to understand the impact on existing users. Users will remain logged in as long as their session is valid. Once their session expires, the users will go through the new login process. They will be asked to login in their provider (or not, if already logged into their provider). Whether or not the users are asked to reauthorize usage depends on each Provider.

Each of these was tested as follows -

• Remove Authorized Application from Provider

• Login using current OAuth Settings

• Change Configuration to use OpenId Connect for same provider, same application

• Login using OpenId Connect Scopes [OpenId, Email, Profile]

Google

Google already uses OpenId Connect as the login mechanism for OAuth. The user does not have to authorize any additional access.

GitLab

GitLab controls the user’s allowed scopes in the GitLab Application. The admin will need to add or verify users have access to [email profile openid] scopes in the Mattermost application on GitLab. Once that is done when the user logs in, the user will be asked to authorize access to the new scopes.

Office365

Office’s User.Read permission allow MM to “Read your profile”. That single permission is enough to allow the profile, email, openid scopes to operate successfully. If the application is deleted and recreated the “View your basic profile” and “View your email address” permissions request access.

Performance

The retrieval of the Discovery Document should only happen once and then be cached.

...