JFrog Authentication and Token Management Overview

Security in the modern software supply chain requires a delicate balance: you need robust identity verification without hindering the speed of development. The JFrog Platform employs a robust security model that delegates identity verification to external identity providers (IdPs) and adheres to widely recognized open standards like SAML 2.0, OAuth 2.0, OIDC, and LDAP. This architecture distinctly separates authentication (who you are) from authorization (what you can do).

This overview explains how the JFrog Platform leverages your existing enterprise identity infrastructure, such as Okta, Microsoft Entra ID, or an LDAP directory, while maintaining fine-grained control over your artifacts and builds through JFrog Access.

What You Will Learn

• Delegate Trust: Integrate with standard Identity Providers (IdPs) using SAML 2.0, OAuth 2.0, and OpenID Connect (OIDC).
• Standardize Credentials: Understand how external identities are exchanged for the canonical JFrog Access Token, the internal currency for all secure interactions.
• Minimize Risk: Use the Principle of Least Privilege to ensure production-grade quality.
• Manage Lifecycles: Effectively handle token expiration, revocation, and user termination.

Authentication Providers

The JFrog Platform employs a robust security model that delegates identity verification to external Identity Providers (IdPs) and adheres to widely recognized open standards like SAML 2.0, OAuth 2.0, OIDC, and LDAP.

This architecture distinctly separates authentication, which confirms user identity, from authorization, which governs user permissions. This approach allows you to integrate your existing identity infrastructures (such as Microsoft Entra ID, Okta, or internal LDAP directories) while centrally managing access control with JFrog Access.

Core Component: JFrog Access and the Canonical Credential

JFrog Access is the foundational microservice acting as the primary authority for all security operations within the platform, overseeing the entire authentication and authorization lifecycle.

The JFrog Access Token: The Canonical Credential

Each successful authentication, irrespective of the method used (SAML assertion, OIDC ID Token, or LDAP validation), is converted into the platform's standard JFrog Access Token:

• This JSON Web Token (JWT) acts as the primary internal credential for all authenticated interactions.
• It serves as the bearer token for all subsequent requests (web UI, API, or CLI).
• The token enforces security through its scope (scp) property, defining granted permissions and supporting the Principle of Least Privilege.
• Access Tokens are created with an optional expiration (exp) period, serving as a defense against misuse.

Identity Protocol Breakdown and Integration Methods

The JFrog Platform supports eight IdP standards and protocols tailored for different use cases and integration mechanisms:

SAML 2.0 SSO Authentication Flow

SAML 2.0 enables Single Sign-On, with the JFrog Platform acting as the Service Provider (SP).

Integration and Key Mechanisms

1. Initiation: The user navigates to the JFrog Platform URL. If the Auto Redirect Login Link to SAML Login option is enabled, the user is immediately redirected to the IdP.
2. SAML Assertion: The IdP constructs a digitally signed SAML Assertion (an XML document) containing the user's identity and claims.
3. Assertion Validation: JFrog Access verifies the digital signature on the assertion using the IdP's public certificate, uploaded during configuration.
4. Hybrid Group Synchronization: The platform supports enabling the synchronize-ldap-groups setting for the SAML provider, allowing JFrog to perform a secondary lookup against a configured LDAP server to retrieve authoritative group memberships after successful SAML authentication.
5. Logout Security: Full security requires configuring the SAML Logout URL to the IdP's Single Logout (SLO) endpoint, ensuring termination of the master authentication session. Failure to configure SLO creates a security gap.

For more information, see SAML SSO Configuration and the SAML-Based SSO Login Process.

OAuth 2.0 / OpenID Connect (OIDC) Authentication Flow

OIDC is an identity layer built on OAuth 2.0, utilized for user-facing SSO and automation.

User-Facing SSO (Authorization Code Flow with PKCE)

• Flow: The JFrog Platform redirects the user to the IdP with a code_challenge. The IdP returns a temporary authorization_code.
• Security: The JFrog backend exchanges this code for an id_token by submitting the original code_verifier, which proves the client requesting the token is the same one that initiated the flow, mitigating interception attacks.

For more information, see Enable Authorization Code Flow with PKCE.

Service-to-Service OIDC (CI/CD Automation)

This flow is the recommended standard for automation, as it eliminates the need for persistent, long-lived secrets.

• Workflow: A CI/CD pipeline requests a short-lived OIDC id_token from its provider (e.g., GitHub's OIDC provider). This token contains verifiable claims about the workflow (e.g., repository, branch).
• Identity Mapping: JFrog Access validates the token and matches its claims against pre-defined Identity Mappings (policy rules configured in the UI).
• Ephemeral Token Generation: If a match is successful, JFrog Access generates a very short-lived, narrowly-scoped JFrog Access Token. The permissions are defined entirely by the matched mapping. This approach implements Policy-as-Code for authentication.

For more information, see OpenID Connect Integration and Identity Mappings.

Transient Users and Auto Join Groups

An identity mapping can map a user, groups, both, or neither. If you include a username pattern, the generated token automatically receives the applied-permissions/user scope.

If that username does not exist in the system, a transient user is created at authentication time. This transient user dynamically inherits all groups configured with Automatically Join New Users. If your mapping includes both a user and explicit groups, the effective permissions become a union of the explicitly mapped groups and the local Auto Join groups.

LDAP / Active Directory Authentication Flow

LDAP provides direct server-to-server integration for user and group management.

Integration Steps

1. Search-Based Authentication (Recommended): The Platform first performs a "bind" using a dedicated Manager DN service account to search the directory for the user's Distinguished Name (DN).
2. User Authentication: The Platform attempts a second "bind" using the user's full DN and the submitted password. A successful bind confirms validation.
3. Group Sync: The user's permissions are determined by group memberships synchronized from the LDAP directory.
4. Security Best Practice: To avoid "split-identity" confusion (where a user exists in both LDAP and the internal JFrog database), administrators should consider disabling the Disable Basic Authentication Method once the external IdP is fully configured.

For more information, see LDAP Configuration and Prevent Authentication Fallback to the Local Artifactory Realm.

SCIM (System for Cross-domain Identity Management)

SCIM is listed as an authentication provider but primarily functions as a lifecycle management protocol.

• Primary Role: SCIM allows the external IdP (like Okta or Azure AD) to proactively push user status changes (e.g., deactivation or deletion) to the JFrog Platform.
• Security Necessity: Implementing SCIM is strongly recommended when using refreshable tokens. Without it, a user disabled in the IdP might still be able to use a refresh token to obtain a new Access Token.

For more information, see SCIM.

HTTP SSO

HTTP SSO relies on authentication being handled by an external component (like a reverse proxy or web server) before the request reaches the JFrog Platform. Note that HTTP SSO is not supported for SaaS, and is not recommended.

• Mechanism: You can configure HTTP SSO in the JPD, use it to integrate Apache and Tomcat, and set up a Reverse SSL Proxy for SSO.
• Token Usage: Users authenticated via HTTP SSO can still use API Keys.

For more information, see Configure HTTP SSO in JPD.

Atlassian Crowd and JIRA Integration

This integration provides a dedicated mechanism for connecting with Atlassian's identity services.

• Mechanism: The integration manages authentication and group synchronization via the Crowd service. You can configure the Crowd server URL and application credentials directly within the platform settings.
• Use Case: This is typically used for legacy or dedicated identity integration setups where Atlassian Crowd serves as the central user management system.

For more information, see Atlassian Crowd and JIRA Integration.

mTLS Authentication in JFrog Cloud

Mutual Transport Layer Security (mTLS) is a specialized framework used primarily in specific JFrog Cloud deployments.

• Mechanism: The integration authenticates clients using cryptographic certificates rather than passwords or tokens, ensuring mutual validation between the client and the server.
• Key Feature: This method provides a high-security framework often required for cloud-to-cloud communication or restricted network environments.

For more information, see mTLS Authentication in JFrog Cloud.

Access Token Management: Enforcement and Lifespan

The architecture relies on the "Multiple Token" Paradigm to enforce the Principle of Least Privilege.

The Multiple Token Paradigm

An authenticated identity can generate multiple, distinct, purpose-built Access Tokens, each with its own specific scope (scp) and lifetime. This strategy limits the "blast radius" if any single token is compromised.

• Scoping: Tokens can be narrowly scoped to grant permissions based on groups (applied-permissions/groups:), project roles (applied-permissions/roles::), or specific resource operations (e.g., artifact:my-repo/path/to/file:r for read access to a specific file).
• Use Case: An administrator can generate one powerful UI session token, and a separate, narrowly-scoped token for a script, ensuring the script token cannot perform administrative actions.

For documentation on token creation, see Access Tokens, Generate Expirable Tokens, and Create a Group Scoped Token.

Token Invalidation and Revocation

While JWTs are primarily invalidated by reaching their natural expiration (exp) date, explicit revocation is necessary for pre-expiry termination (e.g., compromise or user logout).

• Mechanism: JFrog Access maintains a revocation list (blacklist) of token IDs (jti). When a token is revoked, its jti is added to this list, and Access checks this list during subsequent validation.
• Key Warning: Generating a new token does not automatically invalidate any previous tokens. A compromised token must be explicitly revoked.
• SCIM Recommendation: For environments using refreshable tokens, SCIM (System for Cross-domain Identity Management) is highly recommended. SCIM allows the IdP to push user de-provisioning status to the Platform, ensuring a disabled user cannot use a refresh token to obtain a new Access Token.

For administration, see View and Revoke Tokens and the Access Tokens REST API.

This foundation ensures that JFrog's authentication and token management ecosystem upholds the highest security standards, offering flexible, scalable, and secure access management solutions.

Frequently Asked Questions

This section provides answers to frequently asked questions about JFrog authentication methods, identity provider integration, and Access Token management.

Related Topics

• Access Tokens
• SAML SSO
• OpenID Connect Integration
• LDAP Configuration
• SCIM