В современном цифровом мире, где взаимодействие с онлайн-ресурсами и web приложениями стало неотъемлемой частью нашей повседневной жизни, безопасность и управление личной идентификацией стали ключевыми аспектами. Именно в этом контексте становится крайне важным понятие “Identity Provider” или, сокращённо, IdP.

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

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

В этой статье мы рассмотрим более подробно, как происходит взаимодействие с Identity Provider, его преимущества и роль в обеспечении безопасности данных и доступа в цифровой эпохе.

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

Говоря об Identity Provider, нельзя не упомянуть ключевые понятия, ради чего IdP и нужен. Авторизация и аутентификация - процессы которые позволяют обеспечить безопасность и защиту цифровых данных. Начнем по порядку.

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

1. Пароли: Это самый распространенный метод аутентификации. Пользователь вводит уникальный пароль, чтобы получить доступ к своему аккаунту, например, при входе в почту или социальные сети.

2. Биометрия: Включает в себя использование физических характеристик пользователя, таких как отпечаток пальца, сканирование лица или сетчатки глаза для подтверждения личности. Примерами служат Touch ID или Face ID в устройствах Apple.

3. Двухфакторная аутентификация (2FA): Этот метод требует двух различных способов аутентификации, обычно пароля и одноразового кода, который отправляется на мобильное устройство пользователя. Примеры включают в себя вход в аккаунт Google с использованием SMS-кода.

4. Сертификаты: Электронные сертификаты используются для проверки аутентичности, часто в корпоративных сетях. Например, сертификаты используются в корпоративных VPN для обеспечения безопасного удаленного доступа.

5. Пин-коды: Как правило, используются вместе с банковскими картами или смарт-картами для доступа к финансовым ресурсам или защищенным зданиям.

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

Авторизация - это процесс предоставления прав доступа пользователю к определенным ресурсам, функциям или данным после успешной аутентификации. Важно отличать авторизацию от аутентификации: аутентификация проверяет, кто пользователь, а авторизация определяет, что этот пользователь может делать. Вот некоторые примеры авторизации:

1. Уровни доступа в операционных системах: В операционных системах, таких как Windows или Linux, существуют разные уровни доступа, такие как администратор и обычный пользователь. После входа в систему, пользователь авторизуется для выполнения различных действий в зависимости от его уровня доступа.

2. Доступ к файлам и папкам: В системах управления файлами, таких как Dropbox или Google Drive, авторизация определяет, к каким файлам и папкам пользователь имеет доступ. Например, один пользователь может иметь доступ только к своим собственным файлам, в то время как другой может иметь доступ к общим документам.

3. Права доступа к базам данных: В веб-приложениях и системах управления базами данных, авторизация определяет, какие операции и данные пользователь может просматривать, изменять или удалять. Например, администратор базы данных имеет больше прав доступа, чем обычный пользователь.

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

5. Управление правами в социальных сетях: В социальных сетях, пользовательские профили могут быть настроены с разными правами доступа для разных категорий пользователей. Например, пользователь может определить, кто может видеть его посты или отправлять запросы на добавление в друзья.

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

Протоколы аутентификации и авторизации

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

HTTP Basic Authentication

HTTP Basic Authentication - это один из наиболее простых методов аутентификации в протоколе HTTP. Этот метод используется для проверки подлинности пользователя, когда клиент (обычно веб-браузер) отправляет запрос на сервер, включая заголовок "Authorization". Он передает имя пользователя и пароль в закодированном формате на сервер для проверки подлинности.

Вот как работает HTTP Basic Authentication:

1. Клиент отправляет HTTP-запрос на сервер, и в заголовке "Authorization" включает строку, которая выглядит следующим образом:

   Authorization: Basic base64(username:password)

Где base64(username:password) - это закодированная строка, состоящая из имени пользователя и пароля, разделенных двоеточием и закодированных в формате Base64.

2. Сервер получает эту строку и декодирует её, извлекая имя пользователя и пароль.

3. Сервер затем сравнивает полученные учетные данные с хранимыми данными, чтобы проверить, есть ли совпадение. Если совпадение найдено, сервер разрешает доступ к запрошенным ресурсам; в противном случае сервер отправляет ответ с кодом состояния HTTP 401 (Unauthorized), и клиенту требуется вновь отправить правильные учетные данные.

HTTP Basic Authentication имеет несколько ограничений и недостатков:

1. Отправка пароля в открытом виде: Учетные данные (имя пользователя и пароль) передаются в открытом виде, хотя они могут быть закодированы в формате Base64. Это делает их уязвимыми для перехвата злоумышленниками.

2. Базовая безопасность: Этот метод обеспечивает только базовый уровень безопасности, и его не рекомендуется использовать для передачи чувствительных данных или важных ресурсов.

3. Отсутствие возможности смены пароля: HTTP Basic Authentication не предоставляет механизма для изменения пароля, если пользователь хочет его изменить. Это требует дополнительной логики на стороне клиента и сервера.

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

Протоколы основанные на токенах

Работа аутентификации на основе токенов веб-приложений и API основывается на использовании специальных токенов для проверки подлинности пользователей. Эти токены выдаются после успешной аутентификации и могут быть использованы для доступа к защищенным ресурсам. Преимуществами данного подхода является то, что время действия токена ограничено по времени. Также, токены не требуют постоянной передачи пароля по сети, что снижает риск перехвата пароля злоумышленниками. Дополнительным бонусом к этому является возможность использования технологии Single sign-on (SSO).  Общепринятыми протоколами для работы с токенами являются OAuth и OpenID Connect. OAuth используется для авторизации и предоставления доступа к ресурсам, в то время как OpenID Connect используется для аутентификации и авторизации одновременно. Но кто выдаёт эти токены и проверяет их подлинность? Тут мы и подходим к предназначению Identity Provider’a.

Современные приложения, или как их ещё называют в контексте security service providers, делегируют функцию аутентификации пользователей другому приложению, а именно IdP. Это может быть собственный сервис на базе открытых реализации(к примеру KeyCloak) или взаимодействие с IdP сторонних компаний(к примеру Google ил Яндекс). Вы безусловно видели сайты, где вам предлагается использовать учётную запись Google вместо регистрации. Теперь, service provider снимает с себя нагрузку и ответственность за проверку логинов и паролей, эту работу выполняет IdP. Основные функции IdP:

1. Проверка подлинности пользователей

2. Управление клиентами, их аутентификация и хранение их данных.

3. Предоставление управления сеансами и возможность внедрения единой аутентификации (Single Sign-On).

4. Выдача клиентам access токенов.

5. Проверка ранее выданных токенов.

Процесс аутентификации

Рассмотрим, как устроен authentication flow при использовании IdP. Flow может отличаться в зависимости от протокола, реализации и требований к безопасности, поэтому рассмотрим наиболее распространенный способ для web приложений. Это так называем Authorization code flow, который является стандартным для KeyCloak реализации IdP.  Сначала о терминологии. Протокол OAuth определяет четыре роли:

• Resource owner (Владелец ресурса) -  это сущность, способная предоставить доступ к защищенному ресурсу. Обычно это пользователь, который авторизуется  в своей учетной записи приложения для доступа к данным.

• Resource server (Сервер ресурсов) - сервер, на котором размещены защищенные ресурсы, способный принимать и отвечать на запросы защищенных ресурсов с использованием токенов доступа.

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

• Authorization server - Сервер IdP, выдающий токены доступа клиенту после успешной аутентификации владельца ресурса.

Перейдём к рассмотрению процесса аутентификации:

1. Пользователь, зайдя в клиент(в нашем примере сайт), жмет кнопку login.

2. Клиент формирует запрос на аутентификацию.

3. Пользователю прилетает ответ с HTTP кодом 302(Found), который пересылает его на authorization endpoint IdP и IdP отображает пользователю login page.

4. Пользователь вводит свои данные.  

5. IdP возвращает пользователя к клиенту authorization code.

6. Клиент вместе с authorization code, client ID и client credentials делает запрос в IdP.

7. IdP проверяет подлинность данных.

8. После успешной проверки, IdP возвращает клиенту ID token(или refresh token) и access token.

9. Теперь пользователь может выполнять запросы на закрытые ресурсы.

Authorization code

Рассмотрим этап 2-3 подробней. На этом этапе пользователь получает authorization code. Client формирует запрос следующего вида:

GET /authorize?
response_type=code&
client_id=lsBgP1e8&
state=xyz&
redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb

• response_type=code сообщает что используется Authorization Code flow.

• client_id - IdP выдает приложению client_id - уникальную строку, представляющую регистрационную информацию, предоставленную клиентом. Идентификатор клиента не является секретным, он доступен владельцу ресурса. Идентификатор клиента уникален для Idp. Клиенту следует избегать предположений о размере идентификатора. IdP должен документировать размер любого идентификатора, который он выдает.

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

• redirect_uri - то, куда перенаправить пользователя с authorization code

Как раз таки этот запрос и формирует клиент на этапе 2. На этапе 3 пользователю возвращается эта ссылка, перейдя по которой (это делается автоматические при использовании стандартного поведения браузеров при HTTP коде 302) на этапе 4 пользователь вводи свои данные.

После удачной аутентификации IdP перенаправит пользователя на redirect_uri с authorization code в параметре URI

HTTP/1.1 302
FoundLocation: https://client.example.com/cb?
code=SplxlOBeZQQYbYS6WxSbIA&
state=xyz

 Таким образом, authorization code получается с использованием IdP в качестве посредника между клиентом и владельцем ресурса. Вместо запроса авторизации напрямую у владельца ресурса, клиент направляет пользователя к identity provider, который после ввода логина и пароля направляет владельца ресурса обратно к клиенту с авторизационным кодом.

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

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

Access и Refresh token’ы

Access token - это секретная строка, которая используется для аутентификации пользователя и предоставления доступа к защищенным ресурсам или данным через API или другие системы. Access token позволяет определенным пользователям  выполнять определенные операции или получать доступ к определенным данным.

На этапе 6 происходит обмен code на token. Запрос на обмен очень похож на запрос authorization code.

POST /token HTTP/1.1

     Host: server.example.com

grant_type=authorization_code&
code=adSyuiaYbYS6WxSbIA&
redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb&
client_id=lsBgP1e8

Ответ:

HTTP/1.1 200 OK

{
"access_token":"2dUidaAZda87",
"token_type":"example",
"expires_in":3600,
"refresh_token":"tDa789DDzzdpdm",
"…":"…"
}

Access token обычно имеет ограниченное время жизни, что уменьшает риск злоупотребления им в случае утечки или компрометации. Когда срок действия истекает, необходимо запросить новый access token или повторить authentication flow. Для обеспечения безопасности, access token должен передаваться с использованием защищенных протоколов, таких как HTTPS, и храниться в безопасном месте. Также он должен быть зашифрован и защищен от несанкционированного доступа. Поэтому, в 99 процентах случаев access token возвращается браузеру в cookie с флагом “HttpOnly”.

Даже сам обмен, обычно выполняется не самим клиентом(фронтенд веб приложения), а делегируется на серверную часть клиента (бэкенд веб приложения). Клиент сообщает backend’у authorization code, и всю операцию обмена выполняет backend. Это позволяет достичь лучше безопасности и скрыть от пользователя все промежуточные манипуляции. Также, стандарт не определяет использование дополнительных кодов и паролей при обмене authorization code на токен, однако, к примеру, реализация IdP KeyCloak имеет возможность при запросе токена спрашивать также client_secret - секретный пароль для взаимодействия сервера и IdP. Делегирование обмена токена бэкэнду делает authentification flow более безопасным и позволяет использовать флаг HttpOnly.

Флаг HttpOnly - это атрибут, который можно установить в HTTP-куки, возвращаемые клиенту (веб-браузеру), чтобы ограничить доступ к этим кукам из JavaScript кода на клиентской стороне. Когда флаг HttpOnly установлен, куки могут быть доступны только для сервера через HTTP-заголовки, и они не могут быть прочитаны или изменены из JavaScript в браузере. Когда access token хранится в куках с флагом HttpOnly, это снижает риск злоупотребления или утечки токена. Злоумышленники не могут получить доступ к access token через JavaScript-инъекции или кросс-сайт-скриптинг (XSS) атаки, что делает систему более надежной. Кроме того, использование флага HttpOnly помогает в защите от атаки межсайтовой подделки запроса (CSRF). Злоумышленники не могут получить доступ к кукам с токенами и использовать их для выполнения нежелательных операций от имени пользователя.

Refresh token выдаётся клиенту от IdP и используется для получения нового токена доступа, когда текущий токен доступа становится недействителен или истекает. Выдача токена обновления является необязательной и остается на усмотрение IdP. Однако использование refresh token’а улучшает user experience, так как все операции по замене токена берет на себя клиент. В случае протечки access token’a пользователю не придётся заново вводить свои учётные данные, так как клиент, используя refresh token, сделает запрос в IdP, и обновит access token заранее. Refresh token имеет больший срок жизни, чем access token.

В реализации OAuth используется токен формата jwt.

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

Single sign-on

Single Sign-On (SSO) - это метод аутентификации и авторизации в web приложениях, который позволяет пользователю войти в несколько различных приложений или сервисов, используя одни и те же учетные данные, такие как имя пользователя и пароль, только один раз. Когда SSO внедрен, пользователь может авторизоваться один раз, и затем, без необходимости повторного ввода учетных данных, получать доступ к другим приложениям или сервисам, связанным с этой системой SSO. Вы безусловно с этим сталкивались, к примеру, при работе с google сервисами. Введя учетные данные для входа в почту gmail, ваш аккаунт применится также и для Youtube или Google Drive.

SSO основан на настройке доверительных отношений между приложениями (service provider) и системой управления доступами(IdP), например, KeyCloak, Google или Яндекс. Эти доверительные отношения часто устанавливаются через обмен сертификатами между системой управления доступом и поставщиком услуг. Этот сертификат используется для указания идентификационной информации, которая передается от системы управления доступом к поставщику услуг. Таким образом, поставщик услуг может быть уверен, что информация поступает из надежного источника. В контексте SSO идентификационные данные представляются в виде токенов, которые содержат идентификационные значения информации о пользователе, такие как адрес электронной почты или имя пользователя.

Заключение

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

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

Во-вторых, использование Identity Provider упрощает управление учетными записями пользователей и повышает удобство использования приложений. Пользователи могут использовать свои существующие учетные записи социальных сетей или других сервисов для авторизации в различных веб-приложениях, избегая необходимости создавать новые учетные записи.

Наконец, реализация Identity Provider позволяет управлять разграничением доступа и правами пользователей в приложении. Администраторы могут легко устанавливать и отзывать разрешения, а также контролировать доступ к конфиденциальным данным.

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

Источники

1. https://auth0.com/docs

2. https://www.keycloak.org/documentation

3. RFC 6749