This removes the encoding of the Bearer token -- OAuth spec isn't as clear as it could be here, but it's intent is that this token is not base64 encoded, only that it adheres to the grammar laid out in b64token.
Note that the name b64token does not imply base64 encoding but rather
is the name for an ABNF syntax definition from HTTP/1.1, Part 7
[I-D.ietf-httpbis-p7-auth]. Because of its use, the "access_token"
string value from an access token response MUST match the b64token
ABNF so it can be used with the Bearer HTTP scheme.
Yeah, something as simple as, "Note that the name 'b64token' does not imply
base64 encoding, see the definition in [[INSERT REFERENCE HERE]]." would do
it.
Manual Test
This was performed against the current website, which doesn't accept base64 encoded tokens.
$ conduct load-license
An access token is required. Please visit https://www.lightbend.com/platform/enterprise-suite/access-token to
obtain one for free or for your commercial licenses.
Please enter your access token: <redacted>
Loading license into ConductR at 192.168.10.6
Licensed To: 521e4ec3-6e40-4719-8ec5-17e44262c41e
Max ConductR agents: 3
Expires In: 92 days (Thu 09 Nov 2017 09:37AM)
ConductR Version(s): 2.1.*, 2.1.0-beta.1
Grants: akka-sbr, cinnamon, conductr
License successfully loaded
-> 0
This removes the encoding of the
Bearer
token -- OAuth spec isn't as clear as it could be here, but it's intent is that this token is not base64 encoded, only that it adheres to the grammar laid out inb64token
.See this discussion on the spec that confirms this: https://www.ietf.org/mail-archive/web/oauth/current/msg08481.html , notably the following quotes:
Manual Test
This was performed against the current website, which doesn't accept base64 encoded tokens.