The Antithesis API will be supporting oauth authentication soon which will allow Snouty to negotiate for a access token using interactive user auth to their IDP.
This flow is still being tuned down, but it currently has the following high-level phases:
- spin up a short lived web server on a localhost port to receive the callback
- send a auth flow start request to antithesis
- receive a IDP url
- open IDP url in browser, ask user to login
- IDP redirects back to the localhost webserver with auth+refresh tokens from idp
- exchange IDP auth token for antithesis token
- store idp refresh token + antithesis token and use for api requests
- refresh antithesis token as needed
Something to keep in mind in Snouty is where we will store the antithesis token + refresh token on the user's machine. Ideally there is an existing pattern and crate that helps us use any available keychains before falling back to storing the tokens in some kind of credentials file. We should make sure this pattern also works for the snouty api key.
Separately, we should add a snouty setup flow which kicks off on first use, similar to Claude that establishes auth in an interactive TUI with the user.
The Antithesis API will be supporting oauth authentication soon which will allow Snouty to negotiate for a access token using interactive user auth to their IDP.
This flow is still being tuned down, but it currently has the following high-level phases:
Something to keep in mind in Snouty is where we will store the antithesis token + refresh token on the user's machine. Ideally there is an existing pattern and crate that helps us use any available keychains before falling back to storing the tokens in some kind of credentials file. We should make sure this pattern also works for the snouty api key.
Separately, we should add a snouty setup flow which kicks off on first use, similar to Claude that establishes auth in an interactive TUI with the user.