Shotgrid Personal Access Token based authentication for backend api endpoints

[Srijan9211]

Summary

Implements ShotGrid PAT (Personal Access Token: https://aps.autodesk.com/blog/understanding-pat-its-benefits-and-how-obtain-pat) based authentication for the DNA backend API. This replaces the previous unauthenticated / Google OAuth flow with a production-ready auth system where users sign in with their ShotGrid username and Legacy Login password.

What changed:

• Backend auth provider (shotgrid_sso.py) — new ShotGridSSOProvider that authenticates against ShotGrid's /api/v1/auth/access_token endpoint using the password grant type, issues a short-lived DNA JWT to the browser, and stores ShotGrid credentials server-side in MongoDB.
• MongoDB session store (session_store.py) — replaces Redis with MongoDB (already used by DNA) for session storage, JWT revocation blocklist, and OAuth state tokens; TTL indexes handle automatic expiry.
• ShotGrid connection pool (connection_pool.py) — thread-safe LRU pool of shotgun_api3 connections keyed by session ID to avoid a new TCP handshake on every API request.
• ShotGrid auth client (shotgrid_auth_client.py) — encapsulates all interactions with ShotGrid's token endpoint (password grant, token refresh, user identity resolution).
• Frontend login page (ShotGridLoginPage.tsx, ShotGridAuthContext.tsx) — new PAT login form (username + password), JWT auto-refresh every 25 minutes, sessionStorage for token persistence scoped to the current tab.
• Removed — Redis dependency, Google OAuth provider, AMI/SSO callback endpoints, google-auth and redis Python packages

Auth flow:

1. Browser POSTs username + password to POST /auth/login
2. Backend exchanges credentials with ShotGrid → receives ShotGrid Bearer token
3. Backend stores session (ShotGrid token + password) in MongoDB, returns a DNA JWT to the browser
4. Every subsequent request: DNA JWT verified → session fetched from MongoDB → ShotGrid API calls run under the user's own token → ShotGrid enforces native project permissions

Cloud ShotGrid requires a Personal Access Token (PAT) bound to the user's account at profile.autodesk.com. On-prem sites work with the actual ShotGrid/LDAP password and no PAT.

Testing

• I have tested these changes locally
• I have run all relevant automated tests
• I have verified this does not break existing workflows
• For changes that can be tested in UI, I have included screenshots or gif animations of the changes.

How I Tested

Generate a PAT at Autodesk:

1. Open your browser and go to: 1. Open your browser and go to:
2. Sign in with your Autodesk account (the same email as your ShotGrid account)
3. Click the Security tab in the left sidebar
4. Find the Personal Access Tokens section → click Generate
5. Fill in:
   • Token name: DNA Tool
   • Application scope: select Flow Production Tracking
6. Click Generate
7. ⚠️ Copy the token code immediately — it is shown only once. If you close this page without copying it, you must generate a new one. Paste it in Notepad temporarily.

Bind the PAT to your ASWF ShotGrid account:

8. Open a new tab and go to: https://aswf.shotgrid.autodesk.com
9. Log in with your Autodesk Identity if not already logged in
10. Click your profile icon in the top-right corner → click Account Settings
11. In the left sidebar click Legacy Login and Personal Access Token
12. Under the Personal Access Token section:
    • Paste the token code you copied in Step 7
    • Click Bind (or Save)
13. You should see the token name, creation date, and status — confirming it is bound

Set your Legacy Login username and password:

14. On the same page (Legacy Login and Personal Access Token), scroll up to the Legacy Login section
15. You will see two fields:
    • Login — this should already be pre-filled with your ShotGrid username (usually your email)
    • Password — this is blank if you have never set it
16. Set a Legacy Login password:
    • Click Change Password or the password field
    • Enter a new password
    • ⚠️ This is NOT your Autodesk account password — it is a separate password just for API access
    • Save it somewhere safe — this is what you type into DNA's login form
17. Click Save

Running Stack and Test:

1. Started the stack in windows machine with
   • Backend:
     • cd dna\backend
     • docker compose -f docker-compose.yml -f docker-compose.vexa.yml -f docker-compose.local.yml -f docker-compose.local.vexa.yml build up --build
   • Frontend:
     • cd dna
     • docker build --build-arg VITE_API_BASE_URL=http://localhost:8000 --build-arg VITE_WS_URL=ws://localhost:8000/ws --build-arg VITE_AUTH_PROVIDER=shotgrid -t dna-frontend frontend/
     • docker run --name dna-frontend -p 8080:8080 -d dna-frontend
2. Opened http://localhost:8080 — confirmed the ShotGrid PAT login form is shown (no Google button, no SSO tab)
3. Entered a valid ShotGrid username and Legacy Login password → confirmed successful login, user name displayed in the app, projects loaded from ShotGrid
4. Entered invalid credentials → confirmed 401 error message is shown in the login form
5. Confirmed GET /auth/me returns { email, name, shotgrid_user_id } with a valid token
6. Confirmed POST /auth/logout clears the session from MongoDB and the browser returns to the login page
7. Confirmed POST /auth/refresh issues a new DNA JWT and rotates the ShotGrid token without requiring re-login
8. Reloaded the page with a valid token in sessionStorage → confirmed the app restores the session without prompting for login again
9. Closed and reopened the browser tab → confirmed sessionStorage is cleared and login is required (token does not persist across tab close)
10. Restarted the backend with an active session → confirmed the app detects the dead session on next page load (401 from /auth/me) and redirects to login

[linux-foundation-easycla]

The committers listed above are authorized under a signed CLA.

• ✅ login: Srijan9211 / name: Srijan9211 (10a9bda, 2f2dd51)

[jspada200]

It is strange the SG needs the password for the legacy flow and we cannot just get a token and use that everywhere. I do see why it is saved here so the user just needs to authenticate once on the FE. That being said it is dangerus to save a password this way and it should be encrypted. I want to bring in @loorthu to help review this and maybe suggest other ways to handling it so we do not need to store the password at all.