OAuth with REST API for non-MCP use cases
Wats currently has closed-beta OAuth support, as part of the McpOAuthProtocol category in it's API, to allow AI harnesses to authenticate and interact with the Wats API.
We asked Wats support for enabling the use of OAuth to access the REST API, but were told to post here to gauge interest before that work will be prioritized.
We would like to use OAuth with the REST API for normal test-operation for two reasons:
- The current Wats Desktop Client is Windows only, and uses the Wats Standard Text Format, which does not have any broad ecosystem support compared to JSON. The .NET data-objects also colors your internal program logic to be inherently Windows exclusive, creating Windows vendor lock-in.
- The alternative to the Wats Client, the REST API which supports JSON, currently requires headless tokens which are not account specific. Any one token is not connected to any one account, making it impossible to audit usage of the token. If you need operator authentication per test-step, you're relying on good-faith textual inputs, instead of proper authentication. (One work-around is to create a headless token per user, and manually distribute and keep track of these tokens, but this is needlessly complex and much less secure)
The workflow would be:
- Our test program directs operators to the WATS login page
- Test operators use SSO to sign-in
- The test program exchanges the authorization code for an access token/refresh token pair
- The test program can now retrieve and upload test reports using the REST API on a per-user, per-session basis
Pros:
- The test program can be perfectly cross-platform, relying only on JSON (de)serialization
- There is no manual token handling / distributing
- Audit logs can record user-level access, instead of token-level access.
If your team would benefit from the same use-cases related to OAuth, please vote on this idea so work on it can be prioritized by Virinco.
Please sign in to leave a comment.
Comments
0 comments