Home > Jamf Pro, Jamf Pro API, Jamf Pro Classic API, Scripting > Basic Authentication deprecated for the Jamf Pro Classic API

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 of the Jamf Pro 10.35.0 Release Notes:

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.

Screen Shot 2022 01 04 at 11 54 23 AM

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

Screen Shot 2022 01 04 at 11 54 52 AM

For more details, please see below the jump.

For the Classic API, here’s what’s required for authentication using Basic Authentication:

  • One step process.
  • Only username and password needed to authenticate an API call.
  • Username and password can be in plaintext.
  • No tokens are used.

Example Classic API call process using Basic Authentication:


# Provide username and password as part of the API call:
/usr/bin/curl -su "username_here:password_here" -H "Accept: application/xml" https://server.name.here/JSSResource/packages/id/2

view raw

gistfile1.txt

hosted with ❤ by GitHub

For the Classic API using Bearer Token authentication, here’s what’s required for authentication:

  • Multi-step process involving multiple API calls.
  • Username and password only used to get authentication token, known as a Bearer Token. The Bearer Token is subsequently used for authentication.
  • Username and password must be base64-encoded.
  • Bearer Tokens are valid for 30 minutes maximum.
  • Introduces need to validate authentication Bearer Tokens before making an API call.

Example Classic API call process using Bearer Token authentication:


# 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 –request GET –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

view raw

gistfile1.txt

hosted with ❤ by GitHub

Screen Shot 2022-01-04 at 5.09.20 PM

The differences in authentication are significant enough that I’ve written shell scripting functions to handle the following tasks for Bearer Token authentication:

  • Obtaining Bearer Token.
  • Verifying that current Bearer Token is valid and unexpired.
  • Renewing Bearer Tokens by using current Bearer Token to authenticate the issuing of a new Bearer Token. (This renewal process creates a new Bearer Token and invalidates the old Bearer Token.)
  • Invalidating current Bearer Token.

Please see the link below for more information on this topic:

https://derflounder.wordpress.com/2021/12/10/obtaining-checking-and-renewing-bearer-tokens-for-the-jamf-pro-api/

  1. January 19, 2022 at 3:40 pm

    Thanks for the heads up on this. I found it very helpful and useful. I was wondering if you could help further explain something.

    Why do you do the check on whether the token is valid? Shouldn’t the token be valid if you’re running on the script once? It grabs the token and should still be valid shouldn’t it?

    To expand my question, why validate the token at all, when we could just grab a new token each time we wanted to make a call to the API?

    • January 19, 2022 at 4:37 pm

      The check is there in case a particular task takes 30 minutes or more to complete.

      An example of this would be deleting a large number of packages via the API. Individually, the packages may take 30 seconds or less to delete. If you have 100 or more packages to delete, the Bearer Token will likely expire before the job is completed. By checking to see if the token is still valid and automatically renewing it if it is not, the job can complete successfully.

  2. January 19, 2022 at 5:19 pm

    That makes a lot of sense. Our instance is pretty small, and couldn’t fathom anything taking that long. Thanks for the reply and the post.

  3. anon
    February 15, 2022 at 8:07 pm

    You are missing an opening quote before “username_here” in your basic authentication curl example. Should be: /usr/bin/curl -su “username_here:password_here” -H “Accept: application/xml” https://server.name.here/JSSResource/packages/id/2

  4. Scott Wertz
    February 18, 2022 at 8:41 pm

    I’m getting “Unknown format specifier: raw” from plutil and the man page lists the options as xml1, binary1, json, swift, and objc. Should that be binary1? Or is your plutil different from the one I have in Big Sur?

    • February 18, 2022 at 8:45 pm

      plutil changed between Big Sur and Monterey and the plutil command referenced only works on Monterey and (presumably) later.

  5. January 4, 2023 at 6:20 pm

    Any word on when this will be officially removed? We’re doing a presentation today on how to migrate your scripts to Token Bearer Auth and want to be the potentially “Bearer of bad news” (pun intended)

  1. No trackbacks yet.

Leave a comment