It's not hard to modify the forms authentication login process so that in addition to normal forms authentication, a WebClient object does basic authentication to the api/token url served by a Web Api DAL set up with Thinktecture IdentityModel. The returned session token can then be stored in the Session dictionary for later use when calling the DAL.
The problem is that these tokens have different lifespans.
I could rewrite the app to keep credentials in localStorage for use recreating the session token as required, but that's ugly and not ideal from a security perspective.
Possibly there are ways to configure token durability for one or both of these systems, but I don't know what search terms to use (I tried searching for token durability and token lifespan but the results weren't helpful).
I'm interested in both philosophical and pragmatic suggestions on how best to coordinate the two types of web app security. I'd be very surprised if there weren't already answers on this topic, if only I knew what to search for.
A little background, since some folks aren't clear on what I'm asking.
There's a big ugly old school ASP.NET web app that uses forms-based security
I've just added new stuff as a separate DAL app that uses Thinktecture IdentityModel. This DAL is used by two apps, the ASP.NET app and a Durandal SPA.
They use the same database for credential checking so they have the same identity space.
I have modified the old app's login process so that it also presents credentials to and obtains a session token from Thinktecture IdentityModel. This token is put into the Session collection to be presented whenever the old app calls into the DAL.
If you start the old app, authenticate, do stuff and close the browser, then later reopen the browser, you have a logged in ASP.NET app without login occurring so there's no opportunity to create the session token. This is the problem. I need the two tokens to have the same lifecycle.
I've thought of one possible approach. I'm presenting it below as an answer so people can express their opinions on its merits or make refinement suggestion comments. If I think of any other ideas I'll throw them up as answers, and I hope you'll do the same.
At the server I know the user id, both when generating the session token and later when the ASP.NET session is recreated without it.
What I need is the server equivalent of a cookie. A quick search for "server side cookie" returned a couple of articles, one of which I apparently wrote myself in 1999, all of which boil down to "use a database".
So... I could use a database. We have a user table, I could add a column. Or I could create another table with three columns: UID, SessionToken and CreatedAt.
CreatedAt is a date-time from which I can work out whether the token has expired and when it has I could expire the ASP.NET session to force a new login.
I ended up using a variation on this. In my specific case, armed with UID, credentials can be fetched from the user table. So I put the token and the creation time into Session and otherwise proceeded as above. When Session doesn't contain a token expiry time or the token has expired, I fetch credentials and request a token then update the token and the expiry.
All this is wrapped in an exception handler that returns a dummy (invalid) token, the net result of which is behaviour identical to tokens of identical durability.
You'll notice that I didn't use a persistent table. This way there are fewer failure points and no dependence on the ability to edit the database schema. The cost of managing state in a table would have been at least as high as the cost of generating a new token.