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.

In this document, you will learn how to:

• 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 platform supports various IdP standards 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.

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.

FAQ: Authentication and Token Management

Q: Can I use my organization's existing Identity Provider (IdP) with the JFrog Platform?

A: Yes. The JFrog Platform relies on a "Delegated Trust" model. You can integrate with your existing IdP using widely recognized standards like SAML 2.0, OAuth 2.0, OIDC, and LDAP. This allows you to enforce your corporate authentication policies, such as Multi-Factor Authentication (MFA), while managing permissions centrally within JFrog.

Q: Can I use several tokens for different tasks simultaneously?

A: Yes. This is a core security feature known as the "Multiple Token Paradigm." You can generate distinct, purpose-built tokens for different tasks (e.g., one for UI access and another for a CI/CD script). Each token has its own scope and expiration, ensuring that if one token is compromised, it does not expose your entire account or administrative privileges.

Q: What is the difference between my SSO login and a JFrog Access Token?

A: Your SSO login (via SAML or OIDC) is used for the initial identity verification. Once the JFrog Platform verifies your identity with your IdP, it exchanges that external credential for a JFrog Access Token. This internal JWT (JSON Web Token) acts as your secure credential for all subsequent actions within the platform, carrying your specific permissions and scope.

Q: If I generate a new Access Token for a script, does it invalidate my current UI session?

A: No. Generating a new token does not automatically invalidate previous tokens. Each JFrog Access Token is an independent credential with its own unique ID (jti) and expiration date. This allows you to maintain a UI session while simultaneously running a script with a separate, narrowly scoped token.

Q: How do I handle authentication for CI/CD pipelines without storing static secrets?

A: We recommend using Service-to-Service OIDC integration. In this flow, your CI/CD provider (like GitHub Actions) issues a short-lived token that the JFrog Platform validates against a pre-configured Identity Mapping. If the validation succeeds, JFrog issues a temporary, scoped Access Token for the pipeline to use. This eliminates the need to store long-lived secrets or API keys in your CI/CD environment.

Q: What happens if a user leaves the organization?

A: If you use SCIM (System for Cross-domain Identity Management), your IdP can automatically push user de-provisioning updates to the JFrog Platform, which disables the user account and prevents token refreshes. For immediate termination, an administrator can explicitly revoke a user's active tokens via the Administration module or the REST API, adding them to the platform's revocation list.

Q: Should I use API Keys or Access Tokens for automation?

A: You should use Access Tokens. Access Tokens are the standard credential for the JFrog Platform; they are time-bound, revocable, and can be scoped to specific permissions (e.g., read-only access to a specific repository), ensuring you follow the Principle of Least Privilege. API Keys are deprecated and considered legacy credentials: they function like a password, making them less secure.

Q: Why should I implement SCIM if I already use SAML or OIDC?
A: While SAML and OIDC handle authentication, they do not always handle user lifecycle events like de-provisioning in real-time. SCIM follows best practices by allowing your IdP to push status changes (such as an employee leaving the company) directly to the JFrog Platform. This ensures that a disabled user cannot use a valid refresh token to obtain a new Access Token, closing a potential access window.