On 2011-10-13 02:38, Manger, James H wrote:
One possible syntax is:
Bearer access_token=xyz_-123,more_info=pdq
Ultimately though, the format of the bearer token is outside of the scope of
the spec, and up to the participants to determine, including whether to use
b64token syntax or params syntax.
It is great to see an example explaining the intention of the "b64token / #auth-param" part of the draft. These
details need to be in the spec. Draft 9 makes no mention of an "access_token" parameter for the HTTP header --
in sharp contrast to mentioning such a parameter for the URI query string and POST body mechanisms. Can the
"access_token" value be a<token> (as in the above example)? Can it be a<quoted-string>? Can it use
RFC5987 (eg access_token*=UTF-8''...)?
Can a client choose the b64token or auth-param option, implying servers MUST
support both? Or is it the other way around: servers only have to support
b64token so existing servers are compliant without requiring any changes?
I thought the consensus was that bearer tokens were so simple that
"Bearer<b64token>" was sufficient. In the unlikely event that more parameters
were required in future, a new scheme (eg Bearer2) could be defined. If this is no longer the
consensus then lets:
1. Define a single syntax that servers MUST support.
Authorization: Bearer a="<access_token>"
2. Use a short parameter name, such as "a", saving 10-bytes per request over
"access_token". The long name is needed in a URI query string or POST body so the
parameter is unambiguous amongst any number of other application-specific parameters. In a Bearer
HTTP header there is no such possibility of confusion.
3. Don't allow the value to be either a<token> or<quoted-string> -- just pick one
(I suggest<quoted-string>). It doesn't help developers or interop to offer a pointless
choice.
4. Allow future comma-separated parameters, and state that unrecognized
parameters MUST be ignored.
5. Add an informative note that some servers might also accept a header of the form
"Bearer<access_token>", but clients using this form are not compliant to this
spec.
6. Explicitly state that when the type is "bearer" in an OAuth2 token response, the
"access_token" MUST only consist of characters that can be represented in a<quoted-string>, ie
%x20-7E (assuming<quoted-string> was picked at #3).
7. Recommend that a base64url encoding without padding (of binary data or of UTF-8
encoded text) is a good choice for an "access_token" value (or a few base64url
encoded segments separated by dots) as it avoids the need to escape characters in most
situations.
+1
Except for:
> 3. Don't allow the value to be either a<token> or<quoted-string> --
just pick one (I suggest<quoted-string>). It doesn't help developers or
interop to offer a pointless choice.
...allow both, because otherwise you'll need custom parsers to process
the header field.
Best regards, Julian
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
