API Basics

Autodesk Platform Services (APS) typically require users to sign in and grant permission when applications need to access their resources. However, server-to-server applications operate without user interaction (“headless”) and cannot prompt for credentials. Secure Service Accounts (SSAs) solve this challenge by providing a secure authentication mechanism specifically designed for these headless scenarios, ensuring seamless and secure access to resources without manual intervention.

The Secure Service Account API lets you create up to 10 Secure Service Accounts for each server-to-server application. Each SSA receives:

• A unique identifier
• A dedicated email address

Using administrative consoles in Autodesk services like BIM 360, Autodesk Construction Cloud, and Fusion Teams, administrators can assign specific permissions to the SSA email addresses. This permission assignment grants your server-to-server application the same access privileges that an actual user would have. The level of granularity depends on what the service’s permission model supports.

Assigning access privileges alone does not allow a headless application to access secured resources. The application needs to send a valid three-legged access token with each request to authenticate its identity.

To obtain this access token, the server-to-server application must first obtain a private key for the SSA by calling the Create Keys operation. This private key is displayed only once and must be stored securely. It is the foundation of the security model. Anyone possessing this key can potentially generate tokens with the same permissions as your secure service account. We recommend that you use secure key management services appropriate for your hosting environment.

Once you obtain the private key you must use it to generate a JSON Web Token (JWT) assertion. See JWT Assertions for more information. After that you can use the Exchange JWT Assertion for Token operation to exchange the JWT assertion for a three-legged access token. This token grants the server-to-server application the permission to access the resources allowed for that SSA.

In the absence of SSAs, the industry has used a technique known as “User Impersonation”. Secure Service Accounts (SSAs) are considered to be safer than user impersonation for several reasons:

• Dedicated Authentication Mechanism: SSAs use a dedicated authentication mechanism. This mechanism is designed specifically for headless server-to-server interactions. The method helps avoid risks associated with user credentials being exposed or misused.
• Granular Permissions: SSAs allow administrators to assign specific permissions to the SSA email addresses. This means the permissions can be tailored precisely to what the server-to-server application needs, minimizing the risk of over-privileged access, which is common in user impersonation scenarios.
• Token-Based Authentication: SSAs use token-based authentication rather than relying on user credentials. Tokens are typically short-lived and can be easily revoked, reducing the risk associated with long-term credential exposure.
• Private Key Security: The security model for SSAs relies on a private key that is generated and stored securely. This key is the foundation of the authentication process, and the use of secure key management services helps protect it. In contrast, user impersonation often involves storing and managing user passwords, which can be more vulnerable to exposure and attacks.
• Isolation of Service Accounts: SSAs are isolated from regular user accounts, meaning they are not tied to any individual’s credentials. This reduces the risk of unauthorized access due to compromised user accounts and ensures that service accounts can be managed independently of user accounts.
• Auditability and Monitoring: Activities performed by SSAs can be more easily monitored and audited compared to user impersonation. Since SSAs are dedicated accounts, their actions can be tracked separately, providing better visibility into server-to-server interactions.
• Compliance and Best Practices: Using SSAs aligns with industry best practices for secure authentication and compliance requirements. It reduces the risk of violating policies related to user credential management and ensures that server-to-server interactions adhere to security standards.

Secure Service Accounts provide a robust and secure solution for server-to-server authentication, particularly in headless scenarios where user interaction is not possible. With the Secure Service Account API, you have all the tools required to manage Secure Service Accounts and their associated private keys. This ensures secure access to resources for server-to-server applications, offering advantages such as enhanced security, granular permissions, token-based authentication, isolation of service accounts, and improved auditability.