Аутентификация и авторизация

OAuth 2.0

OAuth 2.0, что означает «Открытая авторизация», представляет собой фреймворк, предназначенный для предоставления согласованного доступа к ресурсам от имени пользователя без передачи учетных данных пользователя. OAuth 2.0 — это протокол авторизации, а не протокол аутентификации, он разработан в первую очередь как средство предоставления доступа к набору ресурсов, например, к удаленным API или данным пользователя.

OAuth 2.0 заменяет и упраздняет протокол OAuth 1.0, описанный в RFC-5849.

Концепции

Протокол OAuth 2.0 определяет следующие объекты:

  • Владелец ресурса: пользователь или система, которая владеет защищенными ресурсами и может предоставлять к ним доступ.
  • Клиент: Клиент — это система, выполняющая запросы защищенных ресурсов от имени Владельца ресурса и с его разрешения.
  • Сервер авторизации: этот сервер получает запросы от Клиента на токены доступа и выдает их после успешной аутентификации с согласия Владельца ресурса.
  • Сервер ресурсов: сервер, который защищает ресурсы пользователя и получает запросы на доступ от Клиента. Он принимает и проверяет токен доступа от клиента и возвращает соответствующие ресурсы.
  • Токен доступа: часть данных, представляющая авторизацию на доступ к ресурсам от имени конечного пользователя.

Как работает OAuth 2.0?

  1. Запрос авторизации. Клиент запрашивает авторизацию у владельца ресурса. Запрос на авторизацию можно сделать непосредственно владельцу ресурса (как показано), или желательно косвенно через сервер авторизации в качестве посредника.
  2. Разрешение на авторизацию Клиент получает разрешение на авторизацию (еще его называют грантом), которым являются учетные данные, представляющие полномочия владельца ресурса.
  3. Клиент запрашивает токен доступа, аутентифицируясь с помощью сервера авторизации, предоставляя ему разрешение (грант) на авторизацию.
  4. Сервер авторизации аутентифицирует клиента и валидирует разрешение на авторизацию (грант). Если оно валидно, то выдает токен доступа (access token).
  5. Клиент запрашивает защищенный ресурс у сервера ресурсов и аутентифицируется, предоставляя токен доступа.
  6. Сервер ресурсов проверяет токен доступа, и, если он действителен, обслуживает запрос. Предпочтительный метод получения клиентом разрешения на авторизацию от владельца ресурса (описанного на шагах (1) и (2)) — использовать сервер авторизации в качестве посредника.

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

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

Недостатки

Вот наиболее распространенные недостатки OAuth 2.0:

  • Отсутствуют встроенные функции безопасности.
  • Нет стандартной реализации.
  • Нет общего набора прицелов.

Дополнительные источники

OpenID

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

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

Концепции

Протокол OpenID Connect (OIDC) определяет следующие сущности:

  • Надежная сторона: текущее приложение.
  • Поставщик OpenID: по сути, это промежуточная служба, предоставляющая одноразовый код доверяющей стороне.
  • Конечная точка токена: веб-сервер, который принимает одноразовый код (OTC) и предоставляет код доступа, действительный в течение часа. Основное различие между OIDC и OAuth 2.0 заключается в том, что токен предоставляется с использованием JSON Web Token (JWT).
  • Конечная точка UserInfo: Проверяющая сторона связывается с этой конечной точкой, предоставляя безопасный токен и получая информацию о конечном пользователе.

И OAuth 2.0, и OIDC просты в реализации и основаны на JSON, который поддерживается большинством веб-приложений и мобильных приложений. Однако спецификация OpenID Connect (OIDC) более строгая, чем спецификация базового OAuth.

Единый вход (SSO)

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

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

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

Компоненты

Давайте обсудим некоторые ключевые компоненты единого входа (SSO).

Поставщик удостоверений (IdP)

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

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

Поставщик услуг

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

Брокер идентификации

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

SAML

Язык разметки утверждений безопасности — это открытый стандарт, который позволяет клиентам обмениваться информацией о безопасности, касающейся удостоверений, аутентификации и разрешений, в разных системах. SAML реализован со стандартом Extensible Markup Language (XML) для обмена данными.

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

Как работает система единого входа?

Теперь давайте обсудим, как работает единый вход:

  1. Пользователь запрашивает ресурс из желаемого приложения.
  2. Приложение перенаправляет пользователя к поставщику удостоверений (IdP) для аутентификации.
  3. Пользователь входит в систему со своими учетными данными (обычно это имя пользователя и пароль).
  4. Поставщик удостоверений (IdP) отправляет ответ единого входа обратно в клиентское приложение.
  5. Приложение предоставляет доступ пользователю.

SAML против OAuth 2.0 и OpenID Connect (OIDC)

Существует много различий между SAML, OAuth и OIDC. SAML использует XML для передачи сообщений, а OAuth и OIDC используют JSON. OAuth упрощает работу, а SAML ориентирован на корпоративную безопасность.

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

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

OpenID Connect — это, по сути, слой поверх инфраструктуры OAuth. Следовательно, он может предложить встроенный уровень разрешений, который просит пользователя согласиться с тем, к чему может получить доступ поставщик услуг. Хотя SAML также может разрешать поток согласия, он достигает этого за счет жесткого кодирования, выполняемого разработчиком, а не как часть его протокола.

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

Преимущества

Ниже приведены преимущества использования единого входа:

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

Недостатки

Вот некоторые недостатки единого входа:

  • Уязвимость с одним паролем: если основной пароль системы единого входа будет скомпрометирован, все поддерживаемые приложения будут скомпрометированы.
  • Процесс аутентификации с использованием единого входа медленнее, чем традиционная аутентификация, поскольку каждое приложение должно запрашивать поставщика SSO для проверки.

Примеры

Вот некоторые часто используемые поставщики удостоверений (IdP):

SSL, TLS, mTLS

Давайте кратко обсудим некоторые важные протоколы безопасности связи, такие как SSL, TLS и mTLS. Я бы сказал, что с точки зрения проектирования системы в целом эта тема не очень важна, но о ней все равно полезно знать.

SSL

SSL расшифровывается как Secure Sockets Layer и относится к протоколу для шифрования и защиты коммуникаций, которые происходят в Интернете. Впервые он был разработан в 1995 году, но с тех пор устарел в пользу TLS (Transport Layer Security).

Почему он называется сертификатом SSL, если он устарел?

Большинство основных поставщиков сертификатов по-прежнему называют сертификаты SSL-сертификатами, поэтому соглашение об именах сохраняется.

Почему SSL был так важен?

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

TLS

Безопасность транспортного уровня, или TLS, — это широко распространенный протокол безопасности, предназначенный для обеспечения конфиденциальности и защиты данных при обмене данными через Интернет. TLS произошел от предыдущего протокола шифрования под названием Secure Sockets Layer (SSL). Основной вариант использования TLS — шифрование связи между веб-приложениями и серверами.

Протокол TLS состоит из трех основных компонентов:

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

mTLS

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

Зачем использовать mTLS?

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

В настоящее время mTLS обычно используется микросервисами или распределенными системами в модели безопасности с нулевым доверием для проверки друг друга.