Решил покопать в эту сторону, и поискать, зачем эта информация запрашивается. Вы были правы в вопросе на qna.habr.com. Запрос отпечатка никак не относится к OAuth 2.0. Это требуется для добавления Android App Links, и больше ни для чего. Ну а Package Name используется в качестве client id.
Могу с уверенностью сказать, то в OAuth 2.0 нет никакого упоминания fingerprint'ов для приложений. Более того, если вы попробуете добавить своё приложение в YandexID, к примеру, и выберите отличный тип приложения от Android'а - требования к fingerprint не будет, хотя процесс аутентификации всё равно будет работать через OAuth 2.0.
Ну и по данному вопросу я писал в техподдержку Yandex, где мне подтвердили мои предположения.
Я честно скажу, что не понимаю, что имеется ввиду под android package, но предполагаю, что под SHA имеется ввиду PKCE. Если обратиться к RFC 8252, в котором как раз описывается работа с Native App, то мы увидим, что использование PKCE обязательно для таких приложений (ссылка на RFC, обратите внимание на третий абзац)
Да, на данный момент у нас N cookie для N сервисов.
Cookie не может выдаваться IdentityServer’ом, так как все сервисы находятся на разных доменах.
Важно понимать, что сервис, видя неавторизованного пользователя (рассматриваем сценарий, когда срок жизни cookie истёк), отправляет его на сервер авторизации, и если пользователь там уже аутентифицирован (на самом сервере авторизации), то он будет перенаправлен обратно на сервис в соответствии с Authorization Code Flow. Другими словами, если пользователь пришёл в сервис после окончания жизни cookie, то для него, в общем случае, весь процесс восстановления доступа будет выглядеть как пара редиректов.
В веб-сервисах используется Authorization Code Flow with PKCE с выдачей access и refresh token’ов. Access token используется только для создания набора claim’ов для конкретного сервиса (т.е. получения сведений о пользователе, таких как id, email, телефон и т.д.), которые затем сохраняются в cookie и используются в процессе авторизации пользователя. Refresh token так же сохраняется в cookie, он необходим для проверки сессии (ведь токен могут отозвать) и обновления информации о пользователе. Соответственно все изменения состояния пользователя (редактирование или удаление/блокировка учётной записи) мы получаем в момент этого обновления. Интервал обновления с использованием refresh token’ов у каждого сервиса настраивается отдельно.
Безопасность. Достаточно сложно придумать самостоятельно flow, который будет безопаснее, чем тот, который разрабатывает сообщество, в составе которых есть инженеры по безопасности топовых IT компаний. Кроме того, пользуясь стандартом вы можете залатывать дыры в соответствии с его обновлением раньше, чем пострадает бизнес (вряд ли вы найдёте не очевидную проблему в безопасности собственного протокола до взлома со стороны).
Поддержка. Для своего собственного протокола пришлось бы самостоятельно писать библиотеки. И хорошо, если вы и ваши партнёры пишете на одном языке. В противном случае, вам придётся поддерживать библиотеки на разных языках, что накладно. В случае со стандартом — уже существуют готовые библиотеки для популярных языков программирования. Кроме того, протокол будет развиваться, и документация по нему будет дорабатываться.
Лёгкость в интеграции. Недавно к нашему сервису авторизации подключился один из партнёров. Всё, что понадобилось от нас: настроить client_id, client_secret, выдать scope'ы и сказать, что нужно использовать OAuth 2.0 Authorization Code Flow + PKCE. Если бы у нас был свой протокол, то партнёру пришлось бы в нём разбираться и писать свою бибилиотеку для взаимодействия с кастомным решением, так как на его стороне разработка ведётся на языке, который вне нашего технического стека.
Если мы говорим об этой статье, то тут рассказывается только о OAuth 2.0. OpenID Connect 1.0 здесь не затрагивается совсем. OpenID Connect 1.0 приносит дополнительный Hybrid Flow (по сути немного изменённый Authorization Code flow), новый token с данными о авторизации клиента (ID Token) и, как вы правильно сказали, дополняет OAuth 2.0 уточнениями по реализации
Мы написали свой сервис на основе IdentityServer4. Готовые реализации нам не подходили как минимум из-за того, что мы используем кастомный вариант Device flow. Нам требовалось сделать так, чтобы Device мог жить сам по себе без привязки к пользователю. Плюс мы используем уже существующие базы данных пользователей и кастомный RBAC для прозрачного перехода от одной версии сервиса к другой
Решил покопать в эту сторону, и поискать, зачем эта информация запрашивается. Вы были правы в вопросе на qna.habr.com. Запрос отпечатка никак не относится к OAuth 2.0. Это требуется для добавления Android App Links, и больше ни для чего. Ну а Package Name используется в качестве client id.
Могу с уверенностью сказать, то в OAuth 2.0 нет никакого упоминания fingerprint'ов для приложений. Более того, если вы попробуете добавить своё приложение в YandexID, к примеру, и выберите отличный тип приложения от Android'а - требования к fingerprint не будет, хотя процесс аутентификации всё равно будет работать через OAuth 2.0.
Ну и по данному вопросу я писал в техподдержку Yandex, где мне подтвердили мои предположения.
Я честно скажу, что не понимаю, что имеется ввиду под android package, но предполагаю, что под SHA имеется ввиду PKCE.
Если обратиться к RFC 8252, в котором как раз описывается работа с Native App, то мы увидим, что использование PKCE обязательно для таких приложений (ссылка на RFC, обратите внимание на третий абзац)
Cookie не может выдаваться IdentityServer’ом, так как все сервисы находятся на разных доменах.
Важно понимать, что сервис, видя неавторизованного пользователя (рассматриваем сценарий, когда срок жизни cookie истёк), отправляет его на сервер авторизации, и если пользователь там уже аутентифицирован (на самом сервере авторизации), то он будет перенаправлен обратно на сервис в соответствии с Authorization Code Flow. Другими словами, если пользователь пришёл в сервис после окончания жизни cookie, то для него, в общем случае, весь процесс восстановления доступа будет выглядеть как пара редиректов.