Pedantic stuff about go-jwt-middleware

[mgonto]

I've implemented the first and the last in #3. However, I note that RFC 6750 specifically talks about some header manipulations that SHOULD be performed in the case of query string parameters. That isn't currently done by this middleware but we should probably consider adding it. The main issue here is "leaking" tokens via caching.

I don't see anywhere that it says anything about header manipulation when using Query String params. Where did you read about that?

I was reading RFC 6750. In researching #2, I wanted to look at the formal specification for how OAuth tokens should be handled. It mentions three schemes: Authorization header, form fields and query string parameters.

Almost nobody is using the Form Fields for authentication. Mostly all do Request Parameter or Header, so I think we're OK with those 2 at first :). What do you think?

Although RFC 6750 is for OAuth, I think almost all of the practical details (especially around security) apply for JWTs as well.

I agree that using the OAuth spec makes sense :)

[xogeny]

The issue is with caching headers:

Clients using the URI Query Parameter method SHOULD also send a Cache-Control header containing the "no-store" option. Server success (2XX status) responses to these requests SHOULD contain a Cache-Control header with the "private" option.

I'm not worried about the form field stuff because, with the new approach, someone could implement that pretty easily. We don't need to implement everything. We just need to implement the hooks to allow everything.

[mgonto]

Agreed on the second one.

I don't think the cache-control will be a problem by the way.

Thanks for the PR. Closing this one then !