КК инфу по пользователю (всякие аттрибуты типа firstName, lastName и другие кастомные)? Я на сколько понял это можно делать только через админку
Или лучше пойти в сторону написания микросервиса профиля пользователя, где будет все необходимое содержимое?
Это имеется в виду для потребления инфы по пользователю со стороны клиентских приложений типа мобилок
OIDC имеет /userinfo ендпоинт просто по спеке
Мне не нравится вообще подход, использования кейклока как сервиса авторизации(исключительно IdP), как по мне, должен быть бэкэнд со своими токенами и своими аттрибутами, если они нужны
Но к нему доступ по idtoken’у, использовать idtoken для авторизации, мне кажется, не очень хорошая идея
Ну т.е. отвечая на ваш вопрос, мне второй вариант нравится больше
А почему? KK же круто дружится с ресурс серверами. Под капотом дергается jwks ендпоинт и токены красиво проверяются для защищенных эндпоинтов на бэкенде прикладном
Ну, потому что IdP должен быть провайдером, а не авторизовывать запросы, намного гибче, когда этим занимается твой бэкенд, наверное, большой разницы нет, когда этим кейклоком владеешь ты, а если не ты и не можешь ограничить состав аттрибутов, в случае своего бэкэнда - можешь всегда, и т.д. Ну и твой бэкенд тоже должен будет отдавать jwks на well-known url
Мне кажется, кейс, когда ты не можешь управлять кейклоаком, который ты используешь, достаточно редок, чтобы давать общие рекомендации использования своего бэкенда
Таскать готовый keycloak в любом случае выглядит лучше, чем свой бэк (но это уже уходим в предпочтения, которые для каждого проекта разные будут)
Мне так не кажется, так как и okta, и keycloak известные sso, завтра придешь в компанию, а они скажут, что у нас окта и разворачивать кейклок мы не будем. Или кейклок есть, но нужных прав не дадут, но это и правда уже предпочтения(кому-то же нравится писать экстеншены на кейклок)
Обсуждают сегодня