The Forge documentation mentions “If you need an end user to authorize your app to act on the user’s behalf, you’ll want to check out this tutorial.” This makes it sound as if our app will be doing something from OurApp → Forge, reaching into Fusion data, pulling it out. Our desired action would be the user acting on their own behalf, with authorized permission, sending files to their account on OurApp.
I've genericized it, but our specific situation is as follows: we want Fusion360 users to be able to install our plugin and then send models in STL format (model derivative v2 API) to our service for 3D Printing or sharing with others. This same behavior exists for Tinkercad and is very popular, but the requirements change for Fusion, now that it is not a web app like Tinkercad.
Autodesk Forge uses OAuth 2.0 as its authentication strategy, and as part of that, the platform allows you to choose between two-legged and three-legged authentication.
Two-legged authentication means that a trust is established between your own application (with credentials that are generated for you when you create a Forge app on https://forge.autodesk.com) and the Forge services. Your application can manage its own data but it does not have access to your users data in other Forge applications.
Three-legged authentication means that a trust is established among 3 entities: your application, Forge, and your user. With an access token generated using 3-legged authentication, your application can also access the user's content in other Forge applications, for example, in BIM360 or Fusion Teams.
With that, if you plan on having your users upload STL files from a locally running instance of Fusion 360, you can use the simple 2-legged authentication and have your Forge application own and manage the uploaded data and the translated derivatives. But if you wanted to upload or download STLs to/from something like Fusion Teams, you would need the 3-legged auth workflow.
Related
I'm integrating Autodesk Viewer in an application, and it uses Model Derivative API to translate files, which is a paid service.
Can this integration be restricted to allow access only for users under a organization account? Meaning if a random autodesk account outside the organization tries to use the integration, it will not be allowed.
Presumably you are using 3 legged authentication? As a simple way of filtering out users from outside your organization, once they have authenticated you can get their Autodesk account details https://forge.autodesk.com/en/docs/oauth/v2/reference/http/users-#me-GET/ which includes the email address assigned to their account, and decide from that if they should have access.
This question pertains to the Autodesk Forge TokenFlex Usage API. We would like to run an application that pulls data on a scheduled basis. Our understanding is that the Forge TokenFlex API requires 3 Legged authentication. We have successfully adapted the Autodesk GitHub code sample "A Forge Python Script Demonstrating new TokenFlex Usage API" to pull our data but this requires 3-Legged Authentication.
Is there a way to pull data using the TokenFlex Usage API without requiring user intervention for Authentication?
Unfortunately TokenFlex requires 3 legged auth for enhanced security purposes.
However you can minimize user intervention but rotating the token periodically in your backend using the refresh_token that comes with the token to get refreshed tokens implicitly and store them securely (encryption recommended for security reasons) where your script can use them, see here for details
Since BIM360 allows users to disable 2-factor authentication for themselves one of our clients requires a way to prevent access to files / monitor if users turn this feature off.
For forge-applications managed by me I got this covered through following endpoint :
https://forge.autodesk.com/en/docs/oauth/v2/reference/http/users-#me-GET/
Problem is, users without 2-fa can then still access the files if they go directly through the BIM 360 docs webapp (docs.b360.autodesk.com). Is there a way to restrict acces on the bim360docs platform based solely on 2-fa or a way to use the users-#me endpoint in a way that allows me to monitor a project when those users aren't logging in on my applications?
Sorry, this information is only accessible for the current user (who authorized the 3 legged access token).
I am trying to offer an application which is to allow access to user's private files through proprietary back end and present them in a custom Web UI. What is the mechanism that allows to bridge the Web-based OAuth to the server side Drive access for each user?
EDIT:
To expand on my brief description, I would like to add that the OAuth authentication to receive the Token Response is to happen through the HTTP interaction and be presented to a user in a Web interface and be of 2-legged nature. But then I thought the Token Response would be passed to a Java server (via HTTP headers), which would process the file to be stored in user's Drive after some processing. What is not clear to me is what APIs are used to manipulate the files in Google Drive from the Java server back-end and how the Token Response is passed to those APIs to facilitate OAuth authentication.
Is this even implementable?
I'm the administrator of a Bim360 Docs Hub,and i'm trying to retrieve some data from the forge API. I've already created a test app, and i get a Bim 360 Account Id.
I'm not able to get an authentication bearear token (OAuth), to make simple get requests towards projects.
Where do i get the auth token ?
Thanks
See tutorial here to aquire OAuth tokens and note that you will need different permutations of OAuth scopes (esp. data:read data:write etc.) for different operations, as is specified in the docs of each and every API, see an example here.
You may use a RESTful client like Postman to talk to our APIs and manage the authentication flow and operate on response data with JavaScript as you like so as to build workflows such as to create a new project.
Last but not least before you can access BIM360 APIs make sure you provision access to your app.