[OpenID] Using OpenID outside of the browser

[David Fuelling]

Gabe,

With regard to your "OpenId for Desktops" [1] proposal, why not eliminate
the localhost:9876 mechansim entirely.  Instead, the desktop client could
(once it has initiated an authentication process) simply poll a URL on the
RP to see if the authentication succeeded.

 That way, you don't have to worry about localhost clients (and concerns
about port conflicts, NAT, etc), and we don't have to have a "click this"
button, nor do we need the user to do anything special (like copy/paste this
nonce into a new window).

So, the process would go something like this (mainly only step 1 and 7-10
are different from your blog post):

   1. To initiate login, desktop client first does a request to a server
   component (an RP) to associate the desktop client's http session to the RP
   server component with an openid, and a nonce:

   GET on *
   http://servercomponent.com/client-auth?openid=me.openid.com&nonce=
   <nonce>

   *
   2. RP server component returns:

   *302 relocated
   Location: http://servercomponent.com/client-login/<nonce>*

   In generating this 302 response, the RP associates the nonce with
   desktop client's HTTP session, and the openid requested by the desktop
   client.
   3. The desktop client gets the 302 and does NOT follow the redirect
   itself. Instead, it makes the local web browser (e.g. python's
   webbrowser.open) go to
   *http://servercomponent.com/client-login/<nonce>*

   *Note: the desktop client and its HTTP session are now associated (by
   the RP server component) with the user's web browser session via the nonce.

   *
   4. The RP server component looks up openid by nonce and does openid
   discovery, returns a redirect to OP to the browser, with return_to set to:

   *http://servercomponent.com/client-complete/<nonce>

   *
   5. OpenID auth happens as normal (user browser goes off to OP to
   authenticate)
   6. The user browser eventually returns to

   *http://servercomponent.com/client-complete/<nonce>*
   7. *User sees a message from the RP that he can now close his browser.
   *
   8. User closes his browser (or perhaps the client app closes it, via
   step 9).
   9. Desktop client polls the URL *
   http://servercomponent.com/client-complete/<nonce>
    every 15 seconds until that page contains certain information (maybe
   hidden html fields?  Maybe an atom feed?) to let the desktop client know
   that the auth was succesful or not.  *Of course, the server component
   (on servercomponent.com) knows about the sucess or failure since it is
   a normal RP and has done normal OpenID auth in step 5. The desktop client,
   in response to a succesful poll can also try to close the browser window, or
   give the user a friendly status message.
   10. Client app now has access to the RP server component.


[1] http://blog.wachob.com/2007/03/openid_for_desk.html

On 4/29/07, Gabe Wachob <gabe.wachob at amsoft.net> wrote:
>
> I'm not sure if what I discussed earlier on this list and on my blog
> matches
> your requirements, but you might find it of interest:
>
> http://blog.wachob.com/2007/03/openid_for_desk.html
>
>         -Gabe
>
> > -----Original Message-----
> > From: general-bounces at openid.net [mailto:general-bounces at openid.net] On
> > Behalf Of Brendan Taylor
> > Sent: Sunday, April 29, 2007 5:16 PM
> > To: general at openid.net
> > Subject: [OpenID] Using OpenID outside of the browser
> >
> > I've written a web-based Atom Publishing Protocol client[1] that uses
> > OpenID for identifying users. It seems to me that since I have a user's
> > OpenID anyways, it makes sense to include it when publishing an entry;
> > the problem is that while the client knows the user controls that URL,
> > there is no way (that I know of) for the client to prove that to another
> > server.
> >
> > A more general case: I would like to let people comment on my blog using
> > the Atom Publishing Protocol. I would also like to use and verify their
> > OpenIDs for identification. But most APP clients aren't going to be part
> > of a browser, and so the login-redirect-set cookie dance seems out of
> > place.
> >
> > What's the best way to marry OpenID and non-browser clients?
> >
> > 1: <http://necronomicorp.com/pushpin>
>
> _______________________________________________
> general mailing list
> general at openid.net
> http://openid.net/mailman/listinfo/general
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-general/attachments/20070505/5760cc02/attachment-0002.htm>