Use Autodesk Identity Session Token in my webapp?

We have a webapp that uses a Script and API Key with the ShotGrid Python API to the lead the user through workflows like creating a Cut.

Ideally, though, we’d like to use Autodesk Identity/ShotGrid user authentication in our webapp, so that we have the correct user in the created_by fields, better Event Logs, enforced ShotGrid permissions and so on.

Having read this comment…

…is it possible to access the Session Token generated by the Autodesk Identity workflow in my webapp in the same browser?

Thanks!

1 Like

Hi @JoshBurnell

Script and API keys are meant for background/infrastructure processes and NOT for regular interactive work as a user. Creating a key per user is a pain in the neck, and because the permission groups for users and scripts are not the same, it is a lot of trouble to create new ones and maintain synchronization between the corresponding user and script permission groups.

At this time, ShotGrid’s integration with Autodesk Identity is such that the access token and refresh tokens are kept in the ShotGrid’s user profile and not exposed to the browser client.

There is some work underway so that you could use any valid Autodesk Identity access token to talk to ShotGrid with the REST/Python APIs, but this is still work in progress and not available to clients.

I strongly suggest that you move away from using a Script and API key in your web app.

Instead, have users create a Personal Access Token and save it to their ShotGrid user. And then use the legacy username and passphrase to authenticate with ShotGrid using the REST Api.

For security reasons, you should not persist the user’s name and passphrase across sessions of your web app, or serialize the ShotGrid access and refresh tokens. In fact, once the user has logged-in, you only need to keep the access and refresh tokens in memory.

Once the possibility of using an Autodesk Identity access token to talk to ShotGrid directly becomes available, then you just need to create your own personal Autodesk Platform Services App and use that to implement your own sign-in process. I strongly suggest looking at the PKCE version of the authentication, so that you do not need to store a secret in your web app.

Hoping this helps,

-Patrick

Thanks, Patrick. You’re actually describing what we do now, using the legacy username and passphrase system. However, since the migration to Autodesk Identity, we’ve found this process very confusing for users and hard to support.

The move to using a Script with API Key, as described in my first post, is what I’m planning to move the webapp to, because users have become so frustrated.

Thanks for your help and I look forward to being able to use the Autodesk Identity access token when it is ready.

Hi @JoshBurnell

There is actually another option… Which puts the burden of security on your shoulders and requires having a secure server at your disposal. Let’s call it “the identity broker” pattern.

Off the top of my head, here is the recipe…

This will require:

  1. on your ShotGrid site, create a new Script / API Key, to be used to issue ShotGrid session IDs to your users.
  2. on your secure server, you will need a table of correspondance between your ShotGrid user emails and their ShotGrid usernames

The workflow:

  1. implement Autodesk Identity authentication on your secure server. Add the openid scope in your authorize call to avoid having to do a separate call to Autodesk Identity to get the user’s profile.
  2. on your server, when processing the callback and the code exchange, you can use the open-id payload to get the user’s email.
  3. using your correspondance table, find a) if the user exists on your ShotGrid site, and b) what is their username.
  4. have your server make a call to ShotGrid using the Script Name/API, using the sudo_as_login field and generate a session_id for that user.
  5. send back the session_id to the end-user, who can now created a direct connection to the ShotGrid site with the REST API.

That is a quick-and-dirty brain dump… there are likely pitfalls and security gotchas here, but that is the gist of it.

-Patrick

1 Like