Is it ok to create many logins in SQL Server
SQL Server Security Doesn't Scale Well as a Login Store
While you &quot;can&quot; use many SQL Server logins for a web app doesn't mean you should. At the hospital where I work, we use a legacy application called Fastrack. It uses many SQL logins, one for each user, and it's a nightmare to maintain. Users leave and you don't know they've gone. There's no password table and folks forget their passwords. SQL Server security wasn't really built to be a front end for application security. Additionally, providing web users with an authentic SQL login poses security risks to your DBMS. You'll need to assign object security. There will most likely be more manual maintenance to these logins. No DBA will willing want to manage this. And, I've never seen this work well--ever.
A Simple Approach
A better approach is to build a login table or collection of tables within SQL Server for your app. Then, login through ONE application login to SQL Server to take advantage of connection pooling. Next, branch out with your own application login in the app. You'll want to obfuscate the passwords accordingly and possibly store them in an encrypted column within SQL Server. For example, create a simple login page with ASP.NET using C#. It doesn't have to be complex.
https://www.c-sharpcorner.com/article/how-to-create-login-page-in-asp-net-web-application-using-c-sharp-and-sql-server/
ASP .NET Core Identity
And Microsoft is also pushing Identity framework to build scaffolding for logins that are both internal to your app or external from places like Google and Facebook. This looks way more involved and in depth for what you &quot;might&quot; need at first. Especially if you're just experimenting. But you'd probably be able to find some baked code that you can use/copy to get you started.
https://docs.microsoft.com/en-us/aspnet/core/security/authentication/identity?view=aspnetcore-5.0&amp;tabs=visual-studio#create-a-web-app-with-authentication