OAuth introspect endpoint works only with the credentials of the creator of the access token being verified
-
If you call the access token verification endpoint (https://fusionauth.io/docs/lifecycle/authenticate-users/oauth/endpoints#introspect), it responds successfully if you include as credentials the client id and client secret of the Entity that requested that access token from FusionAuth originally.
If you instead try to verify the token with another Entity's client id and client secret, you receive a 401 error (unauthorized).
But the whole point of having a verification endpoint is for a server to validate the token received from a client - and the server obviously won't have the client's secret. Since the server doesn't have the client secret, how is it supposed to validate a token using any secret other than the server's own secret? Is this an error in the permissions of the endpoint of FusionAuth? Otherwise I don't understand how a server can call this endpoint.
Thanks.
-
Also, why doesn't FusionAuth expose the default signing key, HS256, at http://localhost:9011/.well-known/jwks.json?
Because it doesn't, you haven't to change all machine oauth to use a custom key, otherwise access tokens can't be verified manually, in addition to not being verifiable using the introspection endpoint.
-
Also, why doesn't FusionAuth expose the default signing key, HS256, at http://localhost:9011/.well-known/jwks.json?
@fusionauth-qhj5e We don't publish the HMAC key to JWKS.json because if we did, anyone would be able to find it, and sign JWTs as your FusionAuth installation. HMAC keys should only be used when both parties can share a secret.
I'll update the docs to make that clearer. Sorry!
https://fusionauth.io/docs/lifecycle/authenticate-users/oauth/endpoints#json-web-key-set-jwks
-
Here's the PR making the doc better: