Home > Jamf Pro, Jamf Pro API, Jamf Pro Classic API, Scripting > Basic Authentication deprecated for the Jamf Pro Classic API
As part of the release of Jamf Pro 10.35, the following note was added to the Deprecations and Removals section:
Basic authentication — Jamf will discontinue support for Basic authentication in the Classic API in a future release of Jamf Pro (estimated removal date: August-December 2022) for enhanced security. Jamf will provide additional information at a later date. To disable Basic authentication before support is removed, contact Jamf Support via Jamf Account.
To help folks prepare for this change, as of Jamf Pro 10.35.0, both Basic Authentication and using Bearer Tokens generated by the Jamf Pro API can be used for Jamf Pro Classic API authentication. This is noted in the New Features and Enhancements section of the Jamf Pro 10.35.0 release notes:
You can now use the Classic API to authenticate using Basic authentication or a Bearer Token retrieved through the /v1/auth/token Jamf Pro API endpoint for enhanced security. For information on Bearer Token authentication, see the Jamf developer resources: https://developer.jamf.com/jamf-pro/docs/classic-api-authentication-changes
For more details, please see below the jump.
For the Classic API, here’s what’s required for authentication using Basic Authentication:
Example Classic API call process using Basic Authentication:
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
For the Classic API using Bearer Token authentication, here’s what’s required for authentication:
Example Classic API call process using Bearer Token authentication:
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
# Get username and password encoded in base64 format and stored as a variable in a script: | |
encodedCredentials=$(printf username_here:password_here | /usr/bin/iconv -t ISO-8859-1 | /usr/bin/base64 -i -) | |
# Use encoded username and password to request a token with an API call and store the output as a variable in a script: | |
authToken=$(/usr/bin/curl https://server.name.here/api/v1/auth/token –silent –request POST –header "Authorization: Basic ${encodedCredentials}”) | |
# Read the output, extract the token information and store the token information as a variable in a script: | |
api_token=$(/usr/bin/plutil -extract token raw -o – – <<< “$authToken”) | |
# Verify that the token is valid and unexpired by making a separate API call, checking the HTTP status code and storing status code information as a variable in a script: | |
api_authentication_check=$(/usr/bin/curl –write-out %{http_code} –silent –output /dev/null https://server.name.here/api/v1/auth/keep-alive –request POST –header "Authorization: Bearer ${api_token}") | |
#Assuming token is verified to be valid, use the token information to make an API call: | |
/usr/bin/curl –silent -H "Accept: application/xml" –header "Authorization: Bearer ${api_token}" https://server.name.here/JSSResource/packages/id/2 |
The differences in authentication are significant enough that I’ve written shell scripting functions to handle the following tasks for Bearer Token authentication:
Please see the link below for more information on this topic: