dozens of databases - one per client
I am guessing, that is the reason for down votes of the question. That is a very bad organizational decision. But if you "client" is actually a group of individuals - departments for example, then yes, this approach can have some merit. If a "client" in your case is an individual person - please reconsider! There are tons of single-user databases starting with Access and sqlite, the SQL Server is not a good DBMS for personal databases.
Once this controversial problem is out of the way...
The approach to security on mulit-db server is largely the same as with a single database. Create as many login
s on the server as needed (one per person). But assign each login
default database and, if needed, add this login
as user
to other databases.
It is better (at least from user point of view) to use Windows AD security instead of SQL Server's own. Because in this case, the login
become something like "mycompany/personid" and you just add this login
to specific databases as needed. But the actual user will not need to "login" to database anymore.
For DBA using domain security is also easier, since if a person forgets his/her password - the domain's admin will deal with it, not database admin... But from all other DBA's points of view - domain or server security does not differ much.
the application is currently using a single Windows login
That is also very bad decision. Application should not use any logins at all, but ask the user to provide credential. They can be hidden by usage of domain logins, but it still would be personal logins.
If you really need an application (like a scheduled robot) to do a login without human present - that is usually done by creating a special user in the domain - the one which would be specific to this application and no human should be able to use it.