Proving identity via Tent

gistfile1.txt

I've been trying to wrap my head around Tent's app
registration/authentication process and specifically how it works for a
web app.

As I understand it, when someone goes to the web app, puts in
'http://entity.tld' and clicks Sign In, the app:

1. Checks its local database to see if it already has app registration
details for 'http://entity.tld'.

2. If not, it registers itself with the server for 'http://entity.tld'
and gets a client ID (6 alphanumeric characters in tentd's
implementation), MAC key ID (of the form "a:" followed by 8 hex digits
in tentd's implementation), and MAC key. This happens without the owner
of 'http://entity.tld' needing to approve the registration or even be
signed in.

3. The app builds a URL for an auth request (which, to identify the app,
contains the Tent-server-provided client ID), and redirects the user
trying to sign in to that URL.

4. The user is required to sign in to the Tent server for
'http://entity.tld', if not already signed in. (In the next step we'll
assume that this sign-in succeeded.)

5. If the user has not used this app before, or if the app is requesting
new permissions since last time the app is used, the user is shown a
list of permissions the app wants and asked whether to grant or decline.
(In the next step we'll assume the user granted the requested permissions.)

6. The user is redirected to the app's callback with a “code” parameter
(32 hex digits in tentd's implementation).

7. The app posts this code at /apps/:id/authorizations on the server for
'http://entity.tld'. In return, the server provides a MAC key ID (of the
form "u:" followed by 8 hex digits in tentd's implementation) and MAC
key. The app can now use this key and ID to interact with the Tent
server on the user's behalf.

My first observation is that while a native app that runs on the user's
device (desktop or mobile), can store the credentials obtained in step 7
and use them indefinitely, a web app *must* always perform steps 3-7 per
session, because only the successful completion of step 7 guarantees
that the user trying to sign in is actually the owner of
'http://entity.tld'.

My next observation is that performing step 2 before the user is
authenticated has two very unfortunate consequences.

One, I can register apps with someone else's Tent server, spamming their
database and admin interface with “apps” they have no desire to use.

Two, by using a timing attack, I can see whether an app is already
registered with another user's Tent server. All I have to do is sign-in
as them with that app, and measure the delay before I get a redirection
response. This is not conclusive evidence, because anyone can register
the app, but it could be enough in some cases. The result is a loss of
privacy (imagine if the app is something sensitive, like a gay dating app).

It seems to me that the auth process is flawed. The web app should
require proof that the user trying to sign in is actually
'http://entity.tld', before it does anything that changes state on the
Tent server, and before it reveals in any way whether it has seen that
user before.

Please correct me, Tent architects and/or fellow developers, if my
understandings above are incorrect.

-s