Комментарии 19
С нетерпением жду рассказ про is4.
Вам не кажется, что свой велосипед был бы сильно проще в разработке, поддержке и использовании?
- Безопасность. Достаточно сложно придумать самостоятельно flow, который будет безопаснее, чем тот, который разрабатывает сообщество, в составе которых есть инженеры по безопасности топовых IT компаний. Кроме того, пользуясь стандартом вы можете залатывать дыры в соответствии с его обновлением раньше, чем пострадает бизнес (вряд ли вы найдёте не очевидную проблему в безопасности собственного протокола до взлома со стороны).
- Поддержка. Для своего собственного протокола пришлось бы самостоятельно писать библиотеки. И хорошо, если вы и ваши партнёры пишете на одном языке. В противном случае, вам придётся поддерживать библиотеки на разных языках, что накладно. В случае со стандартом — уже существуют готовые библиотеки для популярных языков программирования. Кроме того, протокол будет развиваться, и документация по нему будет дорабатываться.
- Лёгкость в интеграции. Недавно к нашему сервису авторизации подключился один из партнёров. Всё, что понадобилось от нас: настроить client_id, client_secret, выдать scope'ы и сказать, что нужно использовать OAuth 2.0 Authorization Code Flow + PKCE. Если бы у нас был свой протокол, то партнёру пришлось бы в нём разбираться и писать свою бибилиотеку для взаимодействия с кастомным решением, так как на его стороне разработка ведётся на языке, который вне нашего технического стека.
Возможно у вас cookie может выдаваться identity сервером, тогда сервисы должны как-то уметь ее расшифровывать. Значит должна быть система распространения и отзыва ключей шифрования. Еще это значит, что каждый сервис должен уметь генерировать cookie если пришел запрос с истекшей cookie, в которой есть живой refresh token. Но вы говорите, что «Access token используется только для создания набора claim’ов для конкретного сервиса», значит ли это, что действительно у вас N cookie для N сервисов?
Cookie не может выдаваться IdentityServer’ом, так как все сервисы находятся на разных доменах.
Важно понимать, что сервис, видя неавторизованного пользователя (рассматриваем сценарий, когда срок жизни cookie истёк), отправляет его на сервер авторизации, и если пользователь там уже аутентифицирован (на самом сервере авторизации), то он будет перенаправлен обратно на сервис в соответствии с Authorization Code Flow. Другими словами, если пользователь пришёл в сервис после окончания жизни cookie, то для него, в общем случае, весь процесс восстановления доступа будет выглядеть как пара редиректов.
Это не совсем комментарий. Скорее вопрос по теме OIDC Auth для мобильных клиентов.
Пытаюсь выяснить для чего сервера OIDC просят android package + SHA при создании авторизации для приложения android. Ну и аналогично для iOS, Windows. В спеке не нашел, в гугле не нагуглил. На вопрос никто не ответил. Even on stack overflow. Я хотел начать смотреть код OSS OIDC сервера, но вы то уже, наверное, все посмотрели и можете легко сказать зачем же это все нужно и как это работает.
Я честно скажу, что не понимаю, что имеется ввиду под android package, но предполагаю, что под SHA имеется ввиду PKCE.
Если обратиться к RFC 8252, в котором как раз описывается работа с Native App, то мы увидим, что использование PKCE обязательно для таких приложений (ссылка на RFC, обратите внимание на третий абзац)
Под android package имеется ввиду не что иное, как android package - не знаю, как сказать по-другому. Под SHA имеется ввиду "Отпечаток сертификата для Android", как это называют в VK или "SHA-1 certificate fingerprint", как это называют в google или хэш-ключи Android, как это называют в facebook. SHA1 хэш ключа, которым вы подписываете свое приложение перед тем, как отправлять его в store.
Если вы захотите добавить "вход через VK" в свое android приложение, то для этого вам надо будет зайти на сайт vk для разработчиков, добавить там свое приложение и указать "Название пакета для Android", "Main activity для Android", "Отпечаток сертификата для Android". Вам предоставят ID приложения, "Защищённый ключ", "Сервисный ключ доступа". И это справедливо для любого типа нативного приложения (Windows, iOS) и для всех OIDC провайдеров (facebook, yandex, twitter, github и пр.) - то есть все провайдеры просят предоставить эту информацию. Ну и мне непонятно, как сервером используется информация "Название пакета для Android", "Main activity для Android", "Отпечаток сертификата для Android" в OIDC протоколе. Я постарался внимательно прочитать все RFC по OIDC, задал вопросы на Хабр Q&A, Stack overflow и никто не ответил, так что до сих пор непонятно.
В RFC 8252 (OAuth 2.0 for Native Apps) я вижу только предпочтительный flow для native apps и необходимость использовать PKCE.
RFC 7636 (PKCE - Proof Key for Code Exchange by OAuth Public Clients) добавляет верификацию вместо секретного ключа в OIDC flow - для того, чтобы перехват первоначального ответа не позволил злоумышленнику получить доступ.
Как используется android package и sha-1 certificate fingerprint непонятно. Исходные данные похожи на те, что используют в verified android app links.
Похоже самым простым способом ответить на этот вопрос будет взять исходники OSS OIDC Authorization Server и посмотреть.
Решил покопать в эту сторону, и поискать, зачем эта информация запрашивается. Вы были правы в вопросе на qna.habr.com. Запрос отпечатка никак не относится к OAuth 2.0. Это требуется для добавления Android App Links, и больше ни для чего. Ну а Package Name используется в качестве client id.
Могу с уверенностью сказать, то в OAuth 2.0 нет никакого упоминания fingerprint'ов для приложений. Более того, если вы попробуете добавить своё приложение в YandexID, к примеру, и выберите отличный тип приложения от Android'а - требования к fingerprint не будет, хотя процесс аутентификации всё равно будет работать через OAuth 2.0.
Ну и по данному вопросу я писал в техподдержку Yandex, где мне подтвердили мои предположения.
Спасибо за статью! Есть уточнения по терминам на схеме - см. картинку., точно ли там не user code должен быть?
И в тексте в статье ниже: Verification URI и Redirection URI - это же про одно?
Тонкости авторизации: обзор технологии OAuth 2.0