I hope I understand your question correctly. Your first question regards database design, and in your second, you are looking for some understanding of use cases for oauth.
Let's talk about your first question, whose answer is a bit less concrete. This is a design decision and is somewhat subjective, but will have a better or worse solution based upon your requirements. You have to decide if the information you need to store about users vs. clients is substantially different. If it is, different tables will be your better design solution. If the only thing you need to know about clients vs. users is that they have a different kind of access, it is probable that all you need is an additional column in your table that will indicate the logged in person's type of access, whether it is client or user. In this case, a single table will be your better design solution.
The second question is also a great question and a source of much heartache for many developers, as oauth's purpose is often poorly understood and once you do get into using it, not all that simple to implement. Oauth can be thought of as a secure handshake between a client and a server. The client, in this case, is you, but the server is also you, which, in short means that you don't need oauth. If you would like to create a backend that can serve up data to other developers' client apps, then you might want to implement oauth, but even then you would only want to use it if you required authorization security from the server. It's a bit confusing at first, and I could go on, but here's an article that explains it very well, written by people who have implemented apps using oauth. If you still think you need oauth (if you're planning on your code being used by other developers as an API), you have your work cut out for you. Otherwise, don't worry about oauth for now!
