Должен ли я использовать PKCE для OpenID Connect с приложением Native Desktop?
Я хочу использовать OpenID Connect для своих родных приложений для Windows и Linux для аутентификации пользователей.
Как указано в разделе 7.3 "OAuth 2.0 для собственных приложений", я хочу открыть локальный порт TCP для перенаправления с сервера аутентификации для получения кода авторизации. Я думаю, что нет никакой другой возможности использовать для родных приложений, которые работают как для Windows, так и для Linux.
Таким образом, поток будет выглядеть так:
- Родное приложение запускается и показывает кнопку входа
- Когда кнопка входа нажата
- нативные приложения открывают эфемерный, локальный порт
- браузер открывается со страницей входа провайдера аутентификации (отправка по идентификатору и секретному ключу клиента, перенаправлению URI и области действия openid, response_type=code)
- После успешной аутентификации пользователя в браузере
- поставщик аутентификации перенаправляет на URI перенаправления, который является локальным открытым портом
- локальный порт должен отображать что-то вроде "закрыть браузер сейчас и вернуться к приложению" для пользователя
- Собственное приложение получает код от перенаправления и закрывает порт
- Собственное приложение запрашивает у конечной точки токена идентификационный токен, используя код
- проверить идентификационный токен с помощью подписи
- сможет получить данные пользователя из этого токена
Мой вопрос сейчас мне нужен PKCE? Я нашел эту статью, в которой говорится, что она не приносит никакой дополнительной безопасности, кроме того, чтобы убедиться, что, когда другое приложение на том же устройстве зарегистрировало такое же перенаправление схемы URI частного использования.
Мой план каким-то другим образом ошибочен или нуждается в дальнейшем улучшении? Я понимаю, что идентификатор и секретный код клиента могут рассматриваться как "общедоступные", поскольку они поставляются с программным обеспечением и могут быть подвергнуты обратному проектированию. Но мое программное обеспечение не будет доступно на общедоступных веб-страницах (надеюсь) и будет предоставлено только доверенным клиентам (которые будут иметь разные идентификаторы и секреты клиентов).
2 ответа
OAuth и нативные приложения приносят некоторую сложность. Это связано с тем, что нативные приложения работают изначально, а OAuth использует браузер для завершения процесса. Во-первых, я приветствую вас посмотреть на некоторые другие вопросы и ответы, в которых обсуждались технологии, связанные с нативными приложениями.
С точки зрения протокола, PKCE сделал обязательным. Это обсуждается в рамках нового RFC ( https://tools.ietf.org/html/draft-ietf-oauth-security-topics-12), который скоро будет доступен. С PKCE вы не потеряете код авторизации для вредоносного приложения, которое запускается на компьютере конечного пользователя.
Причина этого заключается в том, что с сервера авторизации он использует только идентификатор клиента и URL-адрес перенаправления для идентификации правильного клиента. Таким образом, если ответ авторизации будет перехвачен, любая сторона может получить токены. PKCE избегает этого, вводя безопасный случайный секрет, который генерируется во время выполнения. Это не сохраняется и передается только в том виде, в каком оно есть в запросе токена, который защищен SSL. Следовательно, PKCE уменьшает вектор угрозы для кражи токенов.
Для собственных приложений регистрация пользовательской схемы URL-адресов является идеальным способом получения ответа на авторизацию. И, как указывают спецификации, объедините его с PKCE.
Я изо всех сил пытался понять потоки рабочего стола также. Я бы порекомендовал частные схемы URI как лучшее решение - у меня есть несколько кросс-платформенных статей, начинающихся здесь, которые могут дать вам некоторые идеи: https://authguidance.com/2018/01/11/desktop-apps-overview/
Не стесняйтесь задавать мне любые вопросы, Гэри