Skip to main content

This might be more of a rant than anything.

I've spent my day just simply trying to get a script together for our Cart devices to rename the devices to the Bar Code 1 value since those don't change through restores and would enable my techs to just restore the device and put it back in the cart. Zero touch beyond actually restoring the device.

For completionist sake I did get it to work fully as expected!

Come to find out the bearer token you need to generate only lasts for 30 minutes meaning that hard coded credentials either get passed via the script or in the $4 $5 fields.

I kind of get the idea behind only having a 30 minute token but you really can't make it any longer? For instance doing the restores on the carts only take about 2 or 3 days. I can't just set it for 5 days then just regen a new token every summer?

Am I just looking at this the wrong way?

@ajanicke You should take a look at the new Client Credentials mechanism for accessing the Jamf Pro API that was added in JSS 10.49: https://developer.jamf.com/jamf-pro/docs/client-credentials

@ajanicke You should take a look at the new Client Credentials mechanism for accessing the Jamf Pro API that was added in JSS 10.49: https://developer.jamf.com/jamf-pro/docs/client-credentials


Unfortunately we're still on 10.44 but reading through it seems it's the same situation where you only get "short lived access token" instead of real access that can be used for production purposes. Seems the API is used more for running really in depth reports due to the time out of the access token and constantly having to refresh it.

If I am not mistaken if you are still on prem you can change the token time out in the JAMF configuration files. We moved to cloud some time back, so I'm not sure if this is still current information.

If I am not mistaken if you are still on prem you can change the token time out in the JAMF configuration files. We moved to cloud some time back, so I'm not sure if this is still current information.


Now that could be what I need. I'll take a look if I can find it. I think we're going to try to upgrade to 11 over the summer if time permits.

Now that could be what I need. I'll take a look if I can find it. I think we're going to try to upgrade to 11 over the summer if time permits.


The token itself should be short-lived and expired after each use, but the credentials that generate the token don't really change unless you change them/regenerate (ie, how an API secret or credential should behave). So rather than using a temporary (by design) "Bearer Token", use API clients and secrets to create your on-demand Bearer Token. The Bearer Token is meant to be session specific, you're supposed to get a new one for every session/API request.

The token itself should be short-lived and expired after each use, but the credentials that generate the token don't really change unless you change them/regenerate (ie, how an API secret or credential should behave). So rather than using a temporary (by design) "Bearer Token", use API clients and secrets to create your on-demand Bearer Token. The Bearer Token is meant to be session specific, you're supposed to get a new one for every session/API request.


Oh, and even if you haven't upgraded your Jamf server, you can still create an "API user" with only the permissions it needs, like' we've been doing for years. It's username and password are not dissimilar from the new "Clients and secrets", they both give you credentials for generating your Bearer Token. It's just the new stuff gives you a better way to manage API clients, and generates randomized secrets that you can revoke, expire, etc. But it's conceptually the same stuff as far as encoding them as bas64 and using them in your cURL calls to get your session tokens.

Oh, and even if you haven't upgraded your Jamf server, you can still create an "API user" with only the permissions it needs, like' we've been doing for years. It's username and password are not dissimilar from the new "Clients and secrets", they both give you credentials for generating your Bearer Token. It's just the new stuff gives you a better way to manage API clients, and generates randomized secrets that you can revoke, expire, etc. But it's conceptually the same stuff as far as encoding them as bas64 and using them in your cURL calls to get your session tokens.


The issue with this is that if the API call is running on the users system then it can been seen when the call/post is made to the API. Base64 is easily decoded. If you are running this policy daily on 1000+ machines it's a kind of big security hole. If you just use a bearer token that last for a while (instead of needing to request a new one every time the script is run) then at least the attacker would not get the API User and password. Sure the bearer token could be used during that time but you can limit what it can do and easily revoke it, the API account would not be compromised. 


The real solution to this would be to have a policy option to create a bearer token on the fly (using an API account, with the token being created on the server) then it could be passed to the script.

Reply


Terms & ConditionsCookie settings