Возможно, вам не нужен OAuth2/OpenID Connect: вот почему

Возможно, вам не нужны OAuth2 или OpenID Connect. Это спорное мнение, тем более что мой самый большой профессиональные достижения — два самых успешных проекта с открытым исходным кодом в мире OAuth2 и OpenID Connect:

* Ory Hydra (запущен в 2015 г.)

* Ори Фосайт (запущен в 2016 г.)

Эти два проекта помогли создать компанию, которая подняла серию А, и экосистему с открытым исходным кодом, которой пользуются миллионы.

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

При написании и поддержке Ory Hydra и Ory Fosite я провел большую часть своей жизни, работая с большим сообществом разработчиков и разбираясь во всех случаях использования и проблемах, с которыми сталкиваются пользователи при работе с аутентификацией и авторизацией.

Как компания, мы также помогаем другим проводить аудит и проверку их систем. Таким образом, мы часто видим, что OAuth 2 и OIDC используются в неправильном контексте. Это происходит не потому, что люди совершают ошибки или не «понимают» безопасность. Это происходит потому, что протоколы сложны и часто довольно расплывчаты.

При использовании в неправильном контексте — что часто бывает — это может привести к серьезным уязвимостям в системе безопасности.

На данный момент мы выявили более 12 случаев, когда неправильная реализация OAuth2 и OpenID Connect приводила к проблемам безопасности с низким уровнем серьезности (например, выход из системы не аннулировал сеансы должным образом), а также к катастрофическим уязвимостям (таким как захват учетной записи с полным повышением административных привилегий). ).

Страшно то, что это может случиться с любой компанией любого размера, независимо от того, насколько талантливы их разработчики!

Если единственным инструментом, который у вас есть, является молоток, вы склонны рассматривать любую проблему как гвоздь. - "Молот Маслоу"

В Ory мы не продаем OAuth2 и OpenID Connect как «святой Грааль». Хотя эти два протокола являются очень мощными при правильном использовании и имеют много преимуществ и вариантов использования, правда в том, что они не всегда необходимы. На самом деле они вам, скорее всего, не нужны.

Прежде чем мы продолжим, имейте в виду, что существует два основных варианта использования OAuth2/OpenID Connect, и что в этой статье рассматривается только один из них:

1. Если вы являетесь пользователем OAuth2/OpenID Connect: вы реализуете функцию "Войти с помощью Google", вам нужен доступ к учетной записи GitHub пользователя и другие варианты использования. Здесь OAuth2 имеет массу смысла. В этой статье этот вариант использования не рассматривается.

2. Будучи поставщиком OAuth2 / OpenID Connect: вы хотите стать системой, выпускающей токены доступа OAuth2, токены идентификатора OpenID Connect и т. д. Эта статья для вас!

Теперь, когда мы подготовили сцену, давайте посмотрим на структуру этой статьи. Подобно OAuth2 и OpenID Connect (и сопутствующим RFC8252, RFC6819, RFC7636, RFC8628, RFC 7523, OpenID Connect Discovery, OpenID Connect Session Management, OpenID Connect Front-/Backchannel Logout, ...), эта статья длинная, потому что OAuth2 и OpenID Connect охватывают множество спецификаций и регулярно порождают новые, инновационные.

Давайте рассмотрим основные моменты, затронутые в этой статье.

1. Дерево решений tl;dr, которое поможет вам решить, нужен вам OAuth2 или нет.

2. Когда OAuth2 и OpenID Connect полезны и в чем их проблемы?

3. Какие неправильные представления у разработчиков об OAuth2 и OpenID Connect?

4. Когда следует избегать OAuth2 и OpenID Connect?

Прежде чем углубиться, я хочу подчеркнуть два момента:

1. Мы с большим уважением относимся к количеству инноваций, созданных исследователями и участниками в области OAuth2 и OpenID Connect. Эта статья не пытается преуменьшить их впечатляющую работу. Скорее, мы намерены изменить мышление малых и средних команд с "нам нужна эта сложная штука для обеспечения безопасности" на "мы можем решить эту сложную проблему на более позднем этапе и использовать что-то действительно простое сейчас!"

2. Ory разрабатывает службу инфраструктуры идентификации с открытым исходным кодом под названием Ory Kratos, которая доступна как управляемый облачный сервис. В этой статье обсуждаются многие причины, которые изначально побудили нас разработать эту новую систему. Так что да, это бессовестная самостоятельная вилка. Но также: это то, во что мы верим! В мире программного обеспечения есть место для безопасного, надежного, масштабируемого и простого решения. Наша цель в Ory — разработать открытый стандарт с помощью блестящего сообщества. Нам нужно что-то, что работает в 80 % случаев использования.

Нужен ли вам OAuth2 или OpenID Connect?

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

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

Но это не значит, что нет лучшего способа решить эти проблемы! Попытка Ори создать лучший де-факто открытый стандарт аутентификации личности — это проект с открытым исходным кодом Ory Kratos!

Общее дерево решений, которое поможет вам решить, нужен вам OAuth2 или нет, можно резюмировать следующим образом:

Поскольку вы читаете это на веб-сайте Ory, и мы верим в продукты, которые мы производим, вы найдете их на графике выше. Для сопоставимых продуктов мы собрали следующие с открытым исходным кодом:

1. Если вам нужна как платформа для идентификации (что означает, что вам, скорее всего, также потребуется перенести пользовательские данные), так и OAuth2 & OpenID Connect Connect и хотите использовать OAuth2 / OpenID Connect для всего, ознакомьтесь с Keycloak от RedHat. KeyCloak — это как если бы вы использовали платформу Ory Identity Platform и платформу Ory OAuth2/OpenID Connect вместе, используя только OAuth2 & OpenID Connect для «аутентификации».

2. Если вам нужна только платформа идентификации без OAuth2, есть несколько альтернатив платформе идентификации Ory / Ory Kratos:

1. Библиотеки для конкретных языков, такие как authboss, с плюсами и минусами библиотек для конкретных языков.

   2. ~~Супертокены~~ — мы больше не поддерживаем их из-за сомнительного выбора смешивания терминологии OAuth2 с собственными протоколами. В частности, использование терминологии OpenID без поддержки самой спецификации, а также использование «токенов доступа» и «токенов обновления» в некорректных контекстах. Мы считаем, что это то, что Скотт Брэди называет MyOwnOAuth™.

Когда OAuth2 & Open ID Connect полезен?

Основной вариант использования OAuth2 указан в первом разделе (аннотации) его RFC:

Среда авторизации OAuth 2.0 позволяет стороннему приложению получать ограниченный доступ к службе HTTP либо от имени владельца ресурса организовав взаимодействие для утверждения между владельцем ресурса и службой HTTP или разрешив стороннему приложению получать доступ от своего имени.

OAuth 2 был изобретен для удовлетворения потребностей эпохи Web 2.0. Такие платформы, как Google и Facebook, имеют огромные массивы данных, и они хотели открыть эти данные для третьих лиц.

Иногда это использовалось во благо (например, Facebook Games), а иногда и со злоупотреблениями (например, Скандал с Cambridge Analytica). ).

Кроме того, в 2012 году «Вход через социальные сети» был конфиденциальность/">все помешательство. (и до сих пор!)

OAuth2 и OpenID Connect созданы для решения этих двух основных задач:

1. Разрешить третьим лицам доступ к вашим данным, например, Facebook (OAuth2).

2. Разрешить третьим лицам аутентифицировать вас, например, с помощью вашей учетной записи Facebook (OpenID Connect).

Почему OAuth2 – это не аутентификация для третьей стороны, а OpenID Connect

Если вы новичок в OAuth2, может возникнуть путаница, зачем вам нужен OpenID Connect. Они взаимосвязаны, но различны. Основным отличительным фактором является аудитория полученных токенов:

1. Токены OAuth2 (токен доступа OAuth2) используют сторонний сервер в качестве целевой аудитории.

2. Токены OpenID Connect (ID Token) имеют стороннего клиента в качестве целевой аудитории.

OAuth2 не является аутентификацией. Маркеры доступа не являются сеансами.

OpenID Connect был изобретен или добавлен поверх OAuth2, потому что токены OAuth2 непрозрачны — не прозрачны — для сторонних клиентов, которые их получают.

Они не служат никакой цели, кроме представления их на стороннем сервере (например, GitHub) и ожидания ответа (например, в личных репозиториях пользователя).

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

1. Боб создает приложение "myphotobook", которое предлагает "Войти через Facebook". Он принимает токены доступа в качестве доказательства аутентификации по адресу https://myphotobook.com/login?access_token <facebook_token>.

2. Ева создает приложение "myeviapp", которое также предлагает "Войти через Facebook".

3. Если Алиса использует оба приложения, Ева может использовать токен доступа Алисы из «myeviapp», чтобы выдать себя за нее в приложении Боба, позвонив; например, https://myphotobook.com/login?access_token=<alices_myevilapp_facebook_token>.

Есть способы предотвратить эту атаку, используя стандартные механизмы OAuth2. Обеспечение того, чтобы токен доступа был инициирован «myphotobook», является эффективным средством защиты. Но это требует глубокого знания задействованных протоколов, и это неявно. В безопасности нам не нравится неявное.

OpenID Connect решает эту проблему, вводя новый тип токена вместе с дополнительными параметрами конфигурации, которые затем могут использоваться третьей стороной для надежной и безопасной аутентификации пользователей.

Вот почему токены OpenID Connect ID прозрачны — их можно использовать — для сторонних клиентов; это потому, что они представляют собой веб-токены JSON, которые можно декодировать. Кроме того, токены идентификаторов содержат аудиторию — в данном случае третью сторону, а не первую сторону.

Таким образом, "myphotobook" может проверить, является ли аудитория "myphotobook", а не "myeviapp":

// Example ID Token Payload
{
  iss: "https://myphotobook.com",
  sub: "alice",
  // OK:
  aud: ["myphotobook"],
  // NOT OK:
  aud: ["myevilapp"],
  exp: 1516239022,
  iat: 1516239022,
}

Третье лицо, третье лицо, третье лицо!

К настоящему моменту вы довольно часто читали слово "третья сторона". И это улов! Эти протоколы ориентированы на стороннюю интеграцию. Это означает, что кто-то другой пытается получить доступ к данным вашего пользователя. И кто-то еще пытается аутентифицировать своих пользователей, используя ваши данные!

Ваш первый пункт решения именно это. Вы создаете систему, которая взаимодействует с третьими сторонами, такими как партнерские сети и API-интерфейсы платформы? Или вы сами становитесь очередным "Войти с..."?

Если это так, то OAuth2 и OpenID Connect — лучшие в своем классе протоколы для решения ваших задач!

Избегайте OAuth2/OpenID Connect для сторонних приложений (с исключениями)

Независимо от того, создаете ли вы мобильное приложение, одностраничное приложение, веб-приложение, нативное приложение, систему API или вам нужны токены Bearer или веб-токены JSON. Вам, скорее всего, сейчас не нужна сложность OAuth2 и OpenID Connect.

Скорее всего, вам нужна система, которая предлагает различные методы аутентификации пользователей (пароль, без пароля, FIDO2, биометрия, SMS, ...), имеет управление профилями, восстановление учетной записи, сброс пароля, проверку электронной почты и номера телефона и так далее.

Вы всегда можете добавить OAuth2 и OpenID Connect поверх существующей инфраструктуры аутентификации с помощью таких инструментов, как Ory Hydra.

Исключения

Конечно, есть исключения из правил. В некоторых случаях имеет смысл сразу начать с OAuth2 и OpenID Connect.

Это может иметь место для крупных предприятий, таких как Apple или Amazon, в которых работают сотни тысяч сотрудников в сотнях команд, организаций и офисов.

В этих случаях офис A (Google Mail) может не доверять офису B (Google Earth) доступ к данным без согласия пользователя. Крупные организации могут позволить себе дополнительные расходы на обучение, внедрение, тестирование и обслуживание сложных систем.

Но даже в этом случае — войдите в свой профиль Google, и вы не увидите OAuth2 или OpenID Connect, а вместо этого обычный процесс входа в систему: отправьте HTML-форму на сервер и получите файл cookie!

Контрпримером этого является Amazon, который использует OpenID Connect для входа в свой магазин Amazon.

Нишевые клиенты

Еще одно исключение — если вы планируете взаимодействие с большим количеством клиентов разных типов. Это, в частности, относится к клиентам, у которых нет традиционного пользовательского интерфейса (подумайте о Fire TV Stick, Chromecast или о чем-то, что не имеет клавиатуры/порта USB или браузера).

В этом случае вы можете извлечь выгоду из работы, проделанной IETF и OpenID Foundation, которые определили взаимодействие для этих типов клиентов.

Вот некоторые примеры нишевых клиентов:

* SmartTV, потому что у них нет клавиатуры, мыши или USB-порта (например, YubiKeys), что делает вход в систему и регистрацию неприятными или невозможными.

* Интерфейсы командной строки, когда они должны использовать ваш красивый веб-сайт и формы входа (с несколькими факторами аутентификации) для входа пользователей.

Интеграция со многими другими сервисами

Добавление OAuth2 и OpenID Connect в вашу систему, если вы не используете их в качестве основной системы аутентификации для своих собственных служб, полезно, если вы используете другие инструменты и службы, которые должны использовать центральную платформу идентификации для аутентификации пользователей.< /p>

Примерами таких инструментов могут быть:

* Rocket Chat, где пользователи регистрируются в службе и также могут войти в комнату чата, войдя в Rocket Chat с помощью вашего сервера OpenID Connect.

* Инструменты SaaS, предлагающие корпоративные планы единого входа, например Форма шрифта.

* Другие программные продукты, предлагающие единый вход через OpenID Connect.

В этих случаях вы должны взвесить, хотите ли вы использовать одну методологию аутентификации для первых сторон и другую (OpenID Connect) для третьих сторон, или вы хотите использовать OpenID Connect для обоих.

Это решение во многом зависит от контекста, но ни один из двух вариантов не является более или менее сложным для реализации.

Первые и третьи лица одновременно

Исключением из этого правила является случай, когда вы планируете добавить OAuth2 в свою систему для обслуживания третьих лиц. В этом случае вы можете сэкономить время и усилия, используя OpenID Connect и избавляясь от необходимости реализовывать два механизма аутентификации.

Решение здесь не однозначно и во многом зависит от контекста. Реализовать два механизма аутентификации для собственного и стороннего использования может быть так же сложно, как реализовать только OAuth2 для собственного и стороннего использования.

Сложные и изначально небезопасные системы

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

При взаимодействии с популярными провайдерами OAuth2 и OpenID Connect (Facebook, Google, Amazon, ...) вы заметите, что все решают проблемы немного по-разному.

GitHub не предлагает возможности OpenID Connect, у Facebook есть свой вариант OpenID Connect, Apple пришлось получить открытое письмо от OpenID Foundation о совместимости, и у Auth0 есть свои особенности OAuth2... список можно продолжать и продолжать!

OAuth2 и OpenID Connect породили огромное количество захватывающих инноваций.

Тем не менее, если у вас небольшая команда или у вас есть очень четкий вариант использования (например, приложение), объем чтения, необходимый для правильного интерфейса и использования правильных методологий OAuth2, огромен, даже если вы взаимодействуете только с серверами OAuth2. и с использованием библиотек OAuth2!

Давайте рассмотрим самые популярные расширения OAuth2. Список длинный не только для того, чтобы подчеркнуть суть, но и потому, что есть так много вариантов и возможностей:

* Проверочный ключ для обмена кодом публичными клиентами OAuth * Модель угроз OAuth 2.0 и вопросы безопасности * Рекомендации по обеспечению безопасности OAuth 2.0 * Профиль JSON Web Token (JWT) для токенов доступа OAuth 2.0 * OAuth 2.0 для нативных приложений * OAuth 2.0 для браузерных приложений * Предоставление авторизации устройства OAuth 2.0 * Метаданные сервера авторизации OAuth 2.0 * Протокол динамической регистрации клиентов OAuth 2.0 * Протокол управления динамической регистрацией клиентов OAuth 2.0 * Отправленные запросы авторизации OAuth 2.0 * OAuth 2.0 Mutual-TLS Client Authentication и маркеры доступа с привязкой к сертификату * Структура авторизации OAuth 2.0: JAR-защищенный запрос авторизации * Структура утверждений для аутентификации и авторизации клиентов OAuth 2.0 * Профиль JSON Web Token (JWT) для аутентификации и авторизации клиента OAuth 2.0 * Профиль языка разметки подтверждения безопасности (SAML) 2.0 для аутентификации и авторизации клиента OAuth 2.0 * Структура авторизации OAuth 2.0: использование токена носителя * Проверочный ключ для обмена кодом публичными клиентами OAuth * Отзыв токена OAuth 2.0 * Интроспекция токена OAuth 2.0 * Управление сеансом OpenID Connect * Выход из переднего канала OpenID Connect * Выход из обратного канала OpenID Connect * Федерация OpenID Connect * OpenID Connect SSE * CAEP OpenID Connect

Этот список длинный, но есть еще более длинный список RFC и спецификаций, находящихся в стадии разработки и разработки. Наряду с этими более общими спецификациями существуют также спецификации для финансовых учреждений (FAPI), правительств (iGov), EAP, MODRNA и многих других.

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

В некоторых случаях использование OAuth2 затруднено

Если мы еще не убедили вас, давайте рассмотрим еще несколько аргументов в пользу отказа от OAuth2 и OpenID Connect. Как указывалось ранее, это рекомендация, которая не применяется к допустимым вариантам использования. Но прежде чем спуститься в кроличью нору OAuth2, вы должны точно знать, как далеко она зайдет.

Собственные нативные приложения

Обратный к пользователю поток OAuth2 и OpenID Connect требует, чтобы пользователь взаимодействовал с веб-сайтом в браузере. Если вы создаете нативные приложения, вы не можете обойти это, и вам нужно будет открыть браузер iOS или Android.

Единственный способ обойти это — использовать опальный грант учетных данных владельца ресурса OAuth2. Но этот грант доступен не на всех платформах, вызовет тревогу у аудиторов безопасности и планируется удалить из спецификации с OAuth 2.1.

Для многих сторонних приложений это абсолютный запрет, потому что ваши пользователи покинут приложение, чтобы открыть браузер и войти в систему, нарушая работу пользователя. Однако некоторые платформы, такие как iOS, пытаются улучшить это с помощью лучшего пользовательского интерфейса. Тем не менее, многие владельцы продуктов избегают этой практики.

Если вы хотите использовать OAuth2 для нативных приложений, ознакомьтесь с нашим руководством по OAuth2 для нативных приложений. .

Управление сеансом I: слои

Ни OAuth2, ни OpenID Connect не предназначены для управления сеансами. Несколько лет назад, когда я две недели занимался реализацией Auth0, я понял, что Auth0 имеет три разных сеансовых уровня у всех есть свои механизмы выхода из системы!

Это не потому, что Auth0 плохой. Это потому, что они используют сторонний протокол для решения собственной проблемы! Цитата из их документации по сеансовому уровню:

1. Сеансовый уровень приложения. Этот уровень представляет собой сеанс внутри вашего приложения. Хотя ваше приложение использует Auth0 для аутентификации пользователей, ваше приложение также отслеживает, что пользователь вошел в ваше приложение; например, в обычном веб-приложении это достигается путем сохранения этой информации в файле cookie.

2. Уровень сеанса Auth0: Auth0 также поддерживает сеанс на сервере авторизации для пользователя и сохраняет информацию о пользователе в файле cookie. Этот слой используется для того, чтобы в следующий раз, когда пользователь будет перенаправлен на Auth0 для входа в систему, информация о пользователе была запомнена. Этот сеансовый уровень делает возможным использование единого входа для входящих реализаций единого входа.

3. Сеансовый уровень поставщика удостоверений. Когда пользователи пытаются войти в систему с помощью поставщика удостоверений, такого как Facebook или Google, и у них уже есть действительный вход (с помощью любого провайдера, который они выберут), им не будет предложено снова войти в систему, хотя они может быть запрошено разрешение на обмен их информацией с Auth0 и, в свою очередь, с вашим приложением.

Вставьте псевдокод, и вы получите что-то вроде этого:

```js app.get("/oauth2/callback", (req, res) => { const { access_token, id_token } = oauth2.exchange(req.query.code) постоянный сеанс = { user_id: id_token.sub, доступ_токен,

// Мы по-прежнему используем файл cookie для создания сеанса writeSessionCookie(сессия) })

app.get("/protected/api", (req, res) => { // Обратите внимание: здесь нам не нужен токен! константный сеанс = readSessionCookie (требуется) постоянный пользователь = getUser (session.user_id) если (!пользователь) { res.redirect("/логин") возвращаться } })

app.get("/logout", (req, res) => { константный сеанс = readSessionCookie (требуется) постоянный пользователь = getUser (session.user_id) если (!пользователь) { res.redirect("/логин") возвращаться

// Это сеансовый уровень OAuth2. oauth2.logout(пользователь)

// Это уровень сеанса приложения. удалитьSessionCookie(req)

res.redirect("/логин") }) ```

Управление сеансом II: выход

Возможно, вы знаете CircleCI — платформу непрерывной интеграции, которая выполняет тесты вашего кода. Естественно, CircleCI требуется доступ к вашим репозиториям GitHub или GitLab, что означает, что он использует возможности GitHub/GitLab OAuth2.

Суть в том, что если вы вошли в CircleCI через GitHub и вышли из GitHub, вы все равно останетесь в CircleCI! То же самое относится, если вы используете приложение, использующее «Войти с помощью {что угодно}». С OAuth2 третьей стороне неважно, какой у вас статус сеанса у первой стороны!

Мы в Ory регулярно получаем (и отвечаем) на этот вопрос: "Я реализовал OAuth2, но как мне глобально выйти из аккаунта моих пользователей?". Там является спецификацией для этого! Но все могло бы быть намного проще.

Цитируя документацию по выходу из системы Auth0, можно отметить три отдельных механизма выхода при использовании протоколов делегирования (OAuth2 / OpenID Connect):

• Выход на уровне сеанса приложения. Выход пользователей из ваших приложений обычно приводит к очистке их сеанса приложения, и это должно обрабатываться вашим приложением: для уровня сеанса приложения в вашем клиенте Auth0 нет ничего, что вам нужно было бы использовать. для облегчения завершения сеанса. Это потребует, чтобы вы использовали любой стек сеанса приложения, который вы используете, чтобы очистить любую информацию, связанную с сеансом. Обратите внимание, что некоторые SDK Auth0 обеспечивают некоторую поддержку сеансов приложений; пожалуйста, проверьте документацию, чтобы узнать, есть ли какие-либо локальные сеансы SDK, которые необходимо выполнить.

* Выход из уровня сеанса Auth0: вы можете вывести пользователей из уровня сеанса Auth0, перенаправив их на конечную точку выхода Auth0, чтобы Auth0 мог очистить файл cookie SSO.

* Выход из системы на уровне сеанса поставщика удостоверений. Нет необходимости выводить пользователей из этого уровня сеанса, но при необходимости можно использовать Auth0 для принудительного выхода из системы.

Управление сеансом III: хранилище

У браузеров есть три основных способа сохранения данных на клиенте:

1. Файлы cookie, которые могут быть установлены только сервером (httpOnly).

2. Файлы cookie, которые могут быть установлены клиентом (document.cookie JavaScript — уязвим для XSS).

3. LocalStorage, который может быть установлен клиентом (localStorage JavaScript — уязвим для XSS).

При получении токена доступа, обновления или идентификатора возникает вопрос, где вы их храните? Естественным местом будет файл cookie httpOnly браузера! Но сегодня многие приложения являются клиентскими и не имеют прямого доступа к веб-серверу.

Таким образом, сохранение его в файле cookie httpOnly может быть наиболее безопасным вариантом, но также и самым неудобным!

Есть несколько мнений и соображений. Мы собрали несколько наиболее интересных дискуссий для дальнейшего чтения:

1. Как хранить токен доступа? (Oauth 2, поток кода аутентификации)
2. Должны ли мы хранить токен доступа в нашей базе данных для oauth2?
3. LocalStorage и файлы cookie: все, что вам нужно знать о безопасном хранении токенов JWT во внешнем интерфейсе

Синхронизация и условия гонки

OAuth2 использует строгие меры безопасности для предотвращения векторов атак. Наиболее распространенными являются меры по смягчению последствий «Token Replay», в частности для токенов обновления OAuth2 и кодов авторизации OAuth2.

Смягчение повторного использования токена означает, что если вы дважды используете один и тот же токен обновления или код авторизации, запрос завершится ошибкой и все связанные коды доступа, обновления и авторизации будут аннулированы. Это означает, что ваш пользователь должен повторить весь поток OAuth2 с самого начала!

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

Предотвратить эти типы условий состязания сложно во внешних приложениях — вам понадобится хорошее решение для побочных эффектов, такое как Redux Saga, чтобы обеспечить что только один вызов API обновляет токен за раз.

В распределенных системах это становится еще сложнее!

Конечно, есть решения и для этой проблемы, например, льготный период (например, несколько секунд), когда токен обновления можно использовать повторно. Тем не менее, это добавляет еще один уровень сложности и потенциальной нестабильности вашей системе.

Что произойдет, если ваша система находится под большой нагрузкой? Будут ли быстрые запросы на обновление достаточно быстрыми? Что произойдет, если время истекло? Или если вам нужно повторить попытку? Следует ли полностью отключить обнаружение повторного использования токенов? Но тогда вы можете не пройти аудит безопасности!

На это нет четких ответов. Чтобы принять правильное решение, требуется время, исследования, тестирование и повторение.

Человеческий аспект: масштабирование команд

При разработке мы всегда думаем о создании масштабируемых систем. Тем не менее, одним из самых сложных аспектов масштабирования программной системы является человеческий фактор.

Google изобрел Golang, новый язык программирования для решения проблем масштабирования людей, которые пишут программное обеспечение, потому что масштабировать от 10 до 20 000 разработчиков так же сложно, как создать поисковую систему, которая отвечает на любой запрос менее чем за 50 мс. где бы вы ни находились на планете.

Я начал Ory несколько лет назад и с тех пор расширил его от шоу одного человека до компании почти из 30 человек (сравнительно небольшое количество). На протяжении всего этого я был свидетелем того, как сообщество росло и боролось с терминологией OAuth2 и OpenID Connect, сложностью и инструментами.

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

В чем разница между сервером ресурсов, владельцем ресурса, сторонним клиентом, проверяющей стороной, токеном идентификатора, токеном обновления и верификатором PKCE?

Всему этому должен научиться и понять любой новый член команды, касающийся этих систем. Конечно, там масса ресурсов. Но какой из них относится к вашей системе?

Согласие первой стороны

При принятии решения о том, нужен ли вам OAuth2/OpenID Connect Connect, стоит задать себе хороший вопрос: хотите ли вы, чтобы пользователи видели экран, подобный следующему:

Если ответ нет, вам не нужен OAuth2/OpenID Connect для аутентификации пользователя.

Области не являются разрешениями

Токены OAuth2 имеют область действия. Область видимости обычно что-то вроде read:user или profile:write. Область OAuth2 не говорит, что пользователь может и что не может делать.

OAuth не подходит для авторизации пользователей. Тот факт, что у вас есть токен доступа, который позволяет вам действовать от имени пользователя, не означает, что пользователь может выполнить действие. Источник

Маркер доступа означает, что клиентское приложение было авторизовано пользователем. В нем указано, что пользователь сказал (согласие!), что стороннее приложение может делать от его имени. Давайте кратко рассмотрим поток OAuth2:

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

2. Пользователь идентифицирует себя на сервере авторизации (но помните, что OAuth не является аутентификацией; вам понадобится OpenID Connect, чтобы помочь вам в этом).

3. Пользователь разрешает клиентскому приложению доступ к защищенному ресурсу от своего имени (используя процесс согласия OAuth).

4. Клиентскому приложению выдается токен доступа.

Например:

1. Алиса разрешает myphotoapp доступ к своим фотографиям на Facebook.

2. Боб разрешает mytodolist доступ к своему Календарю Google.

Приведем контрпример:

Если Алиса разрешит myphotoapp выступать в качестве администратора системы и удалить производственную базу данных, это не будет иметь значения, если Алиса на самом деле не является системным администратором. Точно так же Алиса не может разрешить myphotoapp доступ к фотографиям Боба, потому что она не Боб.

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

Спецификации и RFC устаревают, как и все остальное в технологии

Технические характеристики могут быть изменены и прекращены, как и в любой другой системе. RFC и спецификации не вечны и не защищают от критических изменений, обновления систем, изменения конфигураций или устаревания определенных потоков.

Вот несколько примеров устаревших спецификаций:

* Неявный грант OAuth2

* Использование OAuth2 без PKCE больше не будет доступно в OAuth 2.1+.

* Предоставление учетных данных владельца ресурса будет устарело в OAuth 2.1 и обычно считается плохой практикой".

* Управление сеансом OpenID Connect использует скрытые iframe (с файлами cookie HTTP) для синхронизации состояний сеанса, что становится все труднее в сегодняшнем закрытом мире файлов cookie.

Конечно, есть и более заброшенные и устаревшие спецификации. Однако они так и не прошли статус черновика, и поэтому я их не включил. По этой причине мы принимаем только окончательные RFC и спецификации для Ory Fosite и Ори Гидра!

Убедите своих сверстников

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

Нашему API нужны токены, поэтому нам нужен OAuth2!

Токены доступа OAuth2 — это подкатегория токенов. Токен авторизации — это просто строка, которая используется для авторизации запроса. Это может быть что угодно, от веб-токена JSON (так называемые токены передачи по значению) до случайного идентификатора (так называемые токены передачи по ссылке).

Вам не нужен OAuth2 для выпуска такого токена!

В частности, вы найдете такие термины, как «токены личного доступа» или «ключи API». Эти типы токенов не являются результатом потоков OAuth2! Они используют такие системы, как Kong's Key Authentication Plugin, или простой сервис.

Вам действительно нужны OAuth2 и OpenID Connect только в том случае, если вы хотите, чтобы ваши пользователи давали согласие («т. Е. Я хочу разрешить этому приложению доступ к моим личным данным»). Вам не нужен OAuth2 для создания веб-токена JSON, токена личного доступа или собственного токена сеанса мобильного приложения.

В Ory вы можете использовать токены сеанса Ory, если хотите связать свой API с собственными приложениями и клиентами. которые не имеют браузера.

Мы также планируем опубликовать новую службу токенов, которая стандартизирует ключи API и токены личного доступа, чтобы ваши пользователи могли легко создавать эти типы токенов масштабируемым и безопасным способом!

В заключение: OAuth2 выпускает токены. Но не каждый токен должен быть выпущен OAuth2 для обеспечения безопасности.

Мы хотим использовать веб-токены JSON, поэтому нам нужен OAuth2.

Вы можете использовать веб-токены JSON без OAuth2. Это два разных стандарта, которые можно использовать независимо! См. раздел выше.

Мы можем использовать OAuth2 для разрешений!

Области не являются разрешениями.

Я планирую будущее, поэтому мне нужен OAuth2 сейчас!

В некоторых случаях это допустимо. Если вы сталкиваетесь со сложной средой с сотнями различных сервисов и интеграций, возможно, имеет смысл стандартизировать все с помощью OAuth2 и OpenID Connect.

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

Другой допустимый случай — если вы создаете платформу, на которой третьим лицам нужен доступ к вашей системе. Здесь также может иметь смысл немедленно начать использовать OAuth2 и OpenID Connect, чтобы поддерживать один стандартный метод аутентификации.

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

OAuth2 и OpenID Connect — лучшее, что у нас есть

Это то, что мы часто слышим от консультантов! Как минимум OAuth2 и OpenID Connect стандартизированы и интегрированы с большинством языков программирования.

Но было бы лучше, если бы у нас действительно было что-то, что:

1. Удовлетворяет потребность в решении для входа, регистрации, восстановления учетной записи…

2. Надежно и не очень сложно

3. Решает разрешения (не области действия OAuth2) масштабируемым и надежным способом

4. Стандартизирован

5. Может быть расширен для поддержки OAuth2 и OpenID Connect, когда вам это действительно нужно?

Что еще, если не OAuth2?

Именно поэтому мы создаем Ory. Мы хотим создать следующее поколение сервисов аутентификации и авторизации. Хотя до того, как Ory действительно станет новым стандартом, еще далеко, у нас уже есть прочная основа!

Пока вы здесь, возможно, вас заинтересует один из наших проектов:

* Ory Network – это управляемая служба, предлагающая общепланетарные API с малой задержкой для входа, регистрации, разрешений, делегирования (OAuth2/OpenID Connect ), и многие другие функции в будущем. Он сочетает в себе наши проекты с открытым исходным кодом с простой и масштабируемой инфраструктурой!

* Ори Кратос — это наша попытка решить проблему аутентификации без использования OAuth2 или OpenID Connect простым, надежным и безопасным способом!

* Ory Keto — это реализация технического документа Google Zanzibar, в котором объясняется, как Google решает проблемы с разрешениями и контролем доступа в своих продуктах (Youtube , Документы Google, Google Workspace, Поиск Google,...).

* Ory Hydra – это современный, простой в использовании сервер OAuth2 и OpenID Connect с открытым исходным кодом, который может подключаться к с любой пользовательской системой (например, Ory Kratos).

Все ли плохо с OAuth2/OpenID Connect?

Конечно, нет! OAuth2 и OpenID Connect — чрезвычайно мощные и хорошо продуманные протоколы, которые при правильном использовании могут значительно улучшить совместимость систем и, таким образом, снизить сложность (что повышает безопасность).

Есть много примеров безопасного и успешного использования этих двух протоколов. От FireTV до интеграции различных сервисов (Hubspot, Google, Discourse, ...) и предложения мощных инструментов для предоставления третьим лицам доступа к конфиденциальной частной информации.

Но важно иметь в виду, что вы хотите построить и в какой последовательности. Для многих вариантов использования, которые заканчиваются в сообществе Ори, что-то вроде Ори Кратос и Ory Network гораздо лучше подходят, чем пытаться внедрить OAuth2 и OpenID Connect как на стороне сервера, так и на стороне клиента!

И хорошая новость заключается в том, что если возникнет необходимость в OAuth2 и OpenID Connect, вы можете снова использовать Ory, чтобы добавить их сверху!

Заключение

Спасибо, что нашли время прочитать эту статью. Это много, я знаю!

Я надеюсь, что вы кое-чему научились и, самое главное, что теперь у вас есть знания, чтобы приступить к созданию своей системы, не тратя беспокойные ночи на то, что вам пока не нужно, разбираясь во всех запутанных деталях OAuth2 и OpenID Connect!

У вас другое мнение на эту тему или вы просто получили удовольствие от прочтения? Пишите мне в Twitter или следите за мной на GitHub .

Спасибо за чтение и увидимся в следующий раз! Может быть, в сообществе Ory? :)

Также опубликовано здесь