Connection to Autodesk account request when using inhouse Tools

Hey everyone,

In order to get all information needed for our production management, we established connection between our inhouse tools to Shotgrid.
We dispose of a launcher that allows our users to open and browse any tool or project. To authenticate our users we use GUI, either custom made or the one from the Python API. This means that our users enter their credentials twice :

  • When they connect to their Microsoft account
  • When they acutally connect to Shotgrid using these GUIs

From what we were told, these two steps could be reduced to a single one using the SSO. As we undesrtood it, the SSO would create in the Active Directory a Shotgrid authentication token when they connect to their Microsoft account. We would then reuse this token to connect them to Shotgrid in our tools without the need to use any additional GUI. This would mean a substantial amount of time saved for all of our users if possible.

Please, let me know if this rings a bell to any of you.



Hi @SarahEA

I assume that your context is one where your ShotGrid instance is hosted (not running on your own infrastructure) and that you site is using Autodesk Identity for authentication.

A few key points:

  • ShotGrid does not connect directly to your SSO system.
  • ShotGrid only connects to Autodesk Identity, which in turn connect to your SSO system. That is a premium feature which your studio needs to have, and it needs to be already setup.
  • Autodesk Identity authentication can only happen in a web browser.
  • When using SSO with Autodesk Identity, users are often already connected to another service and have already authenticated with SSO. When visiting ShotGrid and ‘logging in’, the user is redirected to Autodesk Identity, where the user must enter their email. Following that, based on the domain of the email entered, the user may be directed to the SSO system. If they have authenticated to it before, they will simply be redirected back to ShotGrid without being prompted for credentials.

So, my question to you:

  • does your launcher bundles the necessary components for the user to authenticate in a Web Browser-like environment ? (like Qt, or other OS-specific packages) ?

(You mention ‘open and browse’, but I do not take that as meaning that this is done in a Web Browser.)

The way RV, Create and ShotGrid desktop operate:

  • connect to the site with a Qt WebEngineView at /auth/renew on the site
  • keep track of which pages are being loaded
  • if coming up on /auth/landing then the WebView is closed as this means a successful authentication
  • the session id is fetched from the CookieJar
  • an API connection to ShotGrid is initiated with that session id

I believe that your custom launcher will need to operate in this fashion.

There are other alternatives, which are more complex or with a less satisfactory UX.

Hoping this helps,


1 Like


My name’s Alex, I’m Sarah’s colleague and in charge of handling shotgrid-related tech.

I assume that your context is one where your ShotGrid instance is hosted (not running on your own infrastructure) and that you site is using Autodesk Identity for authentication.

You assume right ! Thanks for the clarifications.

Our main issue with what you described here is the dependency to a Web Browser. While we are indeed using Qt we would prefer not to integrate a WebView in our tools.

Our main goal is to prevent our users to authenticate multiple times when we already have a way to recognize them in our tools. But from what I understand, even with SSO/Autodesk ID, we would need to provide a GUI to our users (a WebView) and ask them their email adress at the very least.

Is there no way to provide Autodesk ID with the user’s email directly for example ? We already know the email or the user in our tools, we could provide it by script (directly in REST maybe) instead of prompting the user for it.

Thanks for the quick response and your time !


Hi @EpicMinimata

There are 2 things possible. Assuming that your ShotGrid site url is :

One alternate solution that I see : leverage the fact that you can ascertain the identity of your users from your tool and setup a session service on a server you control:

  • create a Script Key with Admin rights
  • when an App user request a session from your service, validate their identity and that they have a ShotGrid user on the site
  • with the Script credentials, connect to ShotGrid using the sudo_as_login parameter with the target user and then use get_session_token() to get a token to give back to the requesting App
  • from the App, use that session ID to initiate a ShotGrid session (with the session_token param of the Python API, or with the session_token grant type in the ShotGrid REST API)

With that alternative, you do not need to integrate with QtWebEngine (unless you really want to).

But this relies on your service being able to ensure that connecting users are who they say they are. The burden of security then rest totally on this.

Hoping that helps




Your alternate solution seems to work really well for our case, thanks !

I noticed however that for some users that haven’t been connected to ShotGrid recently it could raise an error when trying to recover the session token. When manually connecting to ShotGrid through their Web browser, the user was prompted for their password and for a code sent to their phone number.

In the site preferences of ShotGrid, the User Session expiry is set to 1 week but I noticed that I could still connect a user with your script method even if they have not connected for more than a week. Actually, the threshold at which the authentication error is raised when getting the session token seems to be set at around a month.

It’s not really an issue for us if a user has to authenticate this way once after a long break. However we do need to know something: if a user connects regularly to ShotGrid using the method you describe, will they need to reconnect to ShotGrid with the two step verification process every month ? Or is the token refreshed and the session preserved as long as the user connects more than once a month to ShotGrid ?

Also, does this method rely on the “Legacy Login and Personal Access Token” where a token needs to be bound to the user ?

Thank you for your quick and relevant help anyway ! It really helps us a ton.


Hi @EpicMinimata

First if I may, I would like to explain the way the Session Expiry setting works.

A session is considered expired if its last update was more than 1 hour/day/week in the past (depending on your security setting). Every time you interact with ShotGrid, the session is updated. Thus the session’s expiration gets pushed back as the user interacts with the software.

When accessing ShotGrid with a session generated from the API, they way I described, those session are subject to the session expiration setting.

Sessions in a web browser, initiated by logging into Autodesk Identity, have a lifetime that is a bit different. In that case, it is the Autodesk Identity session duration which is in play (based on the cookies left in your browser). These sessions are good for 13 days. So if ShotGrid redirects the user back to Identity to validate their session, they will need to re-authenticate.

As for the 2FA token requested with the API connection… This is a setting that is specific to ShotGrid’s authentication, and totally disconnected from Autodesk Identity. You can enable/disable this in the Site Preferences -> Security settings. If you are able to securely identify the user requesting a new session, then the 2FA may be unnecessary. But that is your call to make, based on your security requirements.

I believe that prior to the transition to Autodesk Identity, your site was enforcing 2FA for ShotGrid-based authentication in the browser (and API). With the transition to Identity, that security requirement has been kept for the API access.

So to answer your questions:

  • 1 interaction per week (based on your Session Duration settings) will keep the session alive. But please be aware that there are times where a ShotGrid update will have to invalidate all existing sessions. So re-authentication will be needed then.
  • yes, setting up a Personal Access Token will be required for every user connecting in this way. This is something that can only be done by the users themselves. It cannot be batched or done by someone else.

Hopefully this answers your questions,


1 Like


Thanks for the detailed explanation.

We should have enough material to take an informed decision on how we want to proceed with these matters. We’ll dicuss it thoroughly between us after the holidays and come back to you if we have any question or issue.

Thank you very, very much for your help and happy holidays.