Keycloak-js является "официальной" реализацией для FE приложений от самого Keycloak - можно найти в документации. Других библиотек рекомендовать не могу. Встречал самописные реализации в отдельных проектах, но как правило они были хуже.
Чтобы работать через cli tools, флоу с редиректом на кейклок не подойдет, нужно использовать флоу direct grant access, на вход передается логин пароль, на выходе получаете токены UPD: Можно еще посмотреть device code flow
Второй раз пишу коммент, первый, судя по всему, затер ютуб из-за внешней ссылки на tg. Вариант с Direct grant access действительно может быть решением, но выбирать его стоит, только когда пользователь готов доверять свои логин/пароль приложению, либо когда есть технические ограничения на использование браузера. Если техническая возможность использовать браузер есть, более предпочтительным вариантом с точки зрения ИБ будет Proof Key for Code Exchange. После митапа разобрал сценарий с PKCE в tg канале (ссылка есть в профиле).
Если у вас взаимодействие которое можно описать как М2М(Машина-к-Машине), вызов АПИ например, создание realm через АПИ и все такое, используються client password grant что вроде как задепрекейчено Oauth2.0 либо client credentials flow. Для этого можно создать отдельного клиента в кейклоаке. Ну а authorization code flow(PKCE) маст хев для авторизации пользователей через пароль
Дратути! С разделением пользователей по разным realm: аргументация против этого некорректна, пользователей из одного realm можно использовать в другом посредством федерации (OIDC протокол это позволяет) - это вполне себе рабочий сценарий. В целом, для желающих разобраться в теме это видео довольно бесполезное (есть некоторые неточноти, недосказанности и явные ошибки).
18:50 а какие библиотеки фронтовых адаптеров использовали ?
а почему именно keycloak-js?
Keycloak-js является "официальной" реализацией для FE приложений от самого Keycloak - можно найти в документации. Других библиотек рекомендовать не могу. Встречал самописные реализации в отдельных проектах, но как правило они были хуже.
Чтобы работать через cli tools, флоу с редиректом на кейклок не подойдет, нужно использовать флоу direct grant access, на вход передается логин пароль, на выходе получаете токены
UPD:
Можно еще посмотреть device code flow
Второй раз пишу коммент, первый, судя по всему, затер ютуб из-за внешней ссылки на tg.
Вариант с Direct grant access действительно может быть решением, но выбирать его стоит, только когда пользователь готов доверять свои логин/пароль приложению, либо когда есть технические ограничения на использование браузера.
Если техническая возможность использовать браузер есть, более предпочтительным вариантом с точки зрения ИБ будет Proof Key for Code Exchange.
После митапа разобрал сценарий с PKCE в tg канале (ссылка есть в профиле).
Если у вас взаимодействие которое можно описать как М2М(Машина-к-Машине), вызов АПИ например, создание realm через АПИ и все такое, используються client password grant что вроде как задепрекейчено Oauth2.0 либо client credentials flow. Для этого можно создать отдельного клиента в кейклоаке. Ну а authorization code flow(PKCE) маст хев для авторизации пользователей через пароль
Вообще отдавать токены на фронт не очень секьюрно
Дратути! С разделением пользователей по разным realm: аргументация против этого некорректна, пользователей из одного realm можно использовать в другом посредством федерации (OIDC протокол это позволяет) - это вполне себе рабочий сценарий. В целом, для желающих разобраться в теме это видео довольно бесполезное (есть некоторые неточноти, недосказанности и явные ошибки).
сопоставить пользователей из разных realm можно?