Re: [OAUTH-WG] Understanding the reasoning for Base64

[Dick Hardt <[e-mail]>]

On 2010-07-01, at 12:52 PM, Naitik Shah wrote:

> Searching for base64url does make it better. Thanks for that pointer Dick.
> 
> We don't think base64url will work, because the most common error we'll see is that developers forget the "url" part and just do plain base64, and that's not sufficient because the stock set includes +.

I think forgetting to url-decode is more likely than doing the wrong base64 encoding. At least with the wrong base64 encoding, what was done wrong is more obvious right away. The + will not be in the string.

> 
> So it will maybe work, maybe not. Maybe they'll do urlencoding after anyways, since if they are passing this as a query param, or post data, client libraries will take a dict and try to "do the right thing". And we end up with pluses, and we're not quite sure if they should be urldecoded or not.

we won't have pluses

> 
> For example, this doesn't give me back what I put in:
> 
>   base64_decode(urldecode(base64_encode('-+>')))
> 
> Because the base64_encode returns something containing a +, and the usual urldecode logic will convert this into a space. In fact, looking at the PHP docs for base64 decode, there are a bunch of comments talking about pluses: http://php.net/manual/en/function.base64-decode.php.
> 
> The approach I'm thinking is something like:
> 
>   function getSignedToken($params, $secret) {
>     $json = json_encode($params);
>     // Moving the signature to be before the payload makes the separator/split
>     // logic be: "everything before the first dot is the sig". also, it's hex.

why hex? ... why not base64url?

>     return hash_hmac('sha256', $json, $secret) . '.' . $json;
>   }
> 
>   function parseSignedToken($token, $secret) {
>     list($sig, $json) = explode('.', $token, $limit=2);
>     if (hash_hmac('sha256', $json, $secret) !== $sig) {
>       throw new Exception('Bad Sig');
>     }
>     return json_decode($json);
>   }
> 
> [UNTESTED!] Where url encoding and decoding happens outside of the signature process.
> 
> I'm not convinced adding the request as a header is going to be used often. Headers are always sent uncompressed. I imagine signatures to be used for those that are perf sensitive and don't want the SSL overhead. So this minor detail will matter to them. This is especially true because unlike OAuth1, the header doesn't just contain a signature, but contains the entire signed payload. But there's nothing stopping us from using the same format above for sending the payload as a header.

I am unclear on what your point is. 

The token would be included as one of the headers. This is often preferable as it separates the authorization layer (in header) from application layer parameters (query string or message body)


> 
> One of the arguments was wrt detecting double url encoding. Since the thing we're signing is a JSON object, we always know it will start with %7B and if it's double encoded, it will be %257B.

So you really think a developer will remember the spot that it is  not %7B and is %257B  but will NOT to use base64url?