В чём разница между общедоступными и конфиденциальными клиентами?
Эта статья раскрывает различия между общедоступными и конфиденциальными клиентами в OAuth на примере приложений Logto.
При использовании Logto для создания приложения вы заметите, что есть несколько различных типов приложений на выбор, включая одностраничное приложение (SPA), нативное приложение и традиционное веб-приложение. Интуитивно понятно из названия, что нативное приложение работает на операционных системах, которые обычно находятся на таких устройствах, как телефоны. Однако что же такое SPA и традиционное веб-приложение? Почему нам нужно различать эти разные типы приложений? Эта статья раскрывает ответы на эти вопросы.
Прежде чем мы начнем, нам нужно кратко ввести некоторые концепции.
Что такое OAuth?
OAuth — это открытый стандарт делегирования доступа, который обычно используется как способ для интернет-пользователей предоставлять веб-сайтам или приложениям доступ к их информации на других веб-сайтах без предоставления своих паролей.
За последнее десятилетие он постепенно стал стандартным процессом авторизации и был широко принят большинством компаний, таких как Google, Meta, Microsoft и так далее. В настоящее время используется версия OAuth 2.0.
В контексте OAuth, приложение, о котором мы упоминали ранее, называется клиентом. Они могут запрашивать защищенные ресурсы, если они получили авторизацию владельца ресурса (обычно конечные пользователи).
Общедоступные клиенты и конфиденциальные клиенты
OAuth определяет два типа клиентов на основе их способности поддерживать конфиденциальность учетных данных клиента.
Конфиденциальный клиент
Клиент, который способен поддерживать конфиденциальность своих учетных данных (например, клиент, реализованный на безопасном сервере с ограниченным доступом к учетным данным клиента) или тот, кто способен осуществлять безопасную аутентификацию клиента другими средствами.
Общедоступный клиент
Клиент, который не может поддерживать конфиденциальность своих учетных данных (например, клиент, работающий на устройстве владельца ресурса, таком как нативное приложение или веб-приложение) и который также не может безопасно аутентифицироваться в качестве клиента другими средствами.
SPA, нативное приложение и традиционное веб-приложение
На основе вышеупомянутых знаний, давайте посмотрим, что означают SPA, нативное приложение и традиционное веб-приложение в контексте Logto, а также являются ли они общедоступными клиентами или конфиденциальными клиентами.
SPA
Клиентский код SPA загружается с веб-сервера и исполняется в пользовательском агенте (например, веб-браузере) владельца ресурса на его устройстве. Протокольные данные и учетные данные легко доступны (и часто видны) владельцу ресурса.
Нативное приложение
Нативное приложение устанавливается и исполняется на устройстве владельца ресурса. Протокольные данные и учетные данные доступны владельцу ресурса. Обычно предполагается, что любые учетные данные аутентификации клиента, содержащиеся в приложении, могут быть извлечены.
Традиционное веб-приложение
Традиционное веб-приложение — это клиент, который работает на веб-сервере. Владелец ресурса получает доступ к клиенту через HTML интерфейс пользователя, представленный в пользовательском агенте на его устройстве. Учетные данные клиента, а также любые токены доступа, выданные клиенту, хранятся на веб-сервере и не подвергаются разглашению или доступу для владельца ресурса.
Таким образом, мы можем четко видеть, что SPA и нативные приложения являются общедоступными клиентами, тогда как традиционное веб-приложение является конфиденциальным клиентом.
Вы можете заметить, что при создании SPA или нативного приложения в Logto нет секрета приложения, в то время как традиционное веб-приложение имеет как ID приложения, так и секрет приложения. Это потому, что секрет общедоступного клиента не может гарантировать безопасность.
Как клиент работает в потоке авторизации OAuth?
При разработке приложений OAuth первым шагом является регистрация клиента у поставщика услуг OAuth. Регистрация клиента включает предоставление сведений о приложении, таких как его название и URI перенаправления. Затем поставщик услуг OAuth генерирует ID клиента и секрет клиента, которые считаются учетными данными приложения.
ID клиента считаются общедоступной информацией и делятся с пользователем в процессе OAuth. Обычно он включен в URL авторизации и виден конечным пользователям.
С другой стороны, секрет клиента служит паролем для приложения и должен оставаться секретным. Он используется в процессе OAuth для обмена кодом авторизации (предполагая, что это поток кода авторизации) для получения токена доступа. Наличие секретов клиента обеспечивает возможность завершения обмена токенами доступа только зарегистр ированными приложениями.
Введение ключа доказательства для обмена кодом (PKCE)
Как уже упоминалось, секрета клиента общедоступных клиентов не может быть гарантирована безопасностью, и злоумышленники могут получить учетные данные клиента и выдать себя за клиентов для доступа к защищённым ресурсам, что недопустимо в любой ситуации.
PKCE (ключ доказательства для обмена кодом) решает эту проблему, временно генерируя проверочный код в начале каждого потока авторизации, который сохраняется локально и хэшируется для генерации кодового вызова, отправляемого серверу авторизации. Проверочный код отправляется снова серверу авторизации при обмене токенами доступа. Сервер авторизации проверяет соответствие проверочного кода и кодового вызова, что гарантирует, что общедоступный клиент не был подделан.
Проверочный код в PKCE фактически функционирует как динамический секрет клиента. Его безопасность обеспечивается необратимостью хэш-алгоритма.
Резюме
В этой статье мы обсудили концепции конфиденциальных клиентов и общедоступных клиентов в OAuth. Мы узнали, что конфиденциальные клиенты имеют возможность сохранять секреты и безопасно хранить конфиденциальную информацию, в то время как общедоступные клиенты лишены этой возможности. Мы рассмотрели примеры двух типов клиентов, включая традиционные веб-приложения, SPA и нативные приложения в контексте практики продукта Logto.
Мы также обсудили процесс регистрации клиента в OAuth и роли ID клиента и секрета клиента.
Кроме того, мы обнаружили, что общедоступные клиенты сталкиваются с ограничениями в безопасном хранении секретов клиентов. Чтобы преодолеть это ограничение, мы представили PKCE (ключ доказательства для обмена кодом), расширение OAuth, которое позволяет общедоступным клиентам безопасно обмениваться кодом авторизации без необходимости в секрете клиента.
Наш продукт, Logto, является комплексным решением CIAM, которое следует лучшим практикам протоколов OAuth и OIDC, чтобы обеспечить безопасность на каждом этапе, включая использование PKCE для защиты безопасности общедоступных клиентов.