Well, it not clear why you don't just add some API end points to the existing WebForms application?

In other words, adding some web methods to existing pages, or even adding a .asmx web service page to the existing WebForms would be the easiest road.

However, assuming that both web sites have full rights and access to the same database?

Then change the security SQL provider and the role provider for the WebForms to point to the same "user" database as the new site. This will require you to add (create) these two providers for the existing web forms site.

It is rather easy to simply "inherit" the SqlProvider, and "inhert" the RoleProvider in the existing Webforms application, and that will THEN allow you to point the user database to the new and SAME user database in the new site with the API's.

So, in terms of most easy?

I would consider just adding the API's (web end points) to the existing application. In fact the big question why this was not considered a option? As I pointed out, little or next to nothing is and would prevent you from adding web end points (API's) to the existing site. As noted, this not only solves all your issues, but web end points for WebForms automatic support REST, XML and JSON data, and do so without any special efforts on your part.

If above is not a valid choice (and you not explained why this easy road is not being taken), then next up would be to simply point the existing WebForms's SqlProvider, and RoleProvider's to the new database. You can as noted, create a new (custom) SqlProvider, and a new RoleProvider. If you inherit the existing providers, you find that very few code stubs are required for both of these providers to continue to work, and work by being pointed to the new user database.

Of course, the only issue I can see is if you're using some of the older "legacy" pages often provided in WebForms to add new users, delete (disable) new users, and how they do things like re-set their password etc. And how now are these users assigned security roles for the existing site? In other words, how many moving parts are being used to manage existing users? (either none, or a lot??? - this question needs to be answered).

If you have your own custom pages for this purpose? Then once again, creating a custom sql and role provider would be little work, and that would result in the WebForms site now using the new user database that the API site is using.

As noted, my first choice and suggestion would be to add the web end point's and API's to the existing WebForms application, and it not at all clear why this was or is not the first choice?