In the new Keycloak centralized model, your actual users table should live only in Keycloak for authentication and authorization.

Your services should not maintain separate login users, passwords, roles, or authentication systems anymore.

Recommended model

Keycloak
  └── Users
  └── Passwords / MFA / login
  └── Roles
  └── Groups
  └── Permissions / policies

Trainers Service
  └── trainer_profile table

Students Service
  └── student_profile table

Company Service
  └── company_profile table

Consulting Firm Service
  └── consulting_firm_profile table

So should each service still have a users table?

No, not for authentication.

Each service should not have its own users table like before.

But each service may still have its own domain/profile table.

For example:

In Keycloak

Keycloak stores:

user_id
username
email
password
phone
roles
groups
status
MFA settings

In Students Service

You may store:

student_profile
---------------
id
keycloak_user_id
student_number
course_id
grade_level
created_at

In Trainers Service

trainer_profile
---------------
id
keycloak_user_id
specialization
experience_years
bio
created_at

In Company Service

company_profile
---------------
id
keycloak_user_id
company_name
tax_number
address
created_at

The important field is:

keycloak_user_id

This links the service-specific profile to the centralized Keycloak user.

What should not be stored in services anymore?

Services should not store:

password
password_hash
login_token
refresh_token
user_role_for_auth
auth_permissions
security_questions
MFA secrets

Those belong in Keycloak.

What can be stored in services?

Services can store business-specific data, such as:

student enrollment info
trainer skills
company billing profile
consulting firm documents
preferences
service-specific settings

This is not authentication data. This is application/domain data.

How login works now

User logs in through Keycloak
        ↓
Keycloak returns access token / JWT
        ↓
Frontend sends token to services
        ↓
Each service verifies token
        ↓
Service reads keycloak_user_id from token
        ↓
Service loads local profile using keycloak_user_id

Example:

JWT token contains:
sub = "8f91-abc-221"
email = "student@example.com"
roles = ["student"]

Then Student Service does:

SELECT * FROM student_profile
WHERE keycloak_user_id = '8f91-abc-221';

Best practice answer

For your requirement of 100% centralized authentication and authorization:

| Data | Stored where? |
| ----------------------- | ----------------------- |
| User login | Keycloak |
| Passwords | Keycloak |
| MFA | Keycloak |
| Roles | Keycloak |
| Groups | Keycloak |
| Permissions | Keycloak |
| Access tokens | Keycloak |
| Student profile | Student service |
| Trainer profile | Trainer service |
| Company profile | Company service |
| Consulting firm profile | Consulting firm service |

Simple rule

Keycloak owns identity and access.

Each service owns only its business data.

So instead of every service having a separate users table, each service should have something like:

student_profile
trainer_profile
company_profile
consulting_firm_profile

Each of these tables should reference the centralized Keycloak user using:

keycloak_user_id

Final recommendation

Do not keep separate users tables for authentication in each service.

Use this model:

One centralized user identity in Keycloak
+
Service-specific profile tables linked by keycloak_user_id

That gives you centralized login, centralized roles, centralized authorization, and still lets each service manage its own business-specific data.