все верно.
Если у вас пользователи - какая то рабочая сущность и нужны не только для авторизации, то можно хранить пользователей в БД и сопоставлять им пользователя в киклоке. Как вариант - использовать один UUID для пользователя в БД и в киклоке. Вроде как киклок не позволяет самому указать id пользователя, поэтому сначала создавать там, получать id, а потом записывать в базу.
Запрос на регистрацию можно прогонять через киклок, проверять уникальность email, проверять сложность пароля, которая тоже настраивается в киклоке (минимальное количество символов, использование строчных, заглавных, спецсимволов и пр.), и только потом записывать необходимые данные в базу.
Также удобно некоторые не меняющиеся часто запрашиваемые пользовательские данные (ФИО, дата рождения например) хранить в атрибутах пользователя киклока и прокидывать их в JWT чтобы лишний раз не лезть в БД.
Вообще разных вариантов много. Кто-то в киклоке хранит вообще всё связанное с пользователем. Есть те, кто наоборот держит там только почту и пароль.