Идентификация, аутентификация и авторизация

Что такое ОAuth2.0?

черновикаRFC 6749

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

Роли

• Resource owner — сущность, которая имеет права доступа на защищённый ресурс. Сущность может быть конечным пользователем или какой-либо системой. Защищённый ресурс — это HTTP endpoint, которым может быть что угодно: API endpoint, файл на CDN, web-сервис.
• Resource server — сервер, на котором хранится защищённый ресурс, к которому имеет доступ resource owner.
• Client. Это приложение, которое запрашивает доступ к защищённому ресурсу от имени resource owner и с его разрешения — с авторизацией. 
• Authorization server — сервер, который выдаёт клиенту токен для доступа к защищённому ресурсу, после успешной авторизации resource owner.

Регистрация клиента

фантазииRedirection URIClient type

• Confidential — клиент, который может безопасно хранить свои учётные данные. Например, к такому типу клиентов относят web-приложения, имеющие backend.
• Public — не может безопасно хранить свои учётные данные. Этот клиент работает на устройстве владельца ресурса, например, это браузерные или мобильные приложения.

Абстрактный OAuth 2.0. Flow c применением Access token

• Client отправляет запрос на доступ к требуемому ресурсу resource owner.
• Resource owner передаёт обратно клиенту authorization grant, который подтверждает личность resource owner и его права на ресурс, доступ к которому запрашивает client. В зависимости от flow это может быть токен или учётные данные.
• Client отправляет authorization grant, полученный в предыдущем шаге authorization server, ожидая от него Access token для доступа к защищённому ресурсу. 
• authorization server убеждается в валидности authorization grant, после чего отсылает access token клиенту в ответ.
• Получив access token, клиент запрашивает защищённый ресурс у resource server. 
• Resource server убеждается в корректности access token, после чего предоставляет доступ к защищённому ресурсу.

Абстрактный OAuth 2.0. Flow c применением Refresh token

• Client приходит c authorization grant к authorization server и просит предоставить ему access token и refresh token.
• Authorization server убеждается, что с authorization grant всё нормально и возвращает клиенту запрошенные access token и refresh token.
• Client с access token запрашивает защищённый ресурс, пока не получит первую ошибку доступа к ресурсу — invalid token error.
• После получения ошибки доступа, клиент идет к authorization server с refresh token и просит заменить просроченный access token на новый. 
• В ответ клиент получает новый access token, а также новый refresh token, либо продлевается время жизни старого refresh token. 

OAuth 2.0

• Resource Owner — пользователь, который заходит на MySite и дает ему разрешение использовать свои закрытые данные из Соцсети.
• Client (он же MySite) — приложение или интернет сайт, которым пользуется пользователь и которое взаимодействует с Authorization Server и Resource Server для получения закрытых данных пользователя.
• Authorization Server — сервер который проверяет логин/пароль пользователя, он же Соцсеть.
• Resource Server — хранит закрытую пользовательскую информацию, которую можно получить с помощью API. Authorization Server и Resource Server могут быть совмещены в одну систему.

Authorization flow

• Перед началом авторизации необходимо зарегистрировать MySite в Соцсети:
• Разработчик MySite задает Name (имя приложения), Homepage (адрес домашней страницы MySite) и Callback (адрес, на который Соцсеть перенаправит пользователя после успешной авторизации)
• Соцсеть выдает Client ID (иногда его называют AppID) и Client Secret.
• Client ID и Client Secret разработчик должен прописать в своем Client.

1. Resource Owner заходит на Client (MySite), выбирает опцию “войти с помощью Соцсети”, сайт перенаправляет пользователя в Cоцсеть на Authorization Server.
2. Authorization Server проверяет есть ли у пользователя активная сессия и, если нет, то показывает форму для логина.
3. Resource Owner вводит свои логин/пароль и подтверждает, что определенные закрытые данные могут быть использованы MySite, например имя пользователя или e-mail адрес.
4. Authorization Server проверяет пользователя и перенаправляет на адрес Callback с результатом аутентификации и “Authorization Code”
5. В ответ Client посылает “Authorization Code”, Client ID и Client Secret.
6. Authorization Server проверяет присланные данные и формирует “access token” в формате JWT (JSON Web Token), подписанный своим приватным ключом. В этом же JWT может содержаться и “refresh token”, c помощью которого возможно восстановление сессии после ее окончания.
7. После этого Client может запросить закрытую информацию пользователя с помощью вызова API, в который передается “access token”.
8. Resource Server проверяет “access token” (например, используя открытый ключ Authorization Server) и предоставляет доступ к данным пользователя.

OAuth 2.0 Лабораторная работа (GitHub)

• Client ID: ab8ec08a620c2
• Client Secret: e6fdd52b0a99e8fbe76b05c1b7bb93c1e

• адрес — это точка логина на GitHub
• client_id — это Client ID, выданный при регистрации

• адрес — это точка получения access token на GitHub
• client_id — это Client ID, выданный при регистрации
• client_secret это Client Secret, выданный при регистрации
• code — это только что присланный code

Что такое идентификация

Определение идентификации – это глубинная потребность личности устанавливать совпадения и похожести с объектом почитания. Человек, воспринимающий мир, как систему таинственных явлений и вещей, становится не в состоянии самостоятельно осознавать смысл бытия и назначение окружающего мира. Такой человек нуждается в стойкой системе ориентации, что дала бы возможность ему сопоставить себя с конкретным образцом. Механизм такого рода впервые был разработан в психоаналитической теории Зигмунда Фрейда. Он выделил его на основании личного наблюдения за патологическими случаями, и позже распространил это на «здоровую» духовную жизнь.

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

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

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

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

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

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

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

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

Еще одним динамическим методом есть распознание по динамике набора по клавиатурным клавишам («клавиатурный почерк»). Процесс аналогичен методу распознавания по почерку. Однако здесь используется вместо бумаги клавиатура, а вместо подписи определенное кодовое слово. Главной характеристикой есть динамика компьютерного набора этого кодового слова.

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

Как работает двухфакторная аутентификация

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

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

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

Теоретически, в качестве второго фактора могут выступать:

• пароль, секретный вопрос, PIN-код, графический ключ, код доступа – что-то, известное только владельцу аккаунта;
• токен или магнитная карта (по этому принципу работают ключи безопасности);
• уникальное свойство пользователя, то есть биометрические данные: отпечаток пальца, лицо, радужная оболочка глаза.

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

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

Такая схема используется некоторыми ресурсами (Microsoft или Google) по умолчанию, но ее также можно и нужно настроить и применять везде – от электронной почты до TikTok. Конечно, такие меры не спасут от опытного хакера, которому зачем-то понадобился именно ваш аккаунт. Но для обычного взломщика двухфакторная идентификация будет почти непреодолимым препятствием.

Авторизация

ABACофициальной документацииRBACRole-based access controlKubernetes 1.8Чтобы включить RBACстатью

• и — роли, которые служат для описания прав доступа:
• позволяет описать права в рамках пространства имён;
• — в рамках кластера, в том числе к кластер-специфичным объектам типа узлов, non-resources urls (т.е. не связанных с ресурсами Kubernetes — например, , , );
• и — служит для привязки и к пользователю, группе пользователей или ServiceAccount.

• группы API — см. по apiGroups и вывод ;
• ресурсы (resources: , , и т.п.);
• глаголы (verbs: , и т.п.).
• имена ресурсов () — для случая, когда нужно предоставить доступ к какому-то определённому ресурсу, а не ко всем ресурсам этого типа.

официальной документации

Объясняем идентификацию, аутентификацию и авторизацию на енотах

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

• Для начала система запрашивает логин, пользователь его указывает, система распознает его как существующий — это идентификация.
• После этого Google просит ввести пароль, пользователь его вводит, и система соглашается, что пользователь, похоже, действительно настоящий, раз пароль совпал, — это аутентификация.
• Скорее всего, Google дополнительно спросит еще и одноразовый код из SMS или приложения. Если пользователь и его правильно введет, то система окончательно согласится с тем, что он настоящий владелец аккаунта, — это двухфакторная аутентификация.
• После этого система предоставит пользователю право читать письма в его почтовом ящике и все в таком духе — это авторизация.

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

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

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

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

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

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

Что еще важно понимать: аутентификация — пожалуй, самый важный из этих процессов с точки зрения безопасности вашего аккаунта. Если вы ленитесь и используете для аутентификации только слабенький пароль, то какой-нибудь енот может ваш аккаунт угнать

Поэтому:

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

TACACS+

Данный протокол разработан компанией Cisco и является развитием прошлых версий TACACS и XTACACS. Несмотря на схожесть названий, TACACS+ был сильно видоизменен и не имеет обратной совместимости с TACACS, который сейчас практически нигде не применяется. Основная сфера использования TACACS+ – это администрирование сетевых устройств, однако он может применяться для некоторых типов AAA при доступе в сеть. TACACS + использует Transmission Control Protocol (TCP) порт 49, а не UDP, так как он обладает большей надежностью и позволяет заранее получать информацию о потенциальных ошибках благодаря пакету TCP-RST. ТСP более медленный протокол, но обладает дополнительными преимуществами: возможность разделения аутентификации, авторизации и учета в качестве отдельных и независимых функций, множественная авторизация после одной аутентификации, шифрование всего содержимого пакета.

Для наглядности объединим основные характеристики в таблицу:

Почему стоит использовать токены авторизации?

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

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

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

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

Начало

Вся эта функциональность уже реализована для ASP.NET Core — проект с открытым исходным кодом под названием Identity 3.0. Для настройки окружения вам понадобится установить:

• Visual Studio 2015;
• Update 3 для VS 2015;
• .NET Core tools for Visual Studio.

Инструкцию по установке и ссылки можно найти .

Для включения функционала Identity создадим проект ASP.NET Core Web Application по шаблону Web Application и в качестве типа аутентификации выберем Individual User Accounts.

В проект будет добавлен пакет Microsoft.AspNetCore.Identity.EntityFrameworkCore, который будет сохранять данные и схемы в SQL Server для Entity Framework Core.

Также этот пакет можно добавить через NuGet Package Manager.

Или же дописав соответствующие зависимости в файле project.json в узлах dependencies и tools.

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

Как это работает

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

В ASP.NET Core за настройку обработки запросов отвечает метод Configure класса Startup. При создании проекта с использованием шаблона по умолчанию в этот метод добавится строка отвечающая за аутентификацию для потока запросов, основанную на куки.

Также в метод ConfigureServices этого же класса Startup будут добавлены Identity сервисы.

Это позволит использовать их в приложении с помощью встроенной системы внедрения зависимостей.

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

ASP.NET Core был сильно изменен по сравнению с прошлыми версиями, не остался в стороне и Identity 3.0. Структура БД для Identity 3.0 имеет следующий вид:

Появились две новые таблицы: AspNetRoleClaims и AspNetUserTokens. Пользователи и роли, как и ранее, представлены классами IdentityUser и IdentityRole соответственно. Но теперь они не наследуются от интерфейсов для пользователей и ролей, что очень удобно. Также появились новые инструменты авторизации — политики.

Политика — это одно или несколько требований, необходимых пройти пользователю для авторизации.

Пример

Пусть для доступа к некоторому ресурсу в приложении пользователь должен иметь российское гражданство. Для начала зарегистрируем политику RussianСitizenship в ConfigureService файла startup.cs:

Для регистрации политики мы использовали RussianСitizenshipRequirement в качестве авторизационного требования — параметры данных, которые использует политика для оценки текущего пользователя. В нашем случае есть лишь один параметр — гражданство. Для создания требования нужно реализовать интерфейс IAuthorizationRequirement:

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

Добавим в HomeController метод RussianPage () c атрибутом Authorize:

Готово, доступ к этому методу получат лишь пользователи, удовлетворяющие требованиям данной политики.

Взаимосвязь идентификации, аутентификации и авторизации

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

1. Сначала определяют имя (логин или номер) – идентификация
2. Затем проверяют пароль (ключ или отпечаток пальца) – аутентификация
3. И в конце предоставляют доступ – авторизация

Инфографика: 1 — Идентификация; 2 — Аутентификация; 3 — Авторизация

Проблемы безопасности при авторизации

Помните, как в сказке «Красная Шапочка» бабушка разрешает внучке войти в дом? Сначала бабушка спрашивает, кто за дверью, затем говорит Красной Шапочке, как открыть дверь. Волку же оказалось достаточным узнать имя внучки и расположение дома, чтобы пробраться в дом.

Какой вывод можно сделать из этой истории?

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

Заключение

• OAuth 2.0 — используется для регистрации и входа пользователей на сайты с помощью соцсетей. А также для получения данных пользователей из соцсетей.
• OpenID Connect — используется для аутентификации пользователей и позволят предоставить им доступ к своим закрытым данным на сайтах. Также OpenID Connect служит для реализации сложных сценариев взаимодействия в корпоративных SSO системах.
• WebAuthn — используется для добавления на сайт возможности аутентификации с помощью внешнего физического ключа или отпечатка пальца.

Выводы

• Очевидно, что современный сайт должен реализовать все возможные способы регистрации и авторизации, чтобы у пользователя был осознанный выбор.
• Появилась возможность никогда не хранить пароль пользователя, чтобы не компрометировать свою репутацию, а хранить только логины и зашифрованные личные данные.
• Имеет смысл отдать аутентификацию пользователей облачным платформам, таким как Facebook или Google, т.к. в них работают лучшие специалисты по безопасности, которые могут предусмотреть все нюансы безопасности.
• Предлагаю с оптимизмом смотреть в будущее, т.к. протокол WebAuthn — реальный шанс избавится от парольного ада нашего времени!

It’s only the beginning!