[OpenID] Using OpenID outside of the browser

Sat May 5 22:38:19 UTC 2007

Some very general thoughts:  Having the server establish temporary 
session state based on a unique URL is interesting though I think it 
does impose additional burdens on servers.  It'd be nice if there were 
options to use either a localhost: receiver or a server session.  It'd 
also be nice if the server session could use a server-generated URL to 
allow it to do session load balancing (westcoast.example.com vs. 
eastcoast.example.com). 

I'm also noticing that the establishment of a session is using a GET to 
create a (temporary) server resource, which can be problematic since 
it's modifying server state.  Given that this is a desktop client with 
no restrictions on HTTP verbs, PUT or POST might be more appropriate.  
PUT is especially appealing since the client can simply PUT a new URL 
with a unique nonce (and it's idempotent) and get back a 201 Created 
code to indicate a new session has been established.  Using a 302 to 
mean "send this to a web browser, don't really follow this redirect" 
might be a bit problematic too -- consider a service that wants to fail 
over to a new location; 302 is no longer available for this purpose.  
Perhaps a new unique header, or a link in a returned XML document, might 
be more appropriate; for example, <link rel="login page" 
type="text/html" href="http://..."/>. 

If polling is desired, the use of an Atom Entry document might be a good 
approach.  You could PUT an initial state to a unique URL, getting a 
modified version of the state in the 201 Created response, with a login 
URL back to perform the login, then do a series of GETs until the state 
changes to "authenticated" or something similar.  The entry also 
provides a fairly standard way to give feedback to the end user through 
title, summary, and/or content HTML fields.

(In the process of moving to a new house, I totally missed this thread 
even though I've been thinking along similar lines [1].  Brendan alerted 
me to the discussion.)

-John

[1] 
http://journals.aol.com/panzerjohn/abstractioneer/entries/2007/05/04/aol-openauth-and-atom-publishing-protocol/1440

David Fuelling wrote:
> 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=
>       <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/
>       <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
>       <http://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 
> <mailto: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
>     <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>
>     [mailto: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 <mailto: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 <mailto:general at openid.net>
>     http://openid.net/mailman/listinfo/general
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> 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/189f5a38/attachment-0001.htm>