I'm fine with changing the example to make it clearer that b64token allows a
wider range of characters than just those legal for base64 and base64url
encodings of data values.
I'll add it to my to-do list for any additional edits for the Bearer spec.
-- Mike
---
Brian,
> On casual reading of "The OAuth 2.0 Authorization Protocol: Bearer
> Tokens"* I've encountered several people (including myself) who have
> made the assumption that the name b64token implies that some kind of
> base64 encoding/decoding on the access token is taking place between
> the cli
On casual reading of "The OAuth 2.0 Authorization Protocol: Bearer
Tokens"* I've encountered several people (including myself) who have
made the assumption that the name b64token implies that some kind of
base64 encoding/decoding on the access token is taking place between
the client and RS.
Diggi
On 05/03/12 14:14, Justin Richer wrote:
>
>>>
>>> Shane is right; the way you described your problem, the client
>>> credential grant type may be appropriate. That's especially true if
>>> the client will be accessing resources that don't necessarily belong
>>> to specific users. But if the client
Shane is right; the way you described your problem, the client
credential grant type may be appropriate. That's especially true if
the client will be accessing resources that don't necessarily belong
to specific users. But if the client (web site) will be using the API
(OAuth auth/resource serv
Hi,
On 01/03/12 22:24, André DeMarre wrote:
Pete,
Shane is right; the way you described your problem, the client
credential grant type may be appropriate. That's especially true if
the client will be accessing resources that don't necessarily belong
to specific users. But if the client (web site
