* Authorization - How do I confirm who this person is?
* Identity - Everything about the person. Think name, email, address, tenant_id
* Permissions/roles - What can this person do?
I'm going to discuss this with the assumption that you're using some sort of relational database. If you're using something else, you should be able to adjust accordingly. Keep in mind that your web framework probably has libraries for all of these and standard practices since every app that requires you to sign in had this..
Let's start off with roles and permissions. Typically, most companies will want at a minimum an admin user and a regular user. This usually ends up expanding to include specialized roles such as accounting, who would only have access to billing information, auditor, which would be a read-only role.
Identity - Unless you're just starting a project, this has probably been implemented already and may be called users, customers or employees. This can be one table or a set of tables and would include the relevant information about the person logging into your system. At the very least this includes name, email, and tenant_id.
Authorization - Typically this will start out with username/password login combinations, but is often expanded to include 2FA-login flows, single sign on (OAuth flows using SAML or Active Directory/LDAP authentication). That there can be multiple auth workflows is a good reason to keep these as separate tables from your user table(s).
A good open-source example is Discourse (https://github.com/discourse/discourse). It's a good case because it does have SSO options