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

[Evan Gilbert <[e-mail]>]

Hi all - having a little bit of a hard time following the full thread, but
I'm strongly in favor of base64url encoding.

A big advantage of this encoding is that, if token is base64url encoded,
then urlencode(token) == token.

This allows developers to avoid a large class of problems in dealing with
URL encoding / decoding issues - it is very easy to accidentally double
encode / decode values, and also easy to get tripped up on the different
encoding rules in different parts of a URL. For example, different
characters are OK before and after the hash, and not all browsers decode the
hash the same way.

Also being able to copy a value from a URL and use it directly in a tool or
Authorization header is invaluable for debugging.

Per notes above, the transformation is very straightforward.

Evan

On Sat, Jul 3, 2010 at 12:45 PM, Dick Hardt <[e-mail]> wrote:

>
> On 2010-07-03, at 12:14 PM, Naitik Shah wrote:
>
> On Sat, Jul 3, 2010 at 9:42 AM, Dick Hardt <[e-mail]> wrote:
>
>>
>> On 2010-07-03, at 9:13 AM, Naitik Shah wrote:
>>
>> > I think Naitik is saying that accidentally doing base64 and not
>>> base64url will send some '+'s along.
>>>
>>> if there are '+'s in the token, then it is easy for someone helping to
>>> spot the problem. also easy for servers to send back an error message
>>> saying, "hey, looks like you are using base64 instead of base64url encoding"
>>>
>>> ie, it is easy to detect the error -- urlencoding / decoding is hard to
>>> detect as an error
>>>
>>
>> The pluses are not guaranteed. They may or may not be there depending on
>> the data stream you're encoding. If you don't urlencode the JSON, you'll get
>> a "{", if you do it once, you'll get a "%7B", if you do it twice, you'll get
>> a "%257B" -- seems easier to detect.
>>
>>
>> Your earlier point was that developers may incorrectly use base64 instead
>> of base64url. If they used base64, and if there is a + / = or % in the
>> string, the server can send a useful note saying what is wrong. There may
>> not be one of those characters depending on the input string, but if there
>> is, then the server can suggest what the error might be using base64 instead
>> of base64url. If the token contains ANY character that is not in base64url,
>> then the server can say that it is not base64url encoded.
>>
>> That seems pretty fool proof to detect. Note that you should never get any
>> %7B or other encoding in the token as it is url safe.
>>
>
> The thing I was trying to say was that it's less predictable. That it might
> work just fine when you're experimenting with the API because at that point
> your token did not contain any pluses, but then suddenly started failing
> after you sent a link to your app to someone because their encoded token
> contains a plus. This hit-or-miss to me is worse than being able to tell by
> looking at the first few characters of the urlencoded JSON blob which will
> give a definitive answer as to how many times the token has been urlencoded.
>
>
> I understand your point. I still think base64url encoding makes it really
> clear that it is encoded (nothing is legible anymore), allows there to be
> one encoding format for all data, makes it easy to support encryption.
>
>
>
>
>
>>
>>>  When I wrote a sample in Perl, it was pretty easy to make it base64url
>>> which then provides a consistent encoding.
>>>
>>
>> Did it involve a string replace call? Or a third party library?
>>
>>
>> I used a standard CPAN library.
>>
>>
> Exactly :) I'm imagining our documentation where we want to be library
> agnostic, and have almost psuedo code like code snippets. I said this
> earlier -- while base64 may be common in standard libraries built into
> languages, the base64url version isn't. In order to not have a "cpan install
> base64url" (and gem install, easy_install, mvn install..) -- we'ed most
> likely document a str_replace() call in addition to a base64 call. And I'm
> worried that developers will miss this detail.
>
>
> Likely they will install an OAuth library that will deal with it if they
> are going to have to sign rather than using a bearer token (I believe most
> people will use a bearer token if they can -- soooo much easier!)
>
> Besides base64url, there is HMAC256 and JSON -- not all of which are built
> in -- but are becoming more built in as time goes on, and if OAuth signing
> uses base64url, I would expect these will all be part of standard
> distributions in the future ...
>
> (... in case you are unfamiliar with my backgroud, I have delivered Perl,
> Python and Tcl distributions in the past -- what goes into a packages is
> what is heavily used or what we thought was a good thing to promote -- and
> assuming that  making base64url more available is a good thing, than using
> it in OAuth is a good thing to do. :)
>
>
>
>
>>
>>
>>
>>
>>> >
>>> >> 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)
>>> >
>>> > With our proposal, we were focussed on url parameters (hence the choice
>>> of urlencode after it was all put together). I think it makes total sense to
>>> not do the encoding as part of the sig spec, and let the transport choice
>>> dictate which encoding to use.
>>>
>>> I understand what you are saying. having multiple encodings makes
>>> libraries harder, and leads to the issues that motivated base64url over
>>> url-encoding
>>
>>
>> Glad we agree on that.
>>
>
> I agree multiple encodings makes libraries harder :)
>
>
> glad we agree there
>
>
>
> But I think the stark difference between OAuth1 vs 2 wrt to signing
> actually makes the Authorization header less valuable (again, for signing
> only). I'm pretty happy with this because I thought this header was more
> complex for developers anyways (while big corporations with authentication
> infrastructure love it) :) But the reason I think so is that now the header
> is not just the signature, but also the signed payload. This means an
> application isn't just making a http request as before with a bunch of query
> or post parameters. It's instead making a "JSON request" that may or may not
> have query/post params. It's just not as separate as before.
>
>
> I am confused on what point you are trying to make here.
>
>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
>
>