Почему вашему продукту нужны OAuth 2.0 и OIDC — особенно в эпоху ИИ

С самого начала Logto был создан с твердым убеждением в открытых стандартах. Мы решили следовать таким протоколам, как OIDC, OAuth 2.0 и SAML — не только потому, что они широко используются, но и потому, что они представляют собой хорошо зарекомендовавшие себя, безопасные практики, которым доверяют в индустрии. Безопасность всегда была для нас приоритетом. Такой же важностью мы предавали духу открытого исходного кода и следованию лучшим практикам в Управлении идентичностью клиентов и современной аутентификации.

Но по дороге мы также узнали кое-что:

OAuth 2.0 и OIDC не просты для всех. Для разработчиков, которые только знакомятся с этими протоколами, концепции могут казаться чуждыми и иногда даже контринтуитивными. Это вызвало реальные проблемы, когда мы пытались упростить опыт разработчика, не уступая в безопасности.

Две вещи выделялись:

1. Даже несмотря на наши усилия сделать интеграцию максимально гладкой, есть еще кривая обучения вокруг понимания базовых концепций, таких как ID токены, токены доступа и их взаимосвязь.
2. Обычный вопрос, который мы получаем: «Могу ли я пропустить перенаправление на экран входа?» К сожалению, перенаправление — это основная часть работы OIDC и необходимость для безопасной аутентификации.

Обычный вопрос от наших пользователей в Discord (с их ID и аватаром, замаскированных для конфиденциальности).

Каждое решение идет с компромиссами — но иногда выбор, сделанный на раннем этапе, оказывается особенно ценным, когда появляются новые случаи использования. И теперь мы вступаем в новую эпоху: эпоху ИИ.

В этой статье я рассмотрю, когда ваш продукт должен использовать OIDC и OAuth 2.0, когда они могут не понадобиться, и почему я всегда пропагандировал принятие этих открытых стандартов с самого начала — особенно если вы строите реальный бизнес и выбираете CIAM-решение. Я также объясню, почему с появлением ИИ это решение становится более важным, чем когда-либо.

Что действительно делает OAuth 2.0 (с простой аналогией)#

Для читателей, не очень знакомых с OAuth 2.0, позвольте мне кратко пройтись по нескольким основным концепциям — чтобы сделать их яснее.

OAuth 2.0 предназначен для делегирования авторизации: OAuth 2.0 — это промышленный стандарт для авторизации – он позволяет одному сервису получать доступ к ресурсам другого сервиса с согласия владельца ресурса.

В сценарии OAuth пользователь (владелец ресурса) предоставляет клиентскому приложению ограниченный доступ (определенные разрешения) к API или серверу ресурсов, не делясь своим паролем. OAuth определяет, как запросить и выдать токены доступа, которые клиент может использовать для вызова защищенных API. Это было поворотным моментом по сравнению с ранними днями, когда приложения могли запрашивать ваш учетные данные для доступа к другому сервису (серьезный риск безопасности). С OAuth 2.0 пользователи одобряют конкретный доступ, а клиент получает токен только с необходимыми разрешениями и длительностью — пароли не передаются, что значительно улучшает безопасность.

Представьте OAuth 2.0, как заселение в отель.

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

Персонал отеля (OAuth-система) выдает эту ограниченную карту с определенными правилами:

• Она работает только для спортзала (определенного ресурса).
• Она действительна на короткое время.
• Она не позволяет никому войти в вашу комнату.

Таким образом, вам не нужно отдавать свой мастер-ключ — и система остается безопасной, даже если кто-то другой завладеет этой ограниченной картой.

Рассмотрим другой пример. OAuth 2.0 широко используется в сценариоях входа через социальные сети.

Допустим, вы регистрируетесь в новом приложении, например, Notion, и вместо создания нового имени пользователя и пароля нажимаете «Продолжить с Google».

Вот что происходит под капотом с OAuth 2.0:

1. Вы перенаправляетесь на страницу входа Google, где вы входите (если еще не вошли).

2. Google спрашивает:

   «Разрешаете ли вы этому приложению просматривать ваш основной профиль и адрес электронной почты?»

3. Вы нажимаете «Разрешить», и Google отправляет приложению токен доступа.

4. Приложение использует этот токен для:

   • Подтверждения вашей личности (по вашему адресу электронной почты и информации профиля).
   • Создания или входа в вашу учетную запись — без видимости вашего пароля Google.

Что действительно делает OIDC (с простой аналогией)#

Теперь давайте взглянем на OIDC — более новый и более продвинутый стандарт. OpenID Connect нацелен на идентичность и аутентификацию: это слой аутентификации, построенный поверх OAuth 2.0. В то время как OAuth 2.0 сам по себе не сообщает приложению, кто является пользователем (он касается только токенов доступа и объемов), OIDC добавляет стандартный способ обработки входа пользователей и идентичности.

При использовании OIDC сервер авторизации также действует как OpenID-провайдер (провайдер идентичности), который аутентифицирует пользователя и выдает ID-токен, содержащий информацию о пользователе (утверждения идентичности).

Короче говоря, OAuth 2.0 отвечает на вопрос «Может ли этот клиент получить доступ к этому ресурсу?», а OIDC отвечает на вопрос «Кто является пользователем, который только что вошел?». Вместе они позволяют вашему приложению проверить личность пользователя, а затем использовать авторизованные токены для доступа к API от имени пользователя.

Давайте используем аналогию с отелем, чтобы лучше понять OAuth 2.0 и OIDC.

Представьте, что вы заезжаете в отель.

• OAuth 2.0 — это как просить отель разрешить вашему другу использовать спортзал и бассейн от вашего имени.

  Вы подходите на стойку регистрации, даете разрешение, и отель выдает вашему другу гостевую карту.

  Отель не заботится, кто этот друг — просто о том, что ему разрешено использовать объекты.

  👉 Это OAuth: «Это приложение может получить доступ к части моих данных или услуг.»

• OIDC — это как просить отель выяснить, кто этот человек, прежде чем давать им доступ.

  Так ваш друг также предъявляет удостоверение личности — и теперь отель знает его имя, статус и что он проверенный гость.

  👉 Это OIDC: «Вот кто является пользователем, и теперь он вошел в систему.»

Как Logto использует OAuth 2.0 и OpenID Connect (OIDC)#

Основные функции аутентификации Logto построены на OIDC (OpenID Connect)#

В основе Logto лежит OpenID Connect (OIDC) провайдер — стандарт, построенный на базе OAuth 2.0, который сосредоточен на безопасной, современной аутентификации пользователей. Logto — это профессиональное CIAM-решение, где идентичности являются основными строительными блоками, которые мы управляем.

Мы разработали Logto с основы на безопасности. Это означает, что по умолчанию мы используем PKCE, блокируем небезопасные потоки, такие как неявный поток, и полагаемся на перенаправление для безопасной обработки входов.

Почему перенаправление?#

OIDC предназначен для аутентификации на основе браузера. Это не просто технический выбор — это о предоставлении пользователям безопасного, согласованного опыта на разных платформах. Перенаправление пользователя к провайдеру идентичности (например, Logto, Google или Microsoft) помогает сделать это возможным.

Вот как выглядит типичный поток:

1. Пользователь нажимает «Войти»

   → Ваше приложение отправляет их на страницу входа Logto.

2. Они безопасно входят в систему

   → Здесь происходят вещи, такие как MFA, биометрия или вход через социальные сети.

3. Logto отправляет их обратно

   → В комплекте с безопасным токеном или авторизационным кодом.

4. Ваше приложение завершает вход

   → Токен проверяется, и пользователь входит в систему.

Этот шаблон может показаться простым, но он приносит мощные преимущества:

• Ваше приложение не обрабатывает учетные данные напрямую — что означает меньше рисков.
• Легче добавить функции, такие как MFA, не меняя код приложения.
• Это отлично работает и для мобильных устройств:
  • iOS использует ASWebAuthenticationSession
  • Android использует Custom Tabs

И если ваш продукт охватывает несколько приложений, перенаправление позволяет использовать единый вход — пользователи входят один раз и перемещаются между приложениями без трения.

Logto не поддерживает сбор паролей напрямую в вашем приложении. Это намеренно. Поток ROPC не рекомендуется для лучших практик безопасности OAuth 2.0 по веским причинам — он менее безопасен и сложнее безопасно масштабировать.

Logto также является провайдером OAuth 2.0/OIDC (Identity Provider)#

Logto — это больше, чем просто сервер аутентификации — это полный OAuth 2.0, OpenID Connect (OIDC) и провайдер идентичности (IdP). Это означает, что он может безопасно управлять идентичностями пользователей и выдавать токены, которым доверяют другие приложения.

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

Что это значит на практике?

Как провайдер идентичности (IdP), Logto обрабатывает проверку пользователей, управляет учетными данными и выдает токены аутентификации. Как только пользователь входит в систему, Logto может позволить им получить доступ к различным приложениям — даже от других поставщиков — без повторного входа. Это та же концепция за «Войти с Google» или «Войти с Microsoft».

В этом контексте есть два типа приложений:

• Собственные приложения: Приложения, которые вы создаете и полностью контролируете, прямо интегрируя с Logto.
• Сторонние приложения: Внешние сервисы, созданные партнерами или разработчиками за пределами вашей организации.

Logto позволяет вашим пользователям входить в эти сторонние приложения, используя свои существующие учетные записи Logto — так же, как корпоративные пользователи входят в такие инструменты, как Slack, используя свои учетные данные Google Workspace. Это позволяет вам:

• Предлагать единый вход (SSO) по всей вашей экосистеме.
• Создать открытую платформу, где сторонние разработчики могут добавлять «Войти с Logto» в свои приложения.

Когда действительно нужны OAuth 2.0 и OIDC?#

1. Если вы ранее использовали Auth0 (и подобные): Auth0 уже является провайдером OAuth 2.0 и OIDC. Он управляет входом пользователей, выдачей токенов и интегрируется с вашими API или приложениями.
2. M2M авторизация: Сервер-к-серверу (поток клиентских учетных данных) Машины (или серверные службы) должны безопасно общаться без участия пользователя.
3. Поток устройств: Смарт-ТВ, консоли, IoT устройства: Такие устройства, как телевизоры или принтеры, нуждаются в аутентификации пользователя. Поток устройств является частью OIDC.
4. У вас есть потребности в взаимодействии: Вы не только аутентифицируете пользователей — вы создаете экосистему, где внешние приложения, партнеры или агенты могут интегрироваться с вашей платформой и безопасно получать доступ к данным пользователей.

Почему OAuth и OIDC важны как никогда в эпоху ИИ#

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

1. Удаленные MCP-серверы

   Вы создаете удаленный MCP (Model Context Protocol) сервер и хотите, чтобы сторонние агенты подключались к нему. Эти агенты нуждаются в безопасном доступе для запроса контекста, выполнения действий и обмена данными — все это без компрометации доверия пользователя. OAuth предоставляет механизм для безопасного делегирования доступа.

2. Открытие вашего продукта для интеграций

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

3. Создание собственного агента

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

4. Рост умных устройств

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

Когда вам может не понадобиться OAuth 2.0/OIDC#

Конечно, есть случаи, когда вам может не понадобиться OAuth 2.0 или OIDC — по крайней мере, пока. Другими словами, если ваше текущее использование простое или полностью автономное, эти протоколы могут не принести немедленной ценности.

Однако по мере роста вашего продукта или расширения вашей экосистемы потребность в OAuth 2.0 и OIDC часто становится гораздо более очевидной в долгосрочной перспективе.

1. Простые внутренние приложения

   Если ваше приложение используется только небольшой командой внутри компании и не требует интеграции со сторонними сервисами или раскрытия API, базовая система аутентификации по имени пользователя и паролю (например, сеансы cookie) может быть достаточной.

2. Нет необходимости в аутентификации пользователей

   Если у вашего продукта нет учетных записей пользователей или функций, связанных с идентичностью — таких как публичный контентный сайт или сервер-к-серверный инструмент с статическими API-ключами — OIDC не нужен.

3. Нет необходимости в делегированном доступе

   OAuth отлично справляется в тех случаях, когда вам нужно, чтобы пользователи авторизовали ваше приложение для доступа к их данным в другой системе (например, Google Drive). Если вы не интегрируетесь со сторонними API или не строите мультисервисные рабочие потоки, OAuth добавляет сложность с минимальной пользой.

4. Одинокая среда, минимальный риск

   Для прототипов на ранних стадиях, MVP или внутренних тестовых инструментов, где простота и скорость перевешивают потребности в безопасности, вы можете отложить внедрение OAuth/OIDC до более позднего времени.

Заключительные мысли по выбору правильной стратегии аутентификации#

Вам не обязательно сразу понадобиться OAuth 2.0 или OIDC — и это совершенно нормально. На ранних стадиях простые решения часто справляются с задачей. Но по мере роста вашего продукта, по мере увеличения интеграции агентов и ИИ в то, как мы строим, и по мере открытия вашей экосистемы для партнеров и третьих сторон, безопасная и стандартизованная аутентификация становится меньше желаемым и больше необходимым.

Вместо того чтобы догонять позже, стоит заложить фундамент сейчас. Принятие OAuth 2.0 и OIDC — это не только решение сегодняшних проблем, но и подготовка к тому, что грядет.