Implements Nested JWT functionality as defined in RFC 7519 Section 5.2, 7.1, 7.2, and Appendix A.2.#712
Implements Nested JWT functionality as defined in RFC 7519 Section 5.2, 7.1, 7.2, and Appendix A.2.#712
Conversation
ydah
force-pushed
the
nested-jwt
branch
4 times, most recently
from
b43c683 to
62bbb58
Compare
…2, 7.1, 7.2, and Appendix A.2. Implements Nested JWT functionality as defined in RFC 7519 Section 5.2, 7.1, 7.2, and Appendix A.2. A Nested JWT is a JWT used as the payload of another JWT, allowing multiple layers of signing with different keys/algorithms.
ydah
changed the title
|
Thanks for the addition @ydah, looks interesting. I need to take a look at this with a fresh mind. But its on my todo list. |
| # encoded_token.verify_signature!(algorithm: 'HS256', key: 'secret') | ||
| # encoded_token.payload # => {'pay' => 'load'} | ||
| class EncodedToken | ||
| class EncodedToken # rubocop:disable Metrics/ClassLength |
There was a problem hiding this comment.
Could we do the refactoring sketched out in #713 in a separate PR to deal with the class length?
| tokens = [self] | ||
| current = self | ||
|
|
||
| while current.nested? |
There was a problem hiding this comment.
Should we limit the depth of the nesting to for example 10? There could be some security issue with having no limit.
| # @return [String] the JWT token as a string. | ||
| alias to_s jwt | ||
|
|
||
| class << self |
There was a problem hiding this comment.
Would be easier to follow if there would be only one way to create these for now. Fancying smaller iterations over different variations how to do things.
| # The content type header value for nested JWTs as per RFC 7519 | ||
| CTY_JWT = 'JWT' | ||
|
|
||
| class << self |
There was a problem hiding this comment.
Could we represent such a NestedToken as an instance instead of having static methods doing everything (signing, claim/signature, verification)?
Now for example there is no way to control what claims are being verified.
| # ) | ||
| def sign(inner_jwt, algorithm:, key:, header: {}) | ||
| outer_header = header.merge('cty' => CTY_JWT) | ||
| token = Token.new(payload: inner_jwt, header: outer_header) |
There was a problem hiding this comment.
Think we will be creating invalid tokens this way, as Token is always doing the JSON encoding on the payload. To my understanding the nested tokens should only be base64 encoded.
2 participants
Description
Implements Nested JWT functionality as defined in RFC 7519 Section 5.2, 7.1, 7.2, and Appendix A.2.
A Nested JWT is a JWT used as the payload of another JWT, allowing multiple layers of signing with different keys/algorithms.
see: https://datatracker.ietf.org/doc/html/rfc7519#section-5.2
see: https://datatracker.ietf.org/doc/html/rfc7519#section-7.1
see: https://datatracker.ietf.org/doc/html/rfc7519#section-7.2
Checklist
Before the PR can be merged be sure the following are checked: