Question

I am implementing DotNetOpenAuth for both an OpenId provider and a relying party. In both cases, the servers are behind a load balancer, so for any HTTP request, we can’t assume that we’ll hit the same server.

It appears that DotNetOpenAuth depends on the Session to store a pending request key. Because the server may change between requests, we can’t depend on the standard InProc Session. Unfortunately, we’ve been unable to successfully implemented SQL as the store for Session.

My question is: is it safe to store a PendingAuthenticationRequest as a client cookie? Any worse than using Session?

Answer 1

The ProviderEndpoint.PendingAuthenticationRequest property is there for your convenience only, primarily for simpler scenarios. If it doesn’t work for you, by all means store it another way and totally ignore this property. No harm done there.

Ultimately a session is tracked by an HTTP cookie, so you can certainly store the auth request state entirely in a cookie if you prefer so that it works in a web farm environment. Another approach is to not require the client (or the server) to track state at all by either making everything (including authentication) handled directly at the OP Endpoint URL, or redirecting the user from the OP Endpoint URL with a query string that includes all the state informaiton you need to track. Be careful of the latter approach though since you’ll be exposing your state data to the user to see and possibly tamper with.

In short, you may or may not choose to store user sessions in a SQL store. That should be fine. The issue I think you ran into (that we discussed by email) was that you needed to implement your own IProviderApplicationStore, which will store nonces and associations in a database that is shared across all your web servers. This is imperative to do, and is orthogonal to the user session state since this is stored at the application level.