Hi all - I think I know the answer to this but just wanted to check: would it be possible to log into a modern ASP dot NET Core app and then load a legacy ASP dot NET Forms app that has forms authentication and have it auto-authenticate through the Core app via auth0? Or is a reverse proxy approach with redirects back and forth to the modern and legacy app the only way to achieve this seamless login integration?
To admins of this site: I had to use ASP dot NET to avoid the warning of including URLs. Seems a bit odd 
Hi @cmuentes,
Welcome to the Auth0 Community!
Your desired flow is achievable by integrating your applications within Auth0 and Achieve Single Sign-On (SSO) Between Applications. You can check out more about SSO using this link - Single Sign-On.
Even though the legacy Forms Authentication system is not compatible with modern protocols like OpenID Connect out-of-the-box, you can integrate your application using Auth0’s ASP.NET (OWIN) authentication, which provides a standard way to build a middleware pipeline for .NET applications, and would act as the bridge between your apps and would allow managing an auth0 session cookie.
I believe this would be the most suitable pattern to follow up on, but your case would be achievable using a reverse-proxy and redirects as well, which will require a more custom configuration as well.
Thank you!
Best regards,
Remus
Awesome, thanks. Is it possible to debug the script in any way for testing purposes, or is it kind of a black box? If the latter, then I can just make the script as small as possible so the only failure point can be an external service that I can debug myself. Secondarily, does my service always have to be deployed to a reachable server via the internet for the script to work, or could I point it at localhost and run my service locally?
Hi @cmuentes,
You can fully debug your application’s code when running any SDKs that Auth0 provides, including the .NET application that you are trying to integrate and especially your custom middleware part. It is nothing similar to a black box, but mainly C# pieces of code over which you can use any debugging tools or logs within VS.
You can absolutely point the script or service at localhost and run your service locally for testing. You do not need to deploy it to a publicly reachable server for the most of your development scenarios.
Thank you!
Kind regards,
Remus