Description
Describe the bug
In VS Code, we have our own handling of OAuth (client side) so we can tie it in with VS Code's existing auth stack... one of the things I'm wrestling with is the in-memory example... specifically, this idea that the server only has client ids in-memory.
In VS Code, we persist the client id so that we're not spamming the heck out of the provider... but invalidating that client id is tricky. How does the client know when the client id is invalid? Well if the client id doesn't exist anymore, OAuth says an error invalid_client
should be returned... but:
- The sdk has the auth flow just emit to the page
{"error":"invalid_client","error_description":"Invalid client_id"}
(because it throws) (or maybe it's this code) rather than sending the error along to theredirect_uri
, so we can't get it this way - the example doesn't implement refresh token handling so the error won't be surfaced there either (although admittedly the error would be surfaced here in normal circumstances
I'm trying to avoid upfront client id validation, because really, the client id should almost always be there (save the extra network call)... but that is currently the most robust solution.
To Reproduce
Steps to reproduce the behavior:
- Start this example:
npx tsx src/examples/server/simpleStreamableHttp.ts --oauth
- Start an auth flow using an invalid client id
- See error only displayed in the browser and not passed along to the client
Expected behavior
The invalid_client error is surfaced to the client, not just the user.
Logs
N/A
Additional context
N/A