Authentication
Ideally, your app should only use 3-legged authentication to access data and perform operations, to ensure that proper permission privileges are in place.
In some situations the app needs to use 2-legged tokens, for example when using the Data Management API to access files. We recommend that 2-legged authentication should NOT be used when there are users involved, reserving this approach for account level data exchange. If this is a must, then use a ‘user impersonation’ header (x-user-id) in order to limit the call to only act on behalf of the specified user.
Sometimes the app needs to use 2-legged tokens and is unable to utilize ‘user impersonation’. For example, when using the BIM 360 Account Administrator endpoints. In this case, the application is responsible for ensuring the operations are performed on the correct account.
Provisioning
Multiple BIM 360 accounts can provision the same 3rd party app, which could potentially enable a malicious user to use someone else’s account ID. We recommend using the following solution, which prevents the end user from manually entering any BIM 360 account ID.
Call the GET hubs endpoint in the Data Management API using a 3-legged token to retrieve all the accounts the user has access to. Note that Data Management hubs correspond to BIM 360 accounts. You need to filter the response to only return BIM 360 accounts (filter[extension.type]= hubs:autodesk.bim360:Account). You can limit the user to only access the accounts that were retrieved in the response.
Testing for Data Leaks
Consider testing your app with at least two different BIM 360 accounts to ensure that unauthorized users are unable to access account information, data, or files. For example, check whether different users are able to read files from different accounts.
Token Security
Do not store 2-legged or refresh tokens locally on the client side. The 2-legged token can be used to perform any operation on any account where the respective app is provisioned. Similarly, we do not recommend that you store 3-legged tokens on the client side.
We recommend that you get access tokens with the minimum scopes required for the endpoint calls. For example, if your app only needs to read information, you should only use the data:read scope. This will also reduce the list of permissions on the OAuth consent page.
For the Viewer we recommend that you protect your source data by using the viewables:read scope that limits the app to only read the user’s viewable data. Ideally, your application should use a proxy server and makes server to server calls to Forge. See the following articles for more information: NodeJS and .NET.