Skip to content
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

Modification of content type by attached JWS signature method #109

Closed
jricher opened this issue Nov 13, 2020 · 4 comments
Closed

Modification of content type by attached JWS signature method #109

jricher opened this issue Nov 13, 2020 · 4 comments
Labels
Pending Close Issue will be closed unless there are changes to consensus

Comments

@jricher
Copy link
Collaborator

jricher commented Nov 13, 2020

§8.2 Attached JWS: Editor's note:

A downside to this method is that it requires the content type to be something other than application/json, and it doesn't work against an RS without additional profiling since it takes over the request body - plus we have to specify different delivery locations for a GET vs. a POST, for example. Additionally it is potentially fragile like a detached JWS since a multi-tier system could parse the payload and pass the parsed payload downstream with potential transformations. We might want to remove this in favor of general-purpose HTTP signing, or at least provide guidance on its use.

@davidgtonge
Copy link

I would agree with removing this. Although conceptually simpler this breaks the key benefit of RESTful JSON APIs of over the wire readability. In practice this has been a big benefit to developer experience and debugging.

@yaronf
Copy link
Contributor

yaronf commented Nov 16, 2020

I think it's early for the beauty contest among signature methods, so let's not prune the list just yet.

Besides, I'm not sure about fragility. I don't think there's any system that will try to decode and mangle the base64-encoded JWS.

There are good reasons why "attached JWS" is not best for the RC-RS API, but it's actually very useful for RC-AS.

@jricher
Copy link
Collaborator Author

jricher commented Nov 16, 2020

My own implementation of this method has to pre-decode the JWS payload in a filter in order to present the application with something that it can parse into objects to present to the controllers. It also keeps the "raw" version around for the signature validation code to be able to work with, but for this stack it means basically keeping two full copies of the request around in order to check the signature later. It's doable, but I can attest that it's awkward.

https://github.com/bspk/oauth.xyz-java/blob/master/src/main/java/io/bspk/oauth/xyz/http/JoseUnwrappingFilter.java

This issue isn't present if you're doing the parsing at a late stage, for example doing it by hand within the controller.

@jricher
Copy link
Collaborator Author

jricher commented Dec 15, 2021

This is a known issue that is discussed in the text, and it is intrinsic to the method.

@jricher jricher added the Pending Close Issue will be closed unless there are changes to consensus label Dec 15, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Pending Close Issue will be closed unless there are changes to consensus
Projects
None yet
Development

No branches or pull requests

4 participants