Yandex Cloud
Search
Discuss with expertTry it for free
  • Customer Stories
  • Documentation
  • Blog
  • All Services
  • System Status
  • Marketplace
    • Featured
    • Infrastructure & Network
    • Data Platform
    • AI for business
    • Security
    • DevOps tools
    • Serverless
    • Monitoring & Resources
  • All Solutions
    • By industry
    • By use case
    • Economics and Pricing
    • Security
    • Technical Support
    • Start testing with double trial credits
    • Cloud credits to scale your IT product
    • Gateway to Russia
    • Cloud for Startups
    • Center for Technologies and Society
    • Yandex Cloud Partner program
    • Price calculator
    • Pricing plans
  • Customer Stories
  • Documentation
  • Blog
© 2026 Direct Cursus Technology L.L.C.
Yandex Managed Service for GitLab
  • Getting started
    • All guides
    • Getting instance info
    • Creating and activating an instance
    • Setting up security groups and access restrictions for an instance
    • Stopping and starting an instance
    • Updating instance settings
    • Managing backups
    • Migrating from a custom GitLab installation
    • Migrating to a different availability zone
    • Cleaning up full disk space
    • Deleting an instance
    • Creating and adding users to a project
    • Setting up approval rules
    • Instance state monitoring
    • Setting up OmniAuth
    • Integration with Object Storage
    • Working with a managed runner
  • Access management
  • Pricing policy
  • Terraform reference
  • Monitoring metrics
  • Audit Trails events
  • Release notes
  • FAQ

In this article:

  • Adding an authentication provider
  • Authentication provider settings
  • Bitbucket Cloud
  • Github Enterprise
  • GitLab self-managed
  • Google OAuth 2.0
  • Keycloak
  • LDAP
  • Microsoft Entra ID
  • Microsoft Azure OAuth 2
  • SAML
  • Yandex ID
  • Yandex 360
  1. Step-by-step guides
  2. Setting up OmniAuth

Setting up OmniAuth

Written by
Yandex Cloud
Updated at May 6, 2026
  • Adding an authentication provider
  • Authentication provider settings
    • Bitbucket Cloud
    • Github Enterprise
    • GitLab self-managed
    • Google OAuth 2.0
    • Keycloak
    • LDAP
    • Microsoft Entra ID
    • Microsoft Azure OAuth 2
    • SAML
    • Yandex ID
    • Yandex 360

With OmniAuth, users can sign in to GitLab using credentials from other services.

To integrate an authentication provider for GitLab via OmniAuth, add your provider and specify its settings.

Adding an authentication providerAdding an authentication provider

  1. Go to Managed Service for GitLab.
  2. Click the instance name and select the OmniAuth tab.
  3. Click Configure.
  4. To add an authentication provider, click Add.
  5. Select a type and specify the authentication provider settings.
  6. Click Create.

For more information about using OmniAuth in GitLab, see this GitLab article.

Authentication provider settingsAuthentication provider settings

Some settings are shared across all providers:

  • Allow single sign on: Enables SSO. If you set it to true, GitLab automatically creates an account for a user signing in through OmniAuth who does not yet have a GitLab account.
  • Auto link users by email: Maps the username in OmniAuth to that in GitLab if both share the same email address.
  • Block auto-created users: Automatically marks the created accounts as Pending approval until approved by an administrator.
  • External provider: Sets the external attribute for the provider. Users authenticated through this provider will be treated as external and will have no access to internal projects.
  • Auto link LDAP user: Creates an LDAP entity for automatically created accounts. This setting only applies to instances with an LDAP provider.

Other settings depend on the provider type you select.

Bitbucket CloudBitbucket Cloud

  • Label: Name of the authentication provider. You can set any name.
  • Application ID: App ID obtained when setting up the provider.
  • Application Secret: Secret key obtained when setting up the provider.

You can learn how to obtain an app ID and secret key in this guide on setting up a provider.

Github EnterpriseGithub Enterprise

  • Label: Name of the authentication provider. You can set any name.
  • Application ID: App ID obtained when setting up the provider.
  • Application Secret: Secret key obtained when setting up the provider.
  • URL: Link to the GitHub repository.

You can learn how to obtain an app ID and secret key in this guide on setting up a provider.

GitLab self-managedGitLab self-managed

  • Label: Name of the authentication provider. You can set any name.
  • Application ID: App ID obtained when setting up the provider.
  • Application Secret: Secret key obtained when setting up the provider.
  • Site: Link to the GitLab repository.

You can learn how to obtain an app ID and secret key in this guide on setting up a provider.

Google OAuth 2.0Google OAuth 2.0

  • Label: Name of the authentication provider. You can set any name.
  • Application ID: App ID obtained when setting up the provider.
  • Application Secret: Secret key obtained when setting up the provider.

You can learn how to obtain an app ID and secret key in this guide on setting up a provider.

KeycloakKeycloak

Note

To work with GitLab, make sure your Keycloak server uses HTTPS.

  • Label: Name of the authentication provider. You can set any name.
  • Issuer: Authentication source URL, such as https://keycloak.example.com/realms/myrealm.
  • Client ID: Client ID obtained when configuring Keycloak.
  • Client Secret: Client secret key obtained when configuring Keycloak.
  • Site: Link to the GitLab repository.

LDAPLDAP

Warning

Before setting up LDAP integration, make sure users on the LDAP server cannot:

  • Change the mail, email, and userPrincipalName attributes. Users with these privileges could potentially access any account on the GitLab server.
  • Have a shared email address. LDAP users with a shared email address can use the same account in GitLab.
  • Name: Displayed user name in LDAP. It may not include spaces or punctuation marks.
  • Label: LDAP server name. You can set any name.
  • Host: LDAP server IP address or domain name.
  • Port: LDAP server connection port.
  • Username ID: User ID in LDAP.
  • Encryption: Traffic encryption method.
  • Base: Name of the LDAP directory that stores user accounts.
  • Bind DN: Unique distinguished name (DN) of a user in LDAP. This is an optional setting.
  • User Filter: LDAP user filter in RFC-4515 format. This is an optional setting.

To learn how to configure an LDAP server to work with GitLab, see this GitLab guide.

Microsoft Entra IDMicrosoft Entra ID

  • Label: Name of the authentication provider. You can set any name.
  • Client ID: Client ID obtained when registering the application.
  • Client Secret: Client secret key obtained when registering the application.
  • Tenant ID: Tenant ID obtained when registering the application.

To learn how to register an application on the Azure side, see this GitLab article.

Microsoft Azure OAuth 2Microsoft Azure OAuth 2

  • Label: Name of the authentication provider. You can set any name.
  • Client ID: Client ID obtained when registering the application.
  • Client Secret: Client secret key obtained when registering the application.
  • Tenant ID: Tenant ID obtained when registering the application.

To learn how to register an application on the Azure side, see this GitLab article.

SAMLSAML

  • Label: Name of the authentication provider. You can set any name.
  • Assertion consumer service URL: HTTPS endpoint of the GitLab instance. To create this URL, add /users/auth/saml/callback to your GitLab instance URL, such as https://example.gitlab.yandexcloud.net/users/auth/saml/callback.
  • IDP certificate fingerprint: SHA1 fingerprint of a public certificate key, e.g., 90:CC:16:F0:8D:.... It is issued when configuring the IdP.
  • IDP SSO target URL: IdP URL. It is issued when configuring the IdP.
  • Issuer: Unique ID of the application where user authentication will be performed, such as https://example.gitlab.yandexcloud.net.
  • Name identifier format: Name ID format. It is issued when configuring the IdP.

To learn how to configure SAML on the IdP side, see this GitLab article.

Yandex IDYandex ID

  • Label: Name of the authentication provider. You can set any name.
  • Client ID: Client ID obtained when registering the application.
  • Client Secret: Client secret key obtained when registering the application.
  • Site: Link to the GitLab repository.

To learn how to register an application on the IdP side, see this Yandex.OAuth article. When registering an app, allow access to the user's email address. If selecting web services as the platform, use the Redirect URI field to specify a URL in the following format:

https://<GitLab_instance_address>/users/auth/Yandex/callback

URL example:

https://my-domain.gitlab.yandexcloud.net/users/auth/Yandex/callback

Warning

When integrating with Yandex ID, any user with a Yandex account can log in to your instance. To prevent access by unauthorized users, set Allow single sign on and Block auto-created users to true. This allows GitLab to automatically create new users, while blocking them on first sign-in.

Yandex 360Yandex 360

Yandex 360 uses Yandex ID or LDAP as authentication providers. To allow Yandex 360 users to log into your GitLab instance, add and configure one of these providers in OmniAuth.

Warning

When using Yandex ID, the user's membership in a Yandex 360 organization is not verified during authentication. Any user with a Yandex account can log in to your GitLab instance. To prevent access by unauthorized users, set Allow single sign on and Block auto-created users to true. This allows GitLab to automatically create new users, while blocking them on first sign-in.

Was the article helpful?

Previous
Instance state monitoring
Next
Integration with Object Storage
© 2026 Direct Cursus Technology L.L.C.