Classic API Authentication Changes

Overview

This article describes the changes to the authentication mechanisms supported by the Classic API, beginning in version 10.35.0 of Jamf Pro, as well as recommendations on how to update your tools or applications to support these changes.

Client Credentials

Beginning in version 10.49.0 of Jamf Pro, support for client credentials based authentication was added to the Classic API. For more details see Client Credentials.

Bearer Token Authentication

Beginning in version 10.35.0 of Jamf Pro, the Classic API now accepts Bearer Token authentication. Tokens can be obtained from the Jamf Pro API using the /v1/auth/token endpoint. Please refer to the Jamf Pro API Overview documentation for more details on interacting with the Jamf Pro API.

❗️

Notice

As of version 10.35.0, multiple versions of authentication endpoints are supported by Jamf Pro, some of which have been deprecated and will be removed at a future date. When updating applications to support Bearer Token authentication, ensure that you use the latest version of the authentication endpoints. More information about endpoint deprecations can be found here.

Requirement to Use Bearer Tokens with Basic Authentication

Prior to Jamf Pro version 11.5.0, Basic Authentication (Username and Password) could be used natively to authenticate calls to any Classic API endpoint. It is still possible to authenticate with username and password, however those credentials can now only be used to obtain an automatically-expiring Bearer Token using the /v1/auth/token endpoint; the bearer token is then used to authenticate calls to other API endpoints. The bearer token flow was added in version 10.42.0.

Starting with Jamf Pro version 11.17.0, it is no longer possible to bypass the the deprecation of using Basic Authentication for anything other than obtaining an access token. Prior to 11.17.0 Jamf provided an option to enable/disable that functionality within Jamf Pro's user Interface.

Attempting to use Username and Password with any endpoint other than /v1/auth/tokenwith a Jamf Pro environment that has disabled support will result in a 401 Unauthorized response. Note that this response is the same as the response received when using invalid credentials to interact with the Classic API via Basic authentication.

📘

Basic vs. Client Credential Authentication

Both basic (username and password) and client credential authentication continue to be supported methods of obtaining an API access token and both have valid use cases. Traditionally, basic authentication has been used when a user was being asked to do an interactive login, while client credentials were more commonly used in server-to-server integrations with no human user. However, client credentials can be used in any program that obtains its API secrets programmatically and this option has a number of security advantages:

• Role-based access controls
• Automatically-generated complex secrets with easy rotation
• Compatibility with JWT / oAuth-standard code libraries

Resources and Best Practices

Jamf recommends providing backwards compatibility for your applications that interface with the Classic API. By implementing a version check of Jamf Pro, your application can determine whether Bearer Token authentication is supported (v10.35.0 or later) or if use of Basic authentication is required (v10.34.0 and earlier). The jamf-pro-version endpoint within the Jamf Pro API returns the version of the Jamf Pro Server, to help your application determine authentication compatibility with a given Jamf Pro Server. Jamf recommends including a preference to allow users to select the authentication schema based on their environment configuration or dynamically determining which authentication mechanism to use based on the Jamf Pro Server version.

In addition to the recommendations provided above, Jamf has updated the Postman Collection to now default to the use of Client Credentials authentication.