doc/auth/auth_glossary.md
This glossary defines terms related to authentication, authorization, and access control in GitLab.
External identity providers and protocols that establish and verify user identities across systems. These terms describe how GitLab integrates with enterprise identity management systems to centralize user authentication.
The service that manages your user identities, such as Okta or OneLogin.
An application that delegates authentication to an external identity provider. GitLab acts as a service provider when configured for SAML or OIDC authentication.
An authentication method that allows users to access multiple applications with a single set of credentials. With SSO, users authenticate once through an identity provider and gain access to GitLab and other connected services without re-entering credentials.
Security Assertion Markup Language, an XML-based protocol for exchanging authentication and authorization data between identity providers and service providers. GitLab supports SAML authentication for enterprise single sign-on.
Lightweight Directory Access Protocol, a standard for accessing and maintaining directory information services. GitLab integrates with LDAP servers to authenticate users and synchronize account information.
System for Cross-domain Identity Management, a standard for automating user provisioning and deprovisioning. GitLab supports SCIM to synchronize user lifecycle events from identity providers.
An authentication layer built on OAuth 2.0 that provides identity verification. GitLab supports OIDC for authentication and acts as an OIDC provider for external applications.
An authorization protocol for accessing GitLab resources on behalf of users without sharing passwords. OAuth supports third-party integrations and GitLab as an identity provider.
A piece of information about a user identity, such as their name or role. Also known as a claim or an attribute.
Information about a user identity or attributes included in authentication tokens. Claims are used in OAuth, OIDC, and JWT tokens to convey details like username, email, or group membership.
The automated process of creating and configuring user accounts and access rights. You can use SCIM or LDAP to synchronize users from external identity systems into GitLab.
The endpoint on GitLab where users are redirected after successfully authenticating with the identity provider.
How GitLab identifies itself to an identity provider. Also known as a relying party trust identifier.
Confirms that SAML communications are secure by verifying that the server is signing communications with the correct certificate. Also known as a certificate thumbprint.
Methods and credentials that verify a user identity before granting access to GitLab. Authentication confirms who you are before granting access to the system. Authentication methods include passwords, two-factor authentication, SSH keys, personal access tokens, and integration with external identity providers.
A passwordless authentication method using cryptographic credentials stored on devices. Passkeys provide phishing-resistant authentication using biometrics or device PINs.
An additional security layer that requires users to provide a second form of authentication beyond their password. GitLab supports various 2FA methods, including authenticator apps and recovery codes.
A temporary authenticated state that persists after a user signs in to GitLab. Sessions persist across requests until the session expires or is terminated.
Cryptographic keys used for secure authentication when accessing Git repositories. SSH keys provide a secure alternative to password-based authentication for Git operations.
A token that acts as an alternative to passwords for authentication when using the GitLab API or Git over HTTPS. Personal access tokens have defined scopes that limit what actions they can perform.
A token scoped to a specific group for automated tasks in that group and any subgroups. Group access tokens inherit the group permissions and support API access and Git operations.
A token scoped to a specific project for automated tasks in that project. Project access tokens are commonly used for CI/CD pipelines and integrations that need project-specific access.
A token with limited scopes for deployment automation. Deploy tokens provide read-only or write access to repositories and package registries without requiring a user account.
A compact token format for securely transmitting information between parties. GitLab uses JWTs for CI/CD job authentication, OAuth flows, and service-to-service communication.
An administrative capability for authorized users to temporarily act as another user. Impersonation is sometimes used to troubleshoot user-specific issues.
Account types and user categories that define different access levels and capabilities in GitLab. These terms describe the various kinds of accounts that can interact with the system.
An individual account that represents a person accessing GitLab. User accounts can be assigned various roles across different groups and projects.
The type assigned to a user account that implicitly grants a set of permissible actions. Types include Regular, Auditor, and Administrator. Types are different from roles and permissions.
A user type with the highest level of system access. Users with administrator access can configure instance-wide settings, manage other users, and perform administrative tasks across all groups and projects.
A special user type with read-only access to all groups, projects, and administrative functions. Auditor users cannot make changes but can view content for compliance and security purposes.
Users designated as external to your organization who have restricted access to internal projects and groups. External users can only access projects where they have a direct membership.
Non-human user accounts designed to perform automated actions, access data, or run scheduled processes. Service accounts are commonly used in pipelines or third-party integrations.
Frameworks and processes that determine what authenticated users can do in GitLab. Authorization evaluates permissions based on user identity, roles, and resource ownership.
The practice of restricting access to resources based on authentication (verifying who a user is) and authorization (determining what a user can do).
The process of determining what actions an authenticated user can perform in GitLab. Authorization is based on the assigned user roles, permissions, and membership in groups and projects.
An access control model where permissions are assigned through roles rather than directly to users. In GitLab, users receive permissions based on their assigned role in a group or project.
A set of authorization rules that determine what actions principals can perform on resources. GitLab enforces access control decisions using the Declarative Policy framework.
Building blocks that define what actions users can perform on resources. Permissions combine into roles, which are assigned to users to grant specific capabilities.
The specific actions a user can perform on GitLab resources, like creating issues, pushing code, or managing project settings.
Sets of one or more permissions assigned to a user that define the actions they can perform in groups and projects. Roles include both default roles and custom roles.
Predefined roles available in every GitLab instance. Each role includes a specific set of permissions. The following default roles are available:
Roles that you create for your GitLab instance to meet your organizational needs. Each custom role extends a default role with additional permissions.
The permissions available to a token or OAuth application at a specific organizational level. GitLab uses scopes to determine the access granted to personal access tokens, group access tokens, project access tokens, and OAuth applications.
Hierarchical containers and relationships that organize resources and control access. These structures determine how permissions flow through groups, projects, and namespaces.
A container that organizes groups and projects in a hierarchical structure. Namespaces determine resource paths and permission inheritance. Each user has a personal namespace, and groups provide shared namespaces for teams.
A collection of related projects and users that enables efficient organization and permission management. Groups can contain subgroups and inherit permissions from parent groups.
A user who has been granted access to a specific group or project. Members have an assigned role that determines their permissions in that resource.
The association between a user and a specific group or project that defines their access rights in that resource. Users can have different memberships and roles across multiple groups and projects.
The organizational levels where permissions and policies can be applied:
The automatic flow of permissions from parent groups to child groups and projects. Inheritance simplifies access management by applying permissions granted at a higher level to all nested subgroups and projects.
Settings that control who can view and access your content: