-
-
Notifications
You must be signed in to change notification settings - Fork 364
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
fix: rfc9068 must condition ignored in introspection #767
base: master
Are you sure you want to change the base?
fix: rfc9068 must condition ignored in introspection #767
Conversation
Tests are missing. Also, I could not find where in fosite we set type for access tokens to |
I must have missed the tests and the change which makes the JWT Profile default to this |
5be54f6
to
760314f
Compare
This fixes an outstanding TODO where the requirement for a correctly formed RFC9068 access token MUST have the media type of 'application/at+jwt', and that this media type MUST be appropriately reflected in the typ header as either 'at+jwt' (SHOULD), or as the media type itself. See https://datatracker.ietf.org/doc/html/rfc9068#section-2.1 for more information.
760314f
to
cf41b86
Compare
So there is no |
This change doesn't affect that code path, just |
Any thoughts on how to transition this on a live system? There might be a period when old valid access tokens are returned as invalid because they have old (This is not a problem for me, but it might be for other users of fosite.) |
I have made sure the function is exported for this reason. I think from a practical standpoint they should be considered invalid or the implementer should implement their own validator which allows both based on |
This fixes an outstanding TODO where the requirement for a correctly formed RFC9068 access token MUST have the media type of 'application/at+jwt', and that this media type MUST be appropriately reflected in the typ header as either 'at+jwt' (SHOULD), or as the media type itself. See https://datatracker.ietf.org/doc/html/rfc9068#section-2.1 for more information.
Related Issue or Design Document
Checklist
If this pull request addresses a security vulnerability,
I confirm that I got approval (please contact security@ory.sh) from the maintainers to push the changes.
Further comments