In a one-to-one relationship, where should the foreign key be placed? I am currently designing an ERD for a project management system. I am unable to choose between two workable solutions as the best solution as I wish to embrace the best standards. 

The two entities that can access the system are the clients and employees. Since they have different information, I decided to treat them as different entities. I figured that it is best to have a single table for users of the system rather having the username and password fields be found in both tables of clients and employees. Plus, the constraints I have to follow:


All users are only limited to employees and clients.
But not all employees are required to be users of the system.


Here are the following entities without relationship yet defined:



Now, there is only one-to-one relationship between users and clients, employees and users. My question is where should I place the foreign key? Should I place two foreign keys in users table namely employee_id and client_id which makes it easier to find the associated client and employee entity from the user entity and where I can define authorization rules more easily? Or should I place each foreign key on clients and employees referencing the users table since I am unsure if it is an acceptable practice to have two foreign keys in a table in which only one foreign key can be used at a time.
It is acceptable to have mutually exclusive attributes in a table.  If you only have one pair of such attributes, this may be the most practical solution.

However, some people may look at your situation as a sub-typing issue.  In this view, you are missing the superset entity.  You have a collection of (something), some of which are employees and some of which are customers and some of which are also users.  

Have you also considered what happens if an employee also happens to be a customer?  Is that important to your system or is that something that would be considered coincidental?

If you think its important to treat all users as a feature of one type of thing, then you need to implement the (something) which is currently missing from your table definitions.

Consider the following ERD:



If you supply the missing superset entity, then every employee is one of these, as is every customer, and also therefore every user.  The hard part of this is coming up with a reasonable name for this superset, but it solves the issue of having to figure out which foreign key to follow from user.  It also makes a connection between employee and customer should one happen to exist, and should that connection be of interest.