Аутентификация по Cookies

Схема действия:

В идеальном RESTful сервисе контроль за состояниями полностью производится на стороне клиента.

Для клиентов, помимо браузеров, COOKIES сложны в обработке.

Если говорить только о браузерах, то возможный сценарий использования такой:

• — api смотрит на заголовок «Authorization», в случае не-браузерных клиентов именно туда будет помещена информация для авторизации
• — если такой заголовок отсутсвует, то проверяется сессионная cookie для осуществления авторизации на стороне сервера.

Недостатки:

не отвечает требованиям RESTful сервиса в вопросе независимости от состояния, уязвима к атакам man-in-the middle, воспроизведение, на стороне сервера каким-то образом нужно хранить сессионную id, что противоречит REST-идеологии.

Таблица 1.6 — Запрос клиента (RFC 6749) для получения токена.

Аутентификация по токенам и SSO

Такой способ аутентификации чаще всего применяется при построении распределенных систем, использующих единый сервис для входа (SSO), где одно приложение, выступающее в качестве Cервиса-поставщика (англ. «service provider», «relying party», «SP»), — в данной работе это один из описанных во введении Сервисов, — делегирует функцию аутентификации пользователей другому приложению (identity provider или authentication service). Такое приложение представляет собой сервис-поставщик идентификационных услуг. Сервис-поставщик идентификационных услуг (англ. «identity provider», ««identity assertion provider», «IdP») — решает следующие основные задачи:

предоставляет идентификаторы пользователей, взаимодействующих с системой;

предоставляет подтверждение того факта, что такой идентификатор известен сервису-поставщику;

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

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

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

На общем уровне, весь процесс выглядит следующим образом:

клиент аутентифицируется в identity provider одним из способов, специфичным для него (пароль, ключ доступа, сертификат, Kerberos, итд.);

клиент просит identity provider предоставить ему токен для конкретного SP-приложения. Identity provider генерирует токен и отправляет его клиенту;

клиент аутентифицируется в SP-приложении при помощи этого токена.

Рисунок 1.5 — Пример аутентификации «активного» клиента при помощи токена, переданного посредством Bearer-схемы.

Процесс, описанный выше, отражает механизм аутентификации активного клиента, т. е. такого, который может выполнять запрограммированную последовательность действий (например, iOS/Android приложения). Браузер же — пассивный клиент в том смысле, что он только может отображать страницы, запрошенные пользователем. В этом случае аутентификация достигается посредством автоматического перенаправления браузера между веб-приложениями IdP и SP.

Рисунок 1.6 — Пример аутентификации «пассивного» клиента посредством перенаправления запросов Существует несколько стандартов, в точности определяющих протокол взаимодействия между клиентами (активными и пассивными) и IP/SP-приложениями и формат поддерживаемых токенов. Среди наиболее популярных стандартов — OAuth, OpenID Connect, SAML, и WS-Federation.

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

При аутентификации с помощью токена SP-приложение должно выполнить следующие проверки:

токен был выдан доверенным identity provider приложением (проверка поля issuer);

токен предназначается текущему SP-приложению (проверка поля audience);

срок действия токена еще не истек (проверка поля expiration date);

токен подлинный и не был изменен (проверка подписи).

В случае успешной проверки SP-приложение выполняет авторизацию запроса на основании данных о пользователе, содержащихся в токене[16].

Выбор способов аутентификации Выбор способ аутентификации находится в зависимости от назначения API, а также основных типов клиентов, для которых предназначено данное API.

Назначением API может быть следующее:

основное назначение. Взаимодействие с front-end частью системы для выполнения основной бизнес-логики системы вторичное. Использование методов, предоставляемых API, сторонними приложениями;

точка доступа для осуществления однократного входа пользователя в рамках использования нескольких систем ООО НЦР «РУКОНТ».

Основные типы клиентов можно подразделить на браузерные;

не браузерные.

Отсюда можно сделать вывод о необходимости внедрения двух способов аутентификации.

аутентификация по cookie, являющаяся классическим решением, применяющимся для браузеров;

аутентификация по токену, являющаяся широко распространенным решением для RESTful сервисов.

О технологии.

Web API применяет спецификацию Oath2, которая описывает механизм аутентификации на основе токенов. Конкретную реализацию этой спецификации представляют компоненты OWIN, благодаря которым и производит генерация токенов, их выдача клиенту и их дальнейшая валидация. Поэтому при создании приложения Web API нам не надо самим реализовывать сервер авторизации, все эти детали, а досточно взять готовый механизм, который предоставляет ASP.NET [17].