-
-
Notifications
You must be signed in to change notification settings - Fork 1.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
oauth2/introspect: make endpoint rfc7662 compatible #289
Comments
RFC6749 is not normative on which method is supported, it just states that some sort of authentication must be done:
We decided to use access token only to reduce the probability of significant CPU drain when validating tokens. I am open to support both though. Nevertheless, this should be documented - ping #287
This is interesting, I remember that this check was required to prevent token substitution attacks, but it does not seem to be in the current RFC any more, so it will be removed with an upcoming patch. |
It appears that the token substitution part has been replaced in favor of:
|
In fact, we could actually remove the |
* warden: make it clear that ladon.Request.Subject is not required or break bc and remove it - closes #270
* warden: make it clear that ladon.Request.Subject is not required or break bc and remove it - closes #270
So has this been changed to allow the token to be able to used to authenticate itself (and return This is quite a common operation for us so we'd like it to be as fast as possible. Currently, we have to get a |
The subject == token.Audience check was removed, apart from that nothing changed, as at_ext was already returned by introspection and RFC7662 requires a separate token:
This will depend on the latency introduced by the store, the operations in hydra take only a few nanoseconds. |
No problem. So any token will be allowed to validate others? On Monday, 10 October 2016, Aeneas notifications@github.com wrote:
|
yes :) |
* warden: make it clear that ladon.Request.Subject is not required or break bc and remove it - closes #270
* oauth2: scopes should be separated by %20 and not +, to ensure javascript compatibility - closes #277 * oauth2/introspect: make endpoint rfc7662 compatible - closes #289 * warden: make it clear that ladon.Request.Subject is not required or break bc and remove it - closes #270 * travis: execute gox build only when new commit is a new tag - closes #285 * docs: improve introduction (#267) * core: (health) monitoring endpoint - closes #216 * oauth2/introspect: make endpoint rfc7662 compatible - closes #289 * connections: remove connections API - closes #265 * oauth2: token revocation endpoint - closes #233 * vendor: update to fosite 0.5.0 * core: add sql support #292 * connections: remove connections API - closes #265 * all: coverage report is missing covered lines of nested packages - closes #296 * cmd: prettify the `hydra token user` output - closes #281 * travis: make it possible for travis-ci to build forked repos - closes #295
/oauth2/introspect
endpoint requires a valid client's client_credentials token to validate other access_tokens.There seems to be a check in the endpoint that the client's
sub
must equal the access token'saud
.Also don't seem to be able to use basic digest authentication of a client's key/secret during these requests, only a valid client token.
I thought the point of this endpoint was to be able to just pass the access token as the Bearer and have it validate and return itself.
The text was updated successfully, but these errors were encountered: