I've been trying to use TSIDP as an auth provider for MCP toolbox for databases however i've come up against 2 issues,
- Is caused by the fact that the access token is opaque and not jwt. MCP toolbox validates this on a different path which drops all of the claims which doesn't let me use for example a sub claim as a userid.
- Is caused by the fact that custom scopes that have been set in tailscale ACL only appear in the ID token and not the access token, and MCP toolbox only seems to read the access token.
This is a bit of a double whammy for our usecase, we can't put tools behind an auth scope because our custom scopes aren't appearing in the access token, and we can't have parameters derived from the token being injected into tools because they get dropped for opaque tokens.
I've put together a PR for custom scopes which is here: #176
it allows the user to specify which additional scopes they would like to advertise, and if the id token has those particular scopes they get added to the access token.
This works for our usecase, but might need to be refined, I'm happy to do refine it further.
I'm currently working on a PR to optionally allow access tokens to be returned as JWT. Again, this would help our usecase, but might not be suitable for the wider project
I've been trying to use TSIDP as an auth provider for MCP toolbox for databases however i've come up against 2 issues,
This is a bit of a double whammy for our usecase, we can't put tools behind an auth scope because our custom scopes aren't appearing in the access token, and we can't have parameters derived from the token being injected into tools because they get dropped for opaque tokens.
I've put together a PR for custom scopes which is here: #176
it allows the user to specify which additional scopes they would like to advertise, and if the id token has those particular scopes they get added to the access token.
This works for our usecase, but might need to be refined, I'm happy to do refine it further.
I'm currently working on a PR to optionally allow access tokens to be returned as JWT. Again, this would help our usecase, but might not be suitable for the wider project