passport-http-bearer icon indicating copy to clipboard operation
passport-http-bearer copied to clipboard

Token from the request body should force 'application/x-www-form-urlencoded'

Open raymondsze opened this issue 7 years ago • 1 comments

https://tools.ietf.org/html/rfc6750#section-2.2

2.2. Form-Encoded Body Parameter

When sending the access token in the HTTP request entity-body, the client adds the access token to the request-body using the "access_token" parameter. The client MUST NOT use this method unless all of the following conditions are met:

o The HTTP request entity-header includes the "Content-Type" header field set to "application/x-www-form-urlencoded".

o The entity-body follows the encoding requirements of the "application/x-www-form-urlencoded" content-type as defined by HTML 4.01 [W3C.REC-html401-19991224].

o The HTTP request entity-body is single-part.

According to RFC6750, if the access token is sent via the entity body, seems content-type have to be checked equal to application/x-www-form-urlencoded, is this intended for this library?

raymondsze avatar Dec 23 '16 16:12 raymondsze

As far as I understand this library, it is only concerned with the server part, where as the cited rule is one that clients have to obey. The first thing that came to my mind is that with these requirements, you can't easily put the bearer token in a form with a file upload. I'd think the main reason of this rule is to restrict what kinds of body parsing a bearer token parser has to support, and to motivate webmasters to build file uploads in a way where the server can validate the token before even deciding whether to start reading the body.

I think the highlighted rule's impact on the server side is just "you may safely ignore any body whose Content-Type isn't application/x-www-form-urlencoded."

mk-pmb avatar Dec 23 '16 20:12 mk-pmb