500 error when refreshing OAuth token after credential scopes change

[njhale]

Problem

After the scopes of an OAuth credential tool change, the respective existing OAuth credentials return a 500 on refresh.

Reproduction Steps (local Obot setup)

1. Generate an OAuth credential; authenticate an agent or thread for a tool requiring an OAuth credential (e.g. Google Docs tools)
2. Update the respective credential tool definition to either remove or add a scope; e.g. remove the Google OAuth Credential's documents scope
3. Update the tool definitions to point at the updated tool definitions (see Developing Obot Tools for details on pointing your local obot server at a modified local fork of the tool index repo)
4. Wait for the token refresh to occur; For Google OAuth Token this is 1 hour since the token was last refreshed
5. Send a message in the UI to the agent/thread with the credential created with the old scopes. This should produce a 500 error similar to the one in the screenshot above

Possible Solution

A) When the scopes on an OAuth credential tool changes, existing credentials generated by the tool should be automatically deleted to force re-authentication. This approach is likely the simplest, but doesn't give users and admins a chance to evaluate their options; e.g. A scope changes on a pre-authenticated agent, the credential is automatically deleted, and a user (not an admin) gets a prompt to authenticate when the admin only intended for the agent to be used with specific oauth credentials.

B) When the scopes on an OAuth credential tool changes, existing credentials generated by the tool can be flagged and prevent chatting with the agent or using the tool until the existing credential is manually and re-authenticated. This approach gives deleted and notify users and admins that re-authentication is required. This puts more friction in the path and lets users and admins understand why they're being asked to re-authenticate; it may also pair well with the ability to disable thread-level authentication so admins can avoid the scenario outlined in option A.

[cjellick]

Hm. Yeah, this could be particularly tricky with agent level creds. Id probably be ok if we just invalidated thread-level creds, but that would be harder/more awkward UX for agent level crds.

[cjellick]

@njhale does this apply to other tools or just google?

[njhale]

I've only seen it happen with Google, but could be an issue with others as well. I can check if I can trigger with another OAuth app provider in a bit