прикольно было бы посмотреть использование oauth и реализацию или использование либ для реализации своего сервера авторизации как такие токены валидировать - а то как-то пробовал заюзать oidc от фастапи он чот фигню какую-то делал для моего oidc сервера и решил свой oidc валидатор написать, а на сервере юзал парные ключи, чтобы можно было отправить на сервис запрос и он один раз за публичным ключом для валидации обращался к серверу авторизации и дальше сам валидировал также сервер авторизации писал сам, поскок хотел свою специфичную структуру для опльзователей использовать - пробовал разобраться в Keycloak, но так и не понял можно ли в нем хранить свою схему пользователя и как это сделать. ещё знаю, что можно предусмотреть ротации ключей, но такое ещё не делал и хз как другие сервисы оповещать, что ключ был изменен, хотя может в публичную инфу это можно положить и сервер перед валидацией будет проверять просроченность ключа
Спасибо за такой развёрнутый комментарий! Очень интересный опыт. Написание своего сервера авторизации с учётом специфичных требований - крутой подход, особенно если стандартные решения вроде Keycloak не вписываются. Кстати, в Keycloak можно использовать свою схему пользователя, например, добавляя custom attributes через настройки или расширения - как описано в этой статье: medium.com/@ramanamuttana/custom-attribute-in-keycloak-access-token-831b4be7384a Что касается ротации ключей, вы правы, это можно делать через публичный endpoint с метаданными (например, .well-known/jwks.json). Многие сервисы при проверке токенов периодически обращаются к этому endpoint, чтобы получить актуальные ключи, но такая реализация требует аккуратного подхода. В моем понимании публичные ключи только валидируют токен, а приватный ключ всегда хранится на сервере, на котором создаются токены. Да, вопрос с просроченностью ключей можно решить, добавив публичную информацию о времени жизни ключа, что облегчает процесс ротации. Я подумаю о создании видео или материала по этим темам, включая ротацию ключей, валидацию токенов и настройку своей структуры пользователей. Эта тема действительно обширная, которую я постараюсь разобрать в нескольких уроках
![Урок 3 | Аутентикация и Авторизация в FastAPI [часть 1] | Intermediate ⭐ | Python на практике](/img/n.gif)
Спасибо. Ждал продолжение.
Спасибо за ваш интерес! 👍
прикольно было бы посмотреть использование oauth и реализацию или использование либ для реализации своего сервера авторизации
как такие токены валидировать - а то как-то пробовал заюзать oidc от фастапи он чот фигню какую-то делал для моего oidc сервера и решил свой oidc валидатор написать, а на сервере юзал парные ключи, чтобы можно было отправить на сервис запрос и он один раз за публичным ключом для валидации обращался к серверу авторизации и дальше сам валидировал
также сервер авторизации писал сам, поскок хотел свою специфичную структуру для опльзователей использовать - пробовал разобраться в Keycloak, но так и не понял можно ли в нем хранить свою схему пользователя и как это сделать.
ещё знаю, что можно предусмотреть ротации ключей, но такое ещё не делал и хз как другие сервисы оповещать, что ключ был изменен, хотя может в публичную инфу это можно положить и сервер перед валидацией будет проверять просроченность ключа
Спасибо за такой развёрнутый комментарий! Очень интересный опыт.
Написание своего сервера авторизации с учётом специфичных требований - крутой подход, особенно если стандартные решения вроде Keycloak не вписываются. Кстати, в Keycloak можно использовать свою схему пользователя, например, добавляя custom attributes через настройки или расширения - как описано в этой статье: medium.com/@ramanamuttana/custom-attribute-in-keycloak-access-token-831b4be7384a
Что касается ротации ключей, вы правы, это можно делать через публичный endpoint с метаданными (например, .well-known/jwks.json). Многие сервисы при проверке токенов периодически обращаются к этому endpoint, чтобы получить актуальные ключи, но такая реализация требует аккуратного подхода. В моем понимании публичные ключи только валидируют токен, а приватный ключ всегда хранится на сервере, на котором создаются токены. Да, вопрос с просроченностью ключей можно решить, добавив публичную информацию о времени жизни ключа, что облегчает процесс ротации.
Я подумаю о создании видео или материала по этим темам, включая ротацию ключей, валидацию токенов и настройку своей структуры пользователей. Эта тема действительно обширная, которую я постараюсь разобрать в нескольких уроках