Немного понимания IdentityServer3

Некоторая информация по IdentityServer3, позволяющая приблизится к пониманию того, как это все работает…

Токены

Access-токен

Используется для выполнения запросов к API. Токен выдается при входе пользователя и используется многократно. Время жизни токена, как правило не велико.

Refresh-токен

Используется для обновления Access-токена по требованию клиента. Это может происходить, если клиент сам проверяет время жизни Access-токена или после получения от сервера ответа о том, что время жизни Access-токена истекло.

Токен одноразовый, но время его жизни значительное. После использования Refresh-токена обновляется и Access-токена и Refresh-токен.

Зачем это все нужно, хорошо описано тут. Если коротко, то при получении злоумышленником Access-токена, он сможет пользоваться им только до момента истечения срока его жизни; при получении обоих токенов, попытка воспользоваться Refresh-токеном для получения новой пары токенов приведет к ошибке доступа у настоящего клиента, что заставит его заново произвести вход, тем самым сбросив старые токены и получив новые. Таким образом, использование пары токенов приводит к тому, что злоумышленник может перехватить доступ только на время жизни Access-токена.

Flow

ClientCredentials

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

Запрос

POST /connect/token HTTP/1.1
Content-Type: application/x-www-form-urlencoded
Authorization: Basic c2lsaWNvbjpGNjIxRjQ3MC05NzMxLTRBMjUtODBFRi02N0E2RjdDNUY0Qjg=

grant_type=client_credentials&scope=api1

Ответ

HTTP/1.1 200 OK
Content-Type: application/json; charset=utf-8

{
    "access_token": "e97ec9230abec30ea6e1f98b8f0e29a9",
    "expires_in": 3600,
    "token_type": "Bearer"
}

ResourceOwner

Данный тип доступа позволяет запрашивать токены от имени пользователя, используя имя пользователя и пароль. Это так называемая «неинтерактивная» аутентификация, которая, как правило, не рекомендуется для использования. Данный тип доступа может использоваться в устаревших или внутренних сценариях интеграции и рекомендуется вместо него использовать «интерактивные» типы вроде «Implicit» или «Hybrid».

Запрос

POST /connect/token HTTP/1.1
Content-Type: application/x-www-form-urlencoded
Authorization: Basic c2lsaWNvbjpGNjIxRjQ3MC05NzMxLTRBMjUtODBFRi02N0E2RjdDNUY0Qjg=

grant_type=password&username=bob&password=secret&scope=api1

Ответ

HTTP/1.1 200 OK
Content-Type: application/json; charset=utf-8

{
    "access_token": "e97ec9230abec30ea6e1f98b8f0e29a9",
    "expires_in": 3600,
    "token_type": "Bearer"
}

Implicit

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

AuthorizationCode

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

Hybrid

Гибридный тип доступа совмещает в себе неявный (Implicit) тип доступа и авторизацию по коду (AuthorizationCode).

About the author

Добавить комментарий

Сказать спасибо

Способ платежа:

Подписаться на обновления

Укажите свой e-mail чтобы получать уведомления о новых статьях.

Присоединиться к еще 1 подписчику