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

Add clarity around how the access token is sent for various encodings #119

Open
MaybeThisIsRu opened this issue Aug 15, 2020 · 0 comments
Open

Comments

@MaybeThisIsRu
Copy link

MaybeThisIsRu commented Aug 15, 2020

For URL encoded requests, an example has been given where the authorization header is used. This is repeated in the next three examples.

My inference: The access token MUST be sent as an Authorization header.


The template from micropub.rocks states the following:

[ ] The client sends the access token in the HTTP Authorization header.
[ ] The client sends the access token in the post body for x-www-form-urlencoded requests.

My inference: The access token may be sent in either way, but for URL encoded requests, it MUST use the post body. For all other methods of form submission, it MUST be included in the headers.


Lastly, the access_token property is reserved for both URL encoded and form data requests:

A few POST body property names are reserved when requests are sent as x-www-form-urlencoded or multipart/form-data.

  • access_token - the OAuth Bearer token authenticating the request (the access token may be sent in an HTTP Authorization header or this form parameter)

My inference: it MAY be sent in either the headers or the post body, and this is true for BOTH URL encoded requests as well as form data requests. The server MUST look at both headers and post body to get an access token.


As you can see, there is potential for a lot of confusion and this should be clearly laid out in the spec itself.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant