Hey Bin,
Thanks for the comments, it's much appreciated as we sort out these
issues and make sure the service is both easy to use and has a good
sense of security.

I'm not sure I understand your first question completely, but I'll just
say that it's dangerous (and shouldn't be done) to *ever* distribute
both your applicationKey and privateKey. Of course, your applicationKey
will be seen by those using your service (it's how you identify in URLs
for the API calls, so it will be seen). But distributing both your
applicationKey and privateKey is bad because it allows anyone to pose
as you (you being your application). You should never, ever want that.

Our proposed solution above does away with having to ever distribute
your applicationKey and privateKey because it allows you to simply
obtain an applicationToken for each user (which will later turn into an
applicationKey and privateKey through authorization). An
applicationToken could essentially be equated to a "partially created
application." Think of it as an application with no owner, almost.
Because all applications must have owners -- and because you need an
applicationKey and privateKey to actually make API calls -- you can't
actually do anything with an applicationToken. So, what happens is you
send a user to the login page, and we tell them to confirm
authorization to the app you asked for through your applicationToken
(that is, you created a "partial application" with a name and
description and received back an applicationToken).

The good stuff comes when the user confirms the authorization. First,
we complete the creation of an application, with the user being the
owner. Then the user returns to your application and you call
Auth.GetApplicationCredentials to receive the applicationKey and
privateKey.

This is now the new applicationKey and privateKey which you store in
the user's application configuration, but do *not* distribute to anyone
else. Every single user of your program can simply call the
Auth.RegisterApplication call and get a unique applicationToken which
can turn into the applicationKey and privateKey combination you need.

In response to your questions about unconfirmedTokens and being able to
use them multiple times: it's true, you can reuse an unconfirmedToken.
This is not necessarily *too* insecure, but it's at least a point which
one could contend that we should force unconfirmedTokens to expire once
they've created a confirmedToken.

The reason it's not *too* insecure is because a talented user could get
at the confirmedToken just by snooping on URL traffic. The cool thing
is it doesn't really matter until they break the hash and can figure
out what the privateKey is. As long as that is sufficiently hard (and,
unfortunately, with more powerful CPUs, it's getting easier to do
that), it's still sufficiently hard to do anything useful with the
APIs. As long as we stay ahead of the curve on cracking hashes, we
should be okay. At least, I think... Can anyone contend this?

Hopefully this helps clear up some points. Let us know about other
questions/comments, of course.

Ian