The 'users' table is frequently referenced; should I opt for a better design?

IMHO, the users table is the most frequently referenced table in most of the web apps. That seems to be the case with my 'big' app and I'm wondering if my approach is right.

I'm developing an app that basically is an ecosystem of interconnected web apps.

[Web App] |-- App 1 |-- App 2 |-- App 3 ...and so on.

While most of these apps are independent, they rely on the same users table. That said, each sub-app needs to have users with various roles and permissions.

Here's what I'm doing:

1. app_users table : Keeps track of app_id and user_id so that I know which user is using any app.

2. I've a user_roles table: Each registered user of the site has member role as default. If Any user should have greater permissions, I assign them new roles like App1Editor or App1Writer or App3Admin or App3Mod etc. Of course, I've separate tables to define 'roles' where I can go on adding new roles as and when any new app requires it.

3. While defining the tables, I've created references to the user_id.

Now, imagine a situation where I decide on allowing the users with App1Writer role to have their own short bio (which I can append to their posts). I'll have to create an writer_bio table, which again will user_id and bio columns.

I'll have to make multiple joins just to display a post or in future I'll have to keep extending this structure.

Do you think this would create problems in future? Looking for opinions.

PS: This community has been super awesomely wonderful and useful and I can't thank you all enough for all the support you offer. Merry Christmas, all ya great people!