Auth Process

Serval’s Jamf integration utilizes the Client Credentials grant type, also known as two-legged OAuth 2.0.

Here's a brief overview of how it works:

1. Customer generates a unique Client ID and Client Secret in their Jamf instance.
   1. Customer can decide which scopes to provide Serval access to at this stage. This will govern which automations are possible within Serval. Scopes should be configured according to the principle of least privilege.
   2. A maximum access token TTL can also be configured by the customer within Jamf.
2. The Client ID and Client Secret values are entered into the Serval application.
3. When access is needed, our server sends these credentials to Jamf's token endpoint (this is a unique endpoint for each Jamf instance).
4. Jamf verifies the credentials and returns a short-lived access token.
5. Our application uses this token to make authenticated requests to the Jamf API.

Credential Storage and Access

• All Serval access credentials are encrypted at rest in a database located in an isolated production VPC. We use dedicated KMS keys to encrypt data in the table columns for access credentials.
• Instances and data in the production VPC can only be access via our VPN (Tailscale). Public API access is facilitated by load balancers. Only authorized engineers have access to the VPN.
• Serval workflows which leverage API credentials are executed in a separate, isolated VPC (our “worker” VPC). Worker containers are single tenant.
• Workers make requests to Jamf using a proxy hosted in the main VPC. The worker authenticates with the proxy using worker specific authentication credentials (short-lived JWT), then the proxy creates a valid Jamf auth token using the process described above and forwards the request to Jamf and the response back to the worker. This ensures that API credentials are kept within the proxy service and associated database and that they are only decrypted for the shortest possible time period.