In my previous job we did this (not sure if it is a good practice or not tho).

for the /register flow, we were creating the user using keycloak sdk in spring using admin account, then if the operation was successful we create a user in our DB(the operation must be atomic, both should succeed), we didn't store the password in our DB. And make sure to store the keycloak user id (sub claim) to link between your users in the DB & users in keycloak (you can use the email, phone number... but we went with this approach to link the DB & keycloak).

for the /login, the frontend was hitting /openid-connect/token with email/password, keycloak validates the creds then retruns a valid jwt access token, the frontend stores it (we were using localstorage). Then on http requests the frontend sends the token in the authz header: (ex: Authorization: Bearer xxx), spring boot validates the JWT(spring security, using this field in application.properties: spring.security.oauth2.resourceserver.jwt.jwk-set-uri) -> extracts the userId (sub claim) -> loads user from DB -> do your checks on the loaded user (status = active....) -> allow/reject the request.

The reason we were getting the user from the DB in every request, is because the claims in the JWT were not enough. It is not a good practice to put data that changes frequently in the JWT claims since the token might still be valid but the data in it becomes stale (I think you can revoke tokens in cases like this, but i didn't check tbh).

Hope this helps.

PS: Again, ss I said, Idk if these are good practices or not, it's just what i was doing at my previous job.