On 2010-07-03, at 12:14 PM, Naitik Shah wrote:
> On Sat, Jul 3, 2010 at 9:42 AM, Dick Hardt <dick.ha...@gmail.com> 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
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
