Sell a web app with limit per client

I don't quite understand what it is you actually want to share.

I'd assume you won't find a framework cause what you want to do is not that hard to solve.

1) A third party application is -only- going to touch your general purpose API. It uses API authentication only (through forms authentication, api key usage, take your picking).

2) Your own application through user actions will redirect to login page and such and have it's own picking of authentication (form authentication probably). This is about stuff the user can potentially enter through the address bar of the webbrowser. If your application happens to use your general purposed API under the hood you are not going to redirect the user to your login page on ajax calls. Your application should handle/prevent this for the user. A user is not going to make API calls through his/her browser's address bar.

So for your application to be able to use your general purpose API, the general purpose API would only need to support the same authentication scheme (form authentication). Or your application would have to fetch the user's api key or something to use after the user logged in.

You can easily create an Authorize attribute in MVC that will checks multiple options, first for an api-key, then for a forms authentication based cookie token. If it finds nothing your general purpose API should or needs to throw 401s only.

Your application would pick them up from ajax call failures and could decide to move the user over to the login page.

Single Sign On is an excellent idea. Just so you know, you don't necessarily need to use a specific technology, such as Active Directory, WIF or OAuth. You can implement it with just ASP.NET forms auth. Here's how you do it:

Selling it to the head of IT

1. Don't make it just about developer happiness, there's a significant user happiness benefit of SSO.
2. Take your current workload and project the time required to keep mucking with an imperfectly architected system over a year. Compare that with the time required to do a re-write. Most of the time, if it breaks even after a year, it's a good trade.

Deciding on How

1. Figure out the most common way users are identified, (such as AD name, or email address) and try to centralize on that - it should reduce the scope of the re-write.
2. Once you have the best key defined, pick a technology or method that leverages that.

Random Tips from my experience

1. I've had the least friction with OAuth. Mainly because we used google apps, so everyone already had a corporate google account.
2. Windows Authentication has problems depending on if it's set up with NTLM or Kerberos - I had a particular problem with NTLM over a VPN.
3. ADFS was just too much hassle to get working correctly for anyone outside of our domain, it really wasn't worth it.

To keep your application maintainable, I would make the configuration as simple as possible. To your question about the separate databases, if they don't buy you anything by being separate, reduce the complexity and merge them. Since they are an intranet, I'm assuming they won't ever be deployed separately.