OpenId as API authentication method

Eran Hammer-Lahav eran at hammer-lahav.net
Sat Jul 28 03:52:38 UTC 2007


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
<http://api.example.com/session/openid/initiate.xml?openid=some_id&return-ur
l=client_side_capture&realm=optional_client_realm&is-immediate=true>
&return-url=client_side_capture&realm=optional_client_realm&is-immediate=tru
e

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.verisignl
abs.com
<http://api.example.com/session/openid/initiate.xml?openid=eran.pip.verisign
labs.com&return-url=http://www.example.com/capture>
&return-url=http://www.example.com/capture

 

API reply:

http://pip.verisignlabs.com/server?openid.ns=http%3A%2F%2Fopenid.net%2Fsigno
n%2F1.1
<http://pip.verisignlabs.com/server?openid.ns=http%3A%2F%2Fopenid.net%2Fsign
on%2F1.1&openid.mode=checkid_setup&openid.identity=http%3A%2F%2Feran.pip.ver
isignlabs.com%2F&openid.return_to=http%3A%2F%2Fwww.example.com%2Fcapture%3Fn
ouncer.nonce%3D2301694855%26nouncer.sig%3DFFcpLk7S09X60WJSgIEBSWFk2vU%3D&ope
nid.trust_root=http%3A%2F%2Fwww.example.com%2Fcapture>
&openid.mode=checkid_setup&openid.identity=http%3A%2F%2Feran.pip.verisignlab
s.com%2F&openid.return_to=http%3A%2F%2Fwww.example.com%2Fcapture%3Fnouncer.n
once%3D2301694855%26nouncer.sig%3DFFcpLk7S09X60WJSgIEBSWFk2vU%3D&openid.trus
t_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

 

 

 

 

 

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


More information about the specs mailing list