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

[Naitik Shah <[e-mail]>]

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.



>
>>  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.



>
>
>
>
>> >
>> >> 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 :)

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.




>
>  >
>> > * We'd like the signature first (so you can left split instead of right
>> split)
>>
>> What are the advantages of left split vs right split?
>>
>
> Built in split function with a limit is more common, which makes the left
> split easier.
>
>
> Size limit I am assuming? Since the size of the signature is known, this
> makes it safer to have it first? Makes sense to me.
>
>
Yep, this and all the reasons you and Luke mentioned in the parallel thread.



-Naitik