OpenID best implementation practices?
chowells at janrain.com
Thu Dec 29 18:52:07 UTC 2005
Johannes Ernst wrote:
> 1) is there a "best practice" that OpenID implementations should follow
> in order to avoid replay attacks? I suspect the trick is to create a
> Relying Party (aka return_to) URL that contains a nonce, and track the
> uses of that nonce?
> E.g. if the Relying Party is
> as the return_to URL in the forward leg of the authentication, and
> check the my-nonce parameter on the return leg for whether or not it
> was taken already?
That's essentially what I believe to be the best approach, though there
is additional flexibility possible. Our OpenID library provides the
relying party with a token (containing the nonce and some additional
information) that it is responsible for associating with the request in
whatever manner is most appropriate for its application.
Many applications have the concept of a session, even for
non-authenticated users, which is a good spot to store the token. Other
applications may choose to store the token in a cookie, or make it part
of the return_to URL for that request.
But in any case, the idea is the same: store a nonce somewhere, and
verify that it hasn't been used when a response comes back that tries to
> Does that mean we could use the same mechanism that we are using in
> LID, or is a different approach more appropriate for OpenID?
The biggest difference is that LID's approach is specified by the
protocol, but OpenID's is left to implementations. That means that the
one-way nonce idea won't work with the current version of OpenID, as it
requires both the server and the relying party to use the same mechanism.
> 2) is there a "best practice" for single sign-OUT (not -IN). It is
> relatively straightforward to keep track of all the Relying Parties at
> which I have authenticated during the current session, but other than
> visiting each of them manually and looking for the OpenID Logout button
> on each of them, can I automate this from one big button "log out
That's currently not possible. See the discussion in part of this old
> 3) Is the threat model against OpenID documented somewhere? I'm missing
> the rationale for some of the URL arguments, such as why
> openid.return_to is returned on the back leg of the authentication
> redirects, or why some of fields should or should not be signed.
I don't think there's any one document that contains everything. I'd
recommend looking at mailing list archives, especially for messages from
Paul Crowley, and the ones he responded to.
> Of course, everybody might be on vacation ...
Not everybody. :)
More information about the yadis