Use MM as oauth2 provider for GitLab


I am trying to use MM as an oauth2 provider for gitlab to authenticate against.

Here is my setup so far:

gitlab_rails['omniauth_providers'] = [
     "name" => "oauth2_generic",
     "app_id" => "xxx",
     "app_secret" => "xxx",
     "args" => {
       client_options: {
          'site' => '',
          'user_info_url' => '/api/v4/users/me'
       user_response_structure: {
        root_path: [],
        attributes: { nickname: 'username' }
       name: 'Mattermost',
       strategy_class: "OmniAuth::Strategies::OAuth2Generic"
}   }

When I try to login through Mattermost I see the following message on GitLab:
Could not authenticate you from Mattermost because “”.

The docker logs of the MM web container say the following; - - [10/Mar/2018:13:48:00 +0100] “GET /oauth/authorize?client_id=xxx& HTTP/1.1” 302 191 “” “Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/64.0.3282.186 Safari/537.36” “” - - [10/Mar/2018:13:48:00 +0100] “POST /oauth/token HTTP/1.1” 405 0 “-” “Faraday v0.12.2” “”

Any help with this would be highly appreciated.

I only found topics on here who tried to do it the other way arround (having gitlab as the oauth2 provider)


It looks like you’re off to a great start! I had hoped to replicate your setup and assist with testing, but it looks like I have to custom compile Gitlab to even get the gem installed. If you have any suggestions on ways to bootstrap that process I’d be happy to help further!

At this point, I’d be curious to see if the call to /api/v4/users/me gets invoked without error. It might also be useful to intercept the network requests using your browser’s developer console and examine the payload for further clues.


I’ve set it up in a docker environment. Using:

I’ll try the browser tools this evening (GMT). From what I see in the logs it failed when trying to retrieve the oauth token (405 error) … so it doesn’t even get thus far as to get the user info via API.


What exactly are we looking for? I really would love to get this off the ground and add other applications to this setup. :slight_smile:


In that console tab, can you consecutively click on the top four network requests and post the Form Data from the bottom of the Headers tab, and the entire contents of the Response tab? (Shouldn’t be anything to redact from that text, but may want to just peruse before posting publicly.)


Here are the requested screens: (can only post one image per post)

I’ve now deauthorized the app, just that the oauth tokens posted here can’t be reused.
Kind of strange that the response tab is always empty.









Good news is that I’ve been able to reproduce the problem you’re observing above. Bad news is that it’s still unclear why this doesn’t work. To document, here’s my changes to /etc/gitlab/gitlab.rb in the GitLab Ominbus image based on your changes above:

gitlab_rails['omniauth_enabled'] = true
gitlab_rails['omniauth_allow_single_sign_on'] = ['oauth2_generic']
gitlab_rails['omniauth_block_auto_created_users'] = false
gitlab_rails['omniauth_auto_link_saml_user'] = true

gitlab_rails['omniauth_providers'] = [
    'name' => 'oauth2_generic',
    'app_id' => '<app_id>',
    'app_secret' => '<app_secret>',
    'args' => {
      client_options: {
        'site' => 'http://<mattermost_host>:8065/', # including port if necessary
        'user_info_url' => '/api/v4/users/me'
      user_response_structure: {
        root_path: [], # i.e. if attributes are returned in JsonAPI format (in a 'user' node nested under a 'data' node)
        attributes: { nickname: 'username' } # if the nickname attribute of a user is called 'username'
      # optionally, you can add the following two lines to "white label" the display name
      # of this strategy (appears in urls and Gitlab login buttons)
      # If you do this, you must also replace oauth2_generic, everywhere it appears above, with the new name.
      name: 'Mattermost', # display name for this strategy
      strategy_class: "OmniAuth::Strategies::OAuth2Generic" # Devise-specific config option Gitlab uses to find renamed strategy

and the configuration of the OAuth2 application in Mattermost:

Is Trusted: No
Client ID: <client_id>
Client Secret: ***************
Callback URLs: http://<gitlab_host>/users/auth/Mattermost/callback
Created by test on Wednesday, March 21, 2018

Here are the Gitlab logs associated with an attempt to authorize:

==> /var/log/gitlab/gitlab-rails/production.log <==
Started POST "/users/auth/Mattermost" for at 2018-03-21 12:44:57 +0000
Processing by Gitlab::RequestForgeryProtection::Controller#index as HTML
  Parameters: {"authenticity_token"=>"[FILTERED]"}
Completed 200 OK in 1ms (ActiveRecord: 0.0ms)

==> /var/log/gitlab/gitlab-rails/production_json.log <==

==> /var/log/gitlab/gitlab-rails/production.log <==
Started GET "/users/auth/Mattermost/callback?code=[FILTERED]&state=3e78b546e6874487c18207845bc68158e6fbcff86085b49f" for at 2018-03-21 12:44:57 +0000
Processing by OmniauthCallbacksController#failure as HTML
  Parameters: {"code"=>"[FILTERED]", "state"=>"3e78b546e6874487c18207845bc68158e6fbcff86085b49f"}
Redirected to http://localhost:9090/users/sign_in
Completed 302 Found in 5ms (ActiveRecord: 0.0ms)

==> /var/log/gitlab/unicorn/unicorn_stdout.log <==
I, [2018-03-21T12:47:29.527107 #841]  INFO -- omniauth: (Mattermost) Callback phase initiated.
E, [2018-03-21T12:47:29.532019 #841] ERROR -- omniauth: (Mattermost) Authentication failure! invalid_credentials: OAuth2::Error,

==> /var/log/gitlab/gitlab-rails/production_json.log <==

I do note that Gitlab never reaches out to Mattermost on the user_info_url but decides that the authentication failed from the sole interaction against /oauth/authorize. Nothing in the response from Mattermost suggests the authentication failed, so I’m guessing GitLab is expecting something that Mattermost isn’t sending.

I might suggest reaching out to GitLab at this point for assistance, though there’s a few more things I’d like to try myself as well.