Designing Security In An Application

With my next application, I'm thinking about establishing a new security paradigm for my programs, with respect to SQL Server.

In all my previous applications, connections are established using SQL Server authentication. So, all my users may log-in under a single log-in, mapping to a single user in a database. My application then has to use its own security arrangement to determine who has access to what forms within the application. There are three major problems with this design: 1) the user name and password to connect to the SQL server have to be resident as strings somewhere in the application code (or ancillary files), 2) everyone connecting to the SQL Server "looks" the same, and 3) you have to give the broadest rights to everyone with the same login and then pare those rights down within the application itself.

By implementing multiple SQL Server Authentication logins I can mitigate problems 2) and 3), but the only way to eliminate problem 1) is to move to Windows Authentication.

Windows Authentication would allow me to resolve all three design constraints, but there is one problem that I see coming as a result.

If I use Windows Authentication, each user must have an independent login to the SQL Server. If I have an application that may have 4,000 to 6,000 users, does that means I have to have 4,000 to 6,000 logins set up on SQL Server?

Is that true?

I could, of course, generate a script to build all 4,000 to 6,000 users, but I am concerned about this.

Is this a "normal" arrangement that SQL Server has no problem-with?