[OpenID] Can we make a seamless OpenID mobile experience?
Breno de Medeiros
breno at google.com
Fri Apr 10 21:51:45 UTC 2009
Reposting this to OAuth, since they did not like my previous attempts.
On Fri, Apr 10, 2009 at 2:09 PM, Breno de Medeiros <breno at google.com> wrote:
> Actually, the subversion client fits reasonably well in this paradigm:
> 1. The shell interface has a convenient mechanism to accept variable
> input. So the choice of entering a password there.
> 2. The fact that the password does not get exchanged for another token
> (single-user vs. pairing) is a consequence here of the fact that
> subversion clients do not support OAuth; and the shell interface is a
> reasonably convenient mechanism to enter long, strong secrets
> (cut-and-paste from SVN server UI to shell client).
> In general, the human-to-device channel cannot conveniently accept
> large secrets (the svn client example is an exception in this setting)
> and therefore you need a shorter, single-use secret to leverage a
> pairing of stronger crypto token. The OAuth protocol effectively gives
> you this pairing.
> In general, the model of single-use code to be leveraged as a 'request
> token secret' and the full OAuth exchange give in general a mechanism
> that is both more usable (because requiring users to enter short
> secrets) and more secure (because it uses signatures for fetching
> data instead of playing the same secret over what may be insecure
> On Fri, Apr 10, 2009 at 1:55 PM, Deron Meranda <deron.meranda at gmail.com> wrote:
>> On Fri, Apr 10, 2009 at 3:34 PM, Breno de Medeiros <breno at google.com> wrote:
>>> The idea is to use a single-use code of some kind that works as a
>>> password substitute (since the user does not have a password at the
>>> site because he/she signs in using OpenID), followed by the
>>> installation of a longer-lived token on the device. Think about
>>> bluetooth pairing of devices as the basic paradigm.
>> This is not just a mobile or device issue. I do something similar
>> now, for example, to support Subversion version control. The client
>> is typically a Unix command line, and the communications is HTTPS +
>> DAV. No browser there, and probably not even a GUI.
>> Basically, my RP (which hosts subversion among other things) issues a
>> single-purpose password for a user once they are authenticated via
>> OpenID. Then, just for the subversion/DAV portion of the website's
>> URL space, I allow standard HTTP authentication.
>> Also for subversion, most clients will try to "remember" the password
>> once a DAV connection is configured for a local workspace. So as not
>> to break that, the password (which my RP picks) should not readily
>> change. This password is single-purpose, not single-use---which would
>> be prohibitively frustrating for the user in this case.
>> If your RP has it's own user ids; you can store your subversion
>> passwords easily enough. If not, then you can use something like an
>> HMAC hash of the claimed_id, using a secret key, to generate the
>> passwords for each user. You also probably want to use some sort of
>> hash on the claimed_id to generate the usernames (as would go in
>> change lists, etc.); since arbitrary URLs are not syntactically
>> suitable for subversion "users".
>> Since my RP generates these passwords rather than the user picking
>> them, they can be quite strong. Also I don't have to worry about the
>> user forgetting them and getting locked out; since the user can just
>> login via OpenID and then view the password when needed.
>> For the end user, they will have to login via OpenID at least once, to
>> learn what their subversion username/password is. Then they can use
>> subversion in the normal way, without OpenID.
>> You can do additional security checks if you want. Such as only
>> allowing the subversion password to work if a (relatively recent)
>> OpenID session has been created from the same location.
>> Granted, this puts a lot more work on the RP and it's not seamless.
>> But it is doable, and doesn't generate a mass of rarely-used
>> complexity in the OpenID protocol itself, or a rewrite of lots of
>> applications that know how to do standard HTTP authentication.
>> Deron Meranda
> +1 (650) 214-1007 desk
> +1 (408) 212-0135 (Grand Central)
> MTV-41-3 : 383-A
> PST (GMT-8) / PDT(GMT-7)
+1 (650) 214-1007 desk
+1 (408) 212-0135 (Grand Central)
MTV-41-3 : 383-A
PST (GMT-8) / PDT(GMT-7)
More information about the general