PD
Вполне подходит)
Там не описана никак аутентификация клиента.
Size: a a a
2021 March 11
PD
Да и, если честно, OAuth2 очень неудачный протокол
MS
Там не описана никак аутентификация клиента.
https://auth0.com/docs/flows/client-credentials-flow
clientId + client secret
но мне казалось, что это OAuth2.0, а не OpenID Connect ... могу ошибаться
clientId + client secret
но мне казалось, что это OAuth2.0, а не OpenID Connect ... могу ошибаться
PD
https://auth0.com/docs/flows/client-credentials-flow
clientId + client secret
но мне казалось, что это OAuth2.0, а не OpenID Connect ... могу ошибаться
clientId + client secret
но мне казалось, что это OAuth2.0, а не OpenID Connect ... могу ошибаться
это расширение стандарта в конкретном решении. В стандарте ничего про секрет я не нашел
VA
JWK это же лишь формат определения ключа для JWS и JWE?
Ну сервис, владеющий ключами держит у себя jwks endpoint, с которого можно взять актуальные ключи. А сам URL сервиса определяется по iss токена
VA
Там не описана никак аутентификация клиента.
Дык сам процесс аутентификации нигде не описан, это от задачи зависит) там описано, что client (сервис) может поменять свои креды (на выбор 10 разных) на токен.
RT
Ну сервис, владеющий ключами держит у себя jwks endpoint, с которого можно взять актуальные ключи. А сам URL сервиса определяется по iss токена
Только паблик ключи. Значит JWE не подходит. Можно только JWS. В исходном вопросе было что-то про секретные данные в токене
PD
Дык сам процесс аутентификации нигде не описан, это от задачи зависит) там описано, что client (сервис) может поменять свои креды (на выбор 10 разных) на токен.
А где описаны варианты? Я что-то совсем стандарт давно читал (
VA
Только паблик ключи. Значит JWE не подходит. Можно только JWS. В исходном вопросе было что-то про секретные данные в токене
Да, для JWE нужно будет более сложно
VA
А где описаны варианты? Я что-то совсем стандарт давно читал (
VA
Ну и basic auth есть
MS
https://tools.ietf.org/html/rfc6749#section-2.3.1 тут явно про client id и secret
VA
И MTLS
DM
Да и, если честно, OAuth2 очень неудачный протокол
просто его часто пытаются применять не для того, для чего он предназначен
С
Да... проблема с ключами есть. Количество сервисов увеличивается. Плюс будет несколько экземпляров облаков идентичных сервисов. Теоретически можно решить через единый конфигурационной файл для каждого облака сервисов.
Работать с кредами не нужно. У любого запроса единые права с переданными параметрами. Защищать нужно именно эти параметры.
Работать с кредами не нужно. У любого запроса единые права с переданными параметрами. Защищать нужно именно эти параметры.
PD
https://tools.ietf.org/html/rfc6749#section-2.3.1 тут явно про client id и secret
Угу, но это все про MAY support....
PD
Denis Migulin
просто его часто пытаются применять не для того, для чего он предназначен
Ну, двутокенную схему (а она самая интересная) очень неудобно использовать в многопоточных приложениях.
PD
Да... проблема с ключами есть. Количество сервисов увеличивается. Плюс будет несколько экземпляров облаков идентичных сервисов. Теоретически можно решить через единый конфигурационной файл для каждого облака сервисов.
Работать с кредами не нужно. У любого запроса единые права с переданными параметрами. Защищать нужно именно эти параметры.
Работать с кредами не нужно. У любого запроса единые права с переданными параметрами. Защищать нужно именно эти параметры.
Ну тогда просто каждый сервис запрашивает централизованно открытый ключ по его id из токена и кэширует у себя.