Modern Identity for the Jamf Platform

5 min readOct 6, 2025

It wasn’t that long ago that we were sitting in meetings hearing about the Jamf platform of the future. In the fast-moving world of technology, that future arrived quickly. Today we’re proud to say we are building the platform of the now — a foundation that is modern, unified, and based on open standards.

Over the years, Jamf has grown through both internal development and acquisition. That growth led to a patchwork of technologies, each with its own authentication method and release cycle. Customers often had to remember multiple logins across our products. Integrations were one-off and difficult to reuse. Internally, engineers were slowed down by fragmented identity and inconsistent deployment processes.

Our mission was clear: unify identity across the Jamf ecosystem. Doing so would give customers a seamless single sign-on experience while also simplifying engineering by providing a consistent way to authenticate and authorize requests across our platform.

User Identity: From Fragmentation to Federation

Previously, each Jamf product handled identity on its own — sometimes with local usernames and passwords, sometimes with direct SAML connections to a customer’s IdP. Supporting all of these variations was complex, expensive, and inconsistent.

We solved this by introducing a centralized identity broker configured in Jamf Account. Customers who bring their own IdP can federate once and use it everywhere across Jamf. Customers without an external IdP can fall back to Jamf ID. Either way, all identities and federated connections live in one place, making it simpler to maintain and easier for customers to configure.

At the core of this broker is OpenID Connect (OIDC), an authentication layer built on top of OAuth 2.0 providing identity and session management. We use the Authorization Code Flow, which is widely regarded as the most secure approach for server-side applications:

Authorization Code Flow: Sensitive tokens are exchanged through a secure back channel, ensuring they are not exposed in browser redirects.
Claims normalization: All tokens carry consistent subject identifiers (sub), groups, and role claims across our ecosystem.

You can view a more detailed version of this diagram in Jamf’s documentation, here and here.

This shift gave us a single identity for users across Jamf, making privileges, auditing, and logging enforceable everywhere — whether in a monolithic app or a distributed set of micro frontends and microservices.

Customers are already seeing the impact: features like Blueprints and Compliance Benchmarks can be built once and deployed across multiple Jamf solutions. Updates are less risky, rollouts are faster, and features can be released independently of full product upgrades.

Machine Identity: Securing Service-to-Service Communication

Once user identity was solved, we turned to machine-to-machine (M2M) communication. Many Jamf workflows require services to talk directly to one another — for example, when Jamf Protect detects a security event and notifies Jamf Pro or Jamf School to remediate it.

Historically, each integration used its own mechanism: basic auth, API keys, or product-specific tokens. This wasn’t scalable.

Now, all M2M communication uses the OAuth 2.0 Client Credentials Flow. This works by exchanging a client_id and client_secret for an access_token, which is then used in API requests. Standardizing on this flow brings multiple benefits:

Consistency: Every Jamf API, internal or external, authenticates the same way.
Security: Secrets are rotated centrally, reducing risk from long-lived credentials.
Scalability: Tokens can carry scopes and claims, limiting access to only what’s needed.

The result: we’ve moved away from brittle, legacy authentication patterns toward a system that is both secure and developer-friendly.

A Unified API Gateway

The final piece of the puzzle is our unified API gateway, which supports both user-based and machine-based authentication. Instead of different URLs and authentication methods per product, we now provide a single entry point. That same entry point can be used regardless of if you’d like to make requests to platform services like Blueprints and Compliance Benchmarks or directly to underlying product APIs.

From there, the gateway handles token validation, routing, and token exchange. This makes life easier for:

Engineers inside Jamf, who can build new services faster on a consistent platform.
Partners and customers, who now have a predictable way to integrate across the Jamf ecosystem.

Centralizing token issuance in Jamf Account means you can request credentials once and use them everywhere. It also allows for context-preserving token exchanges, where a user token can be transformed into a service token with the appropriate scope — without losing traceability of the original user context.

How to Get Started

If you’re a Jamf customer, you may already be using OIDC single sign-on in products like Jamf Protect, Jamf School, and Jamf Connect. Jamf Pro users can enable OIDC SSO today by following our documentation. There are more helpful links at the bottom of this article.

Whether you bring your own IdP or use Jamf ID, once you log in with OIDC you’re fully onboarded into Jamf’s modern authentication platform. From there, you can start exploring M2M integrations and the new unified API gateway.

Closing Thoughts

Unifying authentication across Jamf has been a transformative step for our platform. By adopting modern, standards-based identity — OIDC for user authentication and OAuth 2.0 client credentials for machine communication — we’ve created a foundation that is secure, scalable, and developer-friendly.

This isn’t just about simplifying logins. It’s about enabling faster feature delivery, safer integrations, and a more cohesive platform for customers and engineers alike.

Helpful Links

Configuring your OIDC IdP in Jamf Account

More information about current Jamf Platform services capabilities

Common SSO FAQs

Jamf Engineering