Users enter a username and password to log into the application.
On Windows, it's more customary to assume that, since the User has managed to log themselves into their own computer to Windows' satisfaction, then they can connect to the application "as themselves", with no further authentication (that they're aware of).
In this case, you'd be looking at a "Trusted" connection into the database, with the user set up at the database end with a Windows account, not a SQLServer one.
The other major downside of SQL Server accounts is that Users will forget their password and, having done so, have locked themselves out of the database and, therefore, cannot use any application-provided "password reset" capability, assuming you've written one.
Another alternative is to bake SQL Server credentials into the application. These are never disclosed to Users and are used to make the connection on their behalf. These credentials confer enough privileges to make the application work. Again, it removes the need for "extra" User authentication and, because you've hidden the credentials away, Users cannot connect to the database using their favourite, ODBC-compliant Reporting program and rummaging around in things that don't concern them.
I use the SQL Server Logins to manage permissions with the database tables
Good start. I'd suggest building on this by looking at using Groups (essentially, Role-Based Access Control).
Set up [small numbers of] Groups with the right levels of permission and then add the right Users to the right Groups.
Don't create permissions for individuals.
Instead, create permissions needed for someone to do their job and then, if that person does [decide to] leave, then their successor can get the exact same permissions, simply by being added to the same Group.