OpenId as API authentication method

Sat Jul 28 04:13:14 UTC 2007

You should probably check out OAuth:  
http://groups.google.com/group/oauth, and its draft spec 
<http://openauth.googlegroups.com/web/OAuth%201.0%20-%20Draft.rtf?gda=s1UWzkYAAAAySf4xbkOgHBZma37zlp9GzEEF__EUK3CcB8RrKx_-nmG1qiJ7UbTIup-M2XPURDT_25fdK7wDxUtwqL26wW_WahD8rT1PnKl_iYB0spTcFQ>.  

Eran Hammer-Lahav wrote:
>
> I am not sure if this belongs in the spec list, but I'll give it a try.
>
>  
>
> I would like to suggest adding some text to section 11.1 (or anywhere 
> else that's appropriate) that will provide guidelines for using OpenID 
> in a scenario where the OpenID RP is not the site the user is actually 
> using. The OpenID specification is written with some bias towards 
> implementation in a website environment which is the most common use. 
> My aim is to use OpenID as the authentication method for establishing 
> API sessions. I am building a web service where the client (any user 
> of the API) requests to create a session token which can then be used 
> to bypass authentication for a certain period of time (nothing new here).
>
>  
>
> The API with HTTP Basic auth it looks something like:
>
>  
>
> https://api.example.com/session/open.xml - with the plaintext username 
> and password in the HTTP header, returns an XML reply with a session token
>
> http://api.example.com/session/close.xml?session-id=unqiue_token
>
>  
>
> Each user will have a local username and password. I was trying to 
> avoid it at first but with the current state of OpenID, it might cause 
> problems as some OP are unreliable and users can end up locked out if 
> their only access is with the one OpenID they setup their access with. 
> The plan is to provide an OP for local users (so that any local user 
> is also an OpenID), and to also allow users to associate any other 
> OpenID with their account. Once a user adds another OpenID to their 
> account, they can use that to create a session via:
>
>  
>
> http://api.example.com/session/openid/initiate.xml?openid=some_id&return-url=client_side_capture&realm=optional_client_realm&is-immediate=true 
> <http://api.example.com/session/openid/initiate.xml?openid=some_id&return-url=client_side_capture&realm=optional_client_realm&is-immediate=true>
>
> http://api.example.com/session/openid/validate.xml?response-url=op_endpoint_redirection_url
>
>  
>
> For example, a USER logs into a WEBSITE which is built on top of a web 
> SERVICE. The SERVICE requires OpenID authentication (the SERVICE is 
> the RP). The USER login request is sent via AJAX to the SERVICE with a 
> return_to URL able to capture the OP reply and send it back to the 
> SERVICE. The SERVICE reply to the AJAX code with the checkid_immediate 
> URL. The AJAX code calls the checkid_immediate given and captures the 
> redirection reply. The AJAX code calls a second SERVICE API call 
> providing the OP reply to the checkid_immediate request. The SERVICE 
> validates the reply and answers with a SERVICE session. The AJAX code 
> the stores the session id in a cookie and uses it for other API calls.
>
>  
>
> The same logic can be used with checkid_setup and a server side API 
> call. The USER is redirected by the AJAX script to the checkid_setup 
> URL received from the initiate API call. The user signs-in and is 
> redirected back to the WEBSITE client_side_capture page with the 
> OpenID query parameters. The WEBSITE server page client_side_capture 
> receives the request, calls the SERVICE validate API, and redirects 
> the USER back to the WEBSITE with the session cookie.
>
>  
>
> This voids the first step in section 11.1 since the RP receives the OP 
> reply via an API call that is not the same as the return-to URL. In 
> order to keep the transaction secure, I have added another signature 
> to the return_to parameter. This way when the WEBSITE returns the OP 
> reply to the API validate call, the SERVICE can make sure that the 
> original return_to was created by it, and not by the WEBSITE. The 
> normal openid.sig signature will make sure the OP reply is valid for 
> the entire input. This is the an example API call and reply:
>
>  
>
> API call:
>
> http://api.example.com/session/openid/initiate.xml?openid=eran.pip.verisignlabs.com&return-url=http://www.example.com/capture 
> <http://api.example.com/session/openid/initiate.xml?openid=eran.pip.verisignlabs.com&return-url=http://www.example.com/capture>
>
>  
>
> API reply:
>
> http://pip.verisignlabs.com/server?openid.ns=http%3A%2F%2Fopenid.net%2Fsignon%2F1.1&openid.mode=checkid_setup&openid.identity=http%3A%2F%2Feran.pip.verisignlabs.com%2F&openid.return_to=http%3A%2F%2Fwww.example.com%2Fcapture%3Fnouncer.nonce%3D2301694855%26nouncer.sig%3DFFcpLk7S09X60WJSgIEBSWFk2vU%3D&openid.trust_root=http%3A%2F%2Fwww.example.com%2Fcapture 
> <http://pip.verisignlabs.com/server?openid.ns=http%3A%2F%2Fopenid.net%2Fsignon%2F1.1&openid.mode=checkid_setup&openid.identity=http%3A%2F%2Feran.pip.verisignlabs.com%2F&openid.return_to=http%3A%2F%2Fwww.example.com%2Fcapture%3Fnouncer.nonce%3D2301694855%26nouncer.sig%3DFFcpLk7S09X60WJSgIEBSWFk2vU%3D&openid.trust_root=http%3A%2F%2Fwww.example.com%2Fcapture> 
>
>
>  
>
> Given the increasing focus on web services, it will be very helpful to 
> include some guidelines in the specification as to how to implement 
> something like the above protocol and how to ensure it is done in a 
> secure manner (I will gladly contribute the text). Any thought are 
> greatly appreciated, as well as letting me know this might not be the 
> right place for such a discussion...
>
>  
>
> Thanks,
>
>  
>
> Eran Hammer-Lahav (=eran)
>
> Hueniverse, LLC
>
> http://hueniverse.com
>
>  
>
>  
>
>  
>
>  
>
>  
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> specs mailing list
> specs at openid.net
> http://openid.net/mailman/listinfo/specs
>   

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs/attachments/20070727/1638ae95/attachment-0002.htm>