Authorization Code Grant в 2.1 не требует обязательного использования какого-то готового агента в виде браузера. В принципе, есть даже драфт, который как бы специально для браузерных приложений как дополнение создан к OAuth, т.е. в самом OAuth нет однозначного требования, что ваше приложение должно базироваться только на браузерных агентах. Вы можете и свое разработать. Главное, что меняется в 2.1 — это то, что нам говорят, что теперь основными сценариями при разработке потоков аутентификации мы должны пользоваться только Authorization Code Grant с PKCE, Client Credentials Grant и еще для дивайсов, думаю, вот этот RFC8628 войдет.
я вижу кучу аппов не делающих это. Они просто все плевали на OAuth?
— вероятно, это риторический вопрос. Если спрашиваете у меня, то в моей практике имеются случаи, когда заказчик «плюет» на безопасность или соответствие каким-либо спецификациям разрабатываемого приложения.
что поменялось и как это теперь реализовывать?
Я надеюсь, что OAuth2.1 и последующие будет понятнее для потребителей, и допускать меньше вольностей в интерпретации. Сейчас, чтобы разобраться, как работать по OAuth, нужно еще рад RFC и драфтов изучить, которые выпускались к фреимворку, как дополнение.
Что поменялось я писала выше, но продублирую еще раз здесь:
(1) Потоки Implicit grant (response_type=token) и Resource Owner Password Credentials исключаются из документа.
(2) Аuthorization code grant расширили кодом PKCE (RFC7636) как для публично, так и конфиденциального клиентов.
(3) Redirect URIs должны будут всегда явно задаваться на сервере авторизации.
(4) Refresh токены для публичных клиентов должны ограничиваться, либо использоваться не более 1 раза.
В ваших вопросах чувствуется некая эмоциональность, и не знаю, были ли все-таки вопросы мне адресованы или во вселенную), но надеюсь, что я смогла отчасти на что-то ответить.
Если я вас правильно поняла, то вот тут предлагается описание для данного сценария. Т.е. использовать публичного клиента (без секрета) + соответственно, PKCE обязательно, как следует из требований к потоку Authorization Code Grant выше.
Здравствуйте!
Спасибо за вопрос.
client credentionals — его основное предназначение — это обмен между приложениями (бэк ту бэк) Например, стороннее приложение использует ваш сервис, который вы не хотите делать публичным, а предоставляете только авторизованным системам.
Доброе утро!
Спасибо за ваш вопрос. Здесь важно обратить внимание на то, что эта рекомендация дается для приложения "JavaScript application with a backend".
Сейчас токены чаще всего как случайный набор символов не используются. Многие решения формируют токены в формате JWT. И в токенах может содержаться значимая информация (встречаются реализации с ФИО, телефонами, email и т.д.).
Поэтому для JavaScript application with a backend стоит использовать:
классический Authorization Code Grant, когда ClientId и Secret хранятся только в бэке и обмен идет в защищенной сети (можно без PKCE тогда и использовать конфиденциального клиента), обмен токенами идет только в бэке,
либо мы не обращаем внимание на то, что у нас присутствует бэкенд, и реализауем сценарий как для JavaScript application with no backend, но по всем правилам для публичных клиентов: Authorization Code Grant Flow with PKCE с публичным клиентом (у публичного клиента нет секрета, а PKCE вводится для защиты только процесса аутентификации пользователя в таком случае) и с добавлением API Gateway, так как для этого сценария строже требуется выполнять проверки токена (redirect uri, cors, clientId, подпись и т.д.) и исключать передачу персональных данных в токене.
Для классического Authorization Code Grant схему дополнила информацией по тому, в какой момент еще формируются пользовательская и клиентская сессия:
Добрый день.
По примеру можно сгенерировать схему, но она будет упрощенная, без ссылочности на другие схемы, в рамках только 1 схемы все.
Т. Е. чтобы использовать все преимущества схемы, нужно пониманить, как ее формировать, в том числе, чтобы избежать дублирования.
Золотой пилюли нет, но при первом формировании схемы я тоже пользуюсь автогенерированием "черновика" схемы, а затем уже разбиваю на несколько схем, оптимизирую.
Все утилиты в статье приведены в самом конце. Присмотритесь к ним, думаю, что-то полезное для себя сможете выбрать.
Добрый день. Вы не забыли указать "$schema": json-schema.org/draft-04/schema# в корне структуры?
Можете привести ваш пример (сложно проанализировать, не видя вашего примера)?
Для валидации можно использовать онлайн-валидаторы, как этот, например: jsonpath.curiousconcept.com, или те, что в статье в списке ссылок приведены.
Спасибо за комментарий.
Если откровенно, но мне не очень понятен сценарий. Не затруднит привести пример и пояснить, за счет чего схема станет строже при ее генерации в run-time? Как технически на это влияет заполнение enum на этапе выполнения программы? Очень интересно)
С огромным удовольствием прочла ваш комментарий)))
Ваш ход мыслей на тему гениальности приглашает к обсуждению).
Вы мастерски задаете конвергентные вопросы, и мне большого усилия стоит, чтобы не «поконфронтировать» вам немного. Но я удержусь), иначе обсуждение может действительно уйти далеко за пределы обсуждения темы данной статьи).
Спасибо за ваш комментарий)
Супер! спасибо! классная статья!
— вероятно, это риторический вопрос. Если спрашиваете у меня, то в моей практике имеются случаи, когда заказчик «плюет» на безопасность или соответствие каким-либо спецификациям разрабатываемого приложения.
Я надеюсь, что OAuth2.1 и последующие будет понятнее для потребителей, и допускать меньше вольностей в интерпретации. Сейчас, чтобы разобраться, как работать по OAuth, нужно еще рад RFC и драфтов изучить, которые выпускались к фреимворку, как дополнение.
Что поменялось я писала выше, но продублирую еще раз здесь:
(1) Потоки Implicit grant (response_type=token) и Resource Owner Password Credentials исключаются из документа.
(2) Аuthorization code grant расширили кодом PKCE (RFC7636) как для публично, так и конфиденциального клиентов.
(3) Redirect URIs должны будут всегда явно задаваться на сервере авторизации.
(4) Refresh токены для публичных клиентов должны ограничиваться, либо использоваться не более 1 раза.
В ваших вопросах чувствуется некая эмоциональность, и не знаю, были ли все-таки вопросы мне адресованы или во вселенную), но надеюсь, что я смогла отчасти на что-то ответить.
Спасибо за вопрос.
client credentionals — его основное предназначение — это обмен между приложениями (бэк ту бэк) Например, стороннее приложение использует ваш сервис, который вы не хотите делать публичным, а предоставляете только авторизованным системам.
Спасибо за ваш вопрос. Здесь важно обратить внимание на то, что эта рекомендация дается для приложения "JavaScript application with a backend".
Сейчас токены чаще всего как случайный набор символов не используются. Многие решения формируют токены в формате JWT. И в токенах может содержаться значимая информация (встречаются реализации с ФИО, телефонами, email и т.д.).
Поэтому для JavaScript application with a backend стоит использовать:
Для классического Authorization Code Grant схему дополнила информацией по тому, в какой момент еще формируются пользовательская и клиентская сессия:
(надеюсь, читаемо)
Добрый день.
По примеру можно сгенерировать схему, но она будет упрощенная, без ссылочности на другие схемы, в рамках только 1 схемы все.
Т. Е. чтобы использовать все преимущества схемы, нужно пониманить, как ее формировать, в том числе, чтобы избежать дублирования.
Золотой пилюли нет, но при первом формировании схемы я тоже пользуюсь автогенерированием "черновика" схемы, а затем уже разбиваю на несколько схем, оптимизирую.
Все утилиты в статье приведены в самом конце. Присмотритесь к ним, думаю, что-то полезное для себя сможете выбрать.
Можете привести ваш пример (сложно проанализировать, не видя вашего примера)?
Для валидации можно использовать онлайн-валидаторы, как этот, например: jsonpath.curiousconcept.com, или те, что в статье в списке ссылок приведены.
Откровенно говоря, не искала аналоги, алтовы мне достаточно всегда было. Но если поискать, то вот такие варианты выдает поиск:
archive.codeplex.com/?p=jsonviewer
codebeautify.org/jsonviewer
countwordsfree.com/jsonviewer
В список не могу добавить, к сожалению, т.к. статья посвящена json schema.
Добавила в список «полезностей».
Если откровенно, но мне не очень понятен сценарий. Не затруднит привести пример и пояснить, за счет чего схема станет строже при ее генерации в run-time? Как технически на это влияет заполнение enum на этапе выполнения программы? Очень интересно)
Ваш ход мыслей на тему гениальности приглашает к обсуждению).
Вы мастерски задаете конвергентные вопросы, и мне большого усилия стоит, чтобы не «поконфронтировать» вам немного. Но я удержусь), иначе обсуждение может действительно уйти далеко за пределы обсуждения темы данной статьи).
Спасибо за ваш комментарий)