Service Account for APIs

Previously, API access was tied to individual Admin accounts, requiring either the creation of dedicated Admin accounts for integrations or the use of Admins’ personal API keys.

This approach presented several issues like increased number of Admin accounts and single points of failure. For example, if an Admin left the org or if their account was disabled, all the dependent integrations would fail and be disruptive.

JumpCloud lets you create Service Accounts that are not tied to individual Admin accounts. Any authorized Admin can generate and manage keys for specific use cases without creating more Admin accounts which significantly improves security, maintenance, and reliability of our integrations.

Why Use a Service Account?

Service Accounts are the digital IDs for your applications, letting you automate workflows securely and at scale. They replace risky, hardcoded credentials with a manageable, auditable, and least-privilege approach to access control, drastically reducing your attack surface.

Here are a few reasons why you should use a Service Account instead of an Admin Account linked with API keys.

Non-Human Identity

A Service Account is a non-human identity used by automated systems (scripts, services, or CI/CD pipelines) to authenticate and interact with APIs or systems without user intervention.

Token-Based Access (Client ID + Client Secret)

The Service Account uses client credentials (Client ID and Client Secret) to request an access token via an OAuth 2.0 token endpoint. This token is then used to make authenticated API calls as part of a workflow.

Role-Based Access Control (RBAC)

The Service Account is granted specific permissions or scopes to perform only certain actions (for example: creating users, triggering provisioning, or fetching device data). These roles ensure the Service Account has just enough access needed by the workflow.

Trigger Points for Automation

Workflow automation tools (like Zapier, Jenkins, GitHub Actions, or internal schedulers) use the Service Account credentials to:

• Trigger actions on schedule
• Respond to events (webhooks, cron jobs)
• Poll APIs regularly
• Handle error retries or escalations

Adding a Service Account

To add a Service Account:

1. Log in to the JumpCloud Admin Portal.
2. Go to Settings> Service Accounts.
3. Click + New to add a new Service Account.
   
4. Enter the Name of the account, then select a Role from the dropdown menu.
5. Under Key Type, select the Client Secret radio button. A pop-up for setting the expiration date appears.
   

6. Set an expiration date for the Service Account by selecting a date from the Secret Lifetime dropdown menu. 
7. Click Activate.
8. The Client ID and Client Secret are displayed. These are only displayed at the time they’re created. Make sure to store it in a secure place, like JumpCloud’s Password Manager so you can access it when you need it. Click Close.
   
   The new Service Account will appear under the Service Accounts tab in Settings.
   An Admin with billing role can create multiple Service Accounts. Each Service Account will have 2 Client Secrets. In case one Client Secret is about to expire, the organization can leverage the  other one. The Admin will receive an email 7 days prior to the expiration date.

Click the Add item button on right to add one more client secret as required.

Deleting Client Secrets

To delete a client secret:

1. Click the Delete button next to the client secret. A pop-up appears prompting you to confirm the deletion.
2. Click Delete.
   The Client Secret should no longer be listed.

Deleting a Service Account

To delete a Service Account:

1. Select the Service Account you want to delete.
2. Click the Delete Account button in the upper right corner. A pop-up appears prompting you to confirm the deletion.
3. Enter the Service Account name and click Delete.
   The Service Account should no longer be listed.

Example: Using JumpCloud Service Account for Interacting with JumpCloud APIs

Storing the Client ID and Secret

Add a new Service Account. The Client Secret is only visible at the time of creation. It is sensitive information that must be stored securely. Make sure to store it in a secure place, like JumpCloud’s Password Manager so you can access it when you need it.

For example:

• Client ID:  sa_68d11d62e6adb60001a8121d
• Client Secret: YwEelr6T6-Mr2MnOI9NV~Vwr6e
  

Encode Client ID and Client Secret

1. Encode ClientID and Client Secret with Base64 encoding. The following example shows the command to perform base 64 encoding of Client ID and Client Secret using shell in mac OS:
   % echo -n sa_68d11d62e6adb60001a8121d:YwEelr6T6-Mr2MnOI9NV~Vwr6e | base64
   The output would look like the following string:
   c2FfNjhkMTFkNjJlNmFkYjYwMDAxYTgxMjFkOll3RWVscjZUNi1NcjJNbk9JOU5WflZ3cjZl
2. Get OAuth2 Access Token for the Client
   Use the value encoded in the previous step to obtain the access token from the token endpoint. Ensure to pass the scope and grant_type values in the payload as mentioned below. The following example shows the token endpoint call using CURL command on shell in mac OS. The same can be done in any programming language of your choice.

The response will look something like this:

Upon successful authentication, the response would contain access_token as highlighted above. The expires_in field contains the lifetime of the token, e.g., 3599 second or about an hour in the example above.

Call JumpCloud API by Sending Access Token in Authorization Header

Using the access token obtained in the previous step, JumpCloud API can be called. It must be passed in the Authorization header with the text “Bearer” prefixed before it as shown below.

FAQ: Service Account with API