Add support for RFC7797 unencoded payloads #561
Conversation
adds `encode_detached` to JWT, which produces a jwt with an empty payload segment adds support for the `b64` header, which when set to false will prevent the payload from being base64 encoded adds support for decoding JWTs with the `b64` header set to false adds support for decoding and verifying JWTs with detached payloads
| @@ -22,7 +22,16 @@ def encode(payload, key, algorithm = 'HS256', header_fields = {}) | |||
| Encode.new(payload: payload, | |||
| key: key, | |||
| algorithm: algorithm, | |||
| headers: header_fields).segments | |||
| headers: header_fields, | |||
| detached: false).segments | |||
There was a problem hiding this comment.
Maybe we can set detached as default false
| @@ -15,11 +15,24 @@ def initialize(options) | |||
| @algorithm = resolve_algorithm(options[:algorithm]) | |||
| @headers = options[:headers].transform_keys(&:to_s) | |||
| @headers[ALG_KEY] = @algorithm.alg | |||
| @detached = options[:detached] | |||
There was a problem hiding this comment.
Here we can set as default false
@detached = options[:detached] || false
| def parse_and_decode(segment, decode: true) | ||
| if decode | ||
| JWT::JSON.parse(::JWT::Base64.url_decode(segment)) | ||
| else |
There was a problem hiding this comment.
We can avoid else statement with a guard clause.
|
Hi guys, this feature is quite common, will be good to have this supported. |
Thanks for you suggestions. I will try to find time to push up some updates soon. |
| end | ||
|
|
||
| def decode_payload? | ||
| header['b64'].nil? || !!header['b64'] |
There was a problem hiding this comment.
I wonder if this is a bit problematic to change behavior because of user-input. Would it be too much of an inconvenience to have the caller decide to decode or not?
| end | ||
|
|
||
| def parse_and_decode(segment) | ||
| JWT::JSON.parse(::JWT::Base64.url_decode(segment)) | ||
| def parse_and_decode(segment, decode: true) |
There was a problem hiding this comment.
Would it be possible to avoid the parameter if the caller would just call parse and decode in separate?
| end | ||
|
|
||
| def encoded_payload | ||
| payload = encoded_detached_payload if !@detached_payload.nil? && @segments[1].empty? |
There was a problem hiding this comment.
I think it would make sense to raise an error if a payload is given and the token also contains a payload, instead of just ignoring the given payload.
| @@ -51,7 +64,21 @@ def encode_header | |||
| end | |||
|
|
|||
| def encode_payload | |||
| encode_data(@payload) | |||
| # if b64 header is present and false, do not encode payload as per RFC7797 proposed standard | |||
There was a problem hiding this comment.
Would it make sense to not rely on header values but instead have an explicit parameter that controls the behavior of both header values and payload encoding?
| Unencoded and detached payloads are often used hand in hand, such as in proof signatures of Verifiable Credentials. You may use the `b64` header in combination with `encode_detached` to combine both features. | ||
|
|
||
| ```ruby | ||
| private_key = RbNaCl::Signatures::Ed25519::SigningKey.new('abcdefghijklmnopqrstuvwxyzABCDEF') |
There was a problem hiding this comment.
The example could be a more simple one than one that required the rbnacl dependency.
This adds support for RFC7797 and addresses #309
Here is the specification: https://www.rfc-editor.org/rfc/rfc7797
Happy to receive feedback and would love to get this released soon as I need it for my current project.