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

[Dick Hardt <[e-mail]>]

Yeah!

On 2010-07-06, at 11:12 PM, Naitik Shah wrote:

> I was hoping to avoid needing str_replace -- but I've been convinced. I'm happy with base64url :)
> 
> 
> Thanks,
> -Naitik
> 
> On Tue, Jul 6, 2010 at 9:17 PM, Evan Gilbert <[e-mail]> wrote:
> 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
> 
> 
>