Должен ли я использовать PKCE для OpenID Connect с приложением Native Desktop?

Question

Я хочу использовать OpenID Connect для своих собственных приложений Windows и Linux для настольных компьютеров для аутентификации моих пользователей.

Как указано в «OAuth 2.0 для собственных приложений», раздел 7.3 Я хочу открыть локальный TCP-порт для перенаправления с сервера аутентификации для получения кода авторизации. Я думаю, что нет никакой другой возможности использовать для родных приложений, которые работают как для Windows, так и для Linux.

Таким образом, поток будет выглядеть так:

• Нативное приложение запускается и показывает кнопку входа в систему
• при нажатии кнопки входа
  • нативные приложения открывают эфемерный локальный порт
  • открывается браузер со страницей входа в систему провайдера аутентификации (отправка по идентификатору клиента и его секрету, URI перенаправления и openid, response_type = code)
• После успешной аутентификации пользователя в браузере
  • поставщик аутентификации перенаправляет на URI перенаправления, который является локальным открытым портом
  • локальный порт должен отображать что-то вроде «закройте браузер сейчас и вернитесь в приложение» для пользователя
• Собственное приложение получает код от перенаправления и закрывает порт
• Собственное приложение запрашивает у конечной точки токена идентификационный токен, используя код
  • подтвердить идентификационный токен с помощью подписи
  • сможет получить данные пользователя из этого токена

У меня сейчас вопрос: нужен ли мне PKCE? Я нашел эту статью , в которой говорится, что она не приносит никакой дополнительной безопасности, кроме проверки того, что когда другое приложение на том же устройстве имеет зарегистрировал тот же перенаправление схемы URI частного использования .

Является ли мой план каким-либо иным способом некорректным или нуждается в дальнейшем улучшении? Я понимаю, что идентификатор и секретный код клиента можно рассматривать как "общедоступные", поскольку они поставляются с программным обеспечением и могут быть подвергнуты обратному проектированию. Но мое программное обеспечение не будет доступно на общедоступных веб-страницах (надеюсь) и будет предоставлено только доверенным клиентам (у всех будут разные идентификаторы и секреты клиентов).

Answer 1

OAuth и нативные приложения приносят некоторую сложность.Это связано с тем, что нативные приложения работают изначально, а OAuth использует браузер для завершения процесса.Во-первых, я приглашаю вас взглянуть на некоторые другие вопросы и ответы , где обсуждались технологии, связанные с нативными приложениями.

С точки зрения протокола, PKCE сделал обязательным.Это обсуждается в рамках нового RFC ( draft-ietf-oauth-security-themes-12 ), который скоро будет доступен.С PKCE вы не потеряете код авторизации для вредоносного приложения, которое запускается на компьютере конечного пользователя.

Причина этого заключается в том, что с сервера авторизации он использует только идентификатор клиента и URL-адрес перенаправления для идентификации правильного клиента.Таким образом, если ответ авторизации будет перехвачен, любая сторона может получить токены.PKCE избегает этого, вводя безопасный случайный секрет, который генерируется во время выполнения.Это не сохраняется и передается только в том виде, в каком оно есть в запросе токена, который защищен SSL.Следовательно, PKCE уменьшает вектор угрозы для кражи токенов.

Для нативных приложений регистрация пользовательской схемы URL является идеальным способом получения ответа авторизации.И, как указывают спецификации, объедините его с PKCE.

Answer 2

Я изо всех сил пытался понять потоки рабочего стола. Я бы порекомендовал частные схемы URI как лучшее решение - у меня есть несколько кросс-платформенных статей, которые могут дать вам некоторые идеи: https://authguidance.com/2018/01/11/desktop-apps-overview/

Не стесняйтесь задавать мне вопросы, Гэри