Аутентификация против авторизации: различия и как они работают

Введение

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

Однако ни то, ни другое не было правдой. Ранее я работал в компании Auth0,, которая управляет цифровой идентификацией. (Сейчас я являюсь участником программы Auth0 Ambassadors и являюсь экспертом Google Developer по SPPI: Security, Privacy, Payments, and Identity — безопасность, конфиденциальность, платежи и идентификация.)

Цифровая идентификация

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

Что это значит?

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

Это приводит нас к …

Аутентификация

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

Как только система сможет установить это, мы приходим к …

Стандарты

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

Есть много разных стандартов и организаций, которые управляют работой Интернета. Два органа, которые представляют для нас особый интерес в контексте аутентификации и авторизации, — это Инженерная рабочая группа по Интернету (Internet Engineering Task Force — IETF) и Фонд OpenID (OpenID Foundation — OIDF).

IETF (Internet Engineering Task Force)

IETF — это большое открытое международное сообщество сетевых инженеров, операторов, поставщиков и исследователей, которые занимаются развитием интернет-архитектуры и бесперебойной работой интернета.

OIDF (OpenID Foundation)

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

Теперь, когда нам известны спецификации и кто их пишет, давайте вернемся к авторизации и поговорим о:

OAuth 2.0

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

OAuth не является спецификацией аутентификации. OAuth имеет дело с делегированной авторизацией. Помните, что аутентификация — это проверка личности пользователя. Авторизация касается предоставления или отказа в доступе к ресурсам. OAuth 2.0 предоставляет доступ к приложениям от имени пользователей.

Как было до OAuth

Чтобы понять цель OAuth, нам нужно вернуться назад во времени. OAuth 1.0 был создан в декабре 2007 года. До этого, если нам требовался доступ к сторонним ресурсам, это выглядело так:

Допустим, вы использовали приложение под названием HireMe123. HireMe123 хочет настроить событие календаря (например, встречу на собеседование) от вашего имени (пользователя). HireMe123 не имеет собственного календаря; поэтому нужно использовать другой сервис под названием MyCalApp для добавления событий.

После того, как вы вошли в HireMe123, HireMe123 запросит у вас ваши учетные данные для входа в MyCalApp. Вы должны ввести свое имя пользователя и пароль на сайте HireMe123.

Затем HireMe123 используя ваш логин получить доступ к API MyCalApp, и затем сможет создавать события календаря с использованием ваших учетных данных.

Совместное использование учетных данных — это плохо!

Этот подход основывался на совместном использовании личных учетных данных пользователя из одного приложения с совершенно другим приложением, и это не очень хорошо.

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

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

Двухфакторная аутентификация (2FA)

Двухфакторная аутентификация (2FA) улучшает безопасность доступа за счёт использования двух методов (также называемых факторами) проверки личности пользователя. Это разновидность многофакторной аутентификации. Наверное, вам не приходило в голову, но в банкоматах вы проходите двухфакторную аутентификацию: на вашей банковской карте должна быть записана правильная информация, и в дополнение к этому вы вводите PIN. Если кто-то украдёт вашу карту, то без кода он не сможет ею воспользоваться. (Не факт! — Примеч. пер.) То есть в системе двухфакторной аутентификации пользователь получает доступ только после того, как предоставит несколько отдельных частей информации.

Другой знакомый пример — двухфакторная аутентификация Mail.Ru, Google, Facebook и т. д. Если включён этот метод входа, то сначала вам нужно ввести логин и пароль, а затем одноразовый пароль (код проверки), отправляемый по SMS. Если ваш обычный пароль был скомпрометирован, аккаунт останется защищённым, потому что на втором шаге входа злоумышленник не сможет ввести нужный код проверки.

Вместо одноразового пароля в качестве второго фактора могут использоваться отпечатки пальцев или снимок сетчатки.

При двухфакторной аутентификации пользователь должен предоставить два из трёх:

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

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

То есть это универсальное решение? Возможно, нет.

И всё же двухфакторка поможет усилить безопасность аутентификации в вашем приложении. Как реализовать? Возможно, стоит не велосипедить, а воспользоваться существующими решениями вроде Auth0 или Duo.

Примеры

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

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

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

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

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

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

Если же речь идет о содержимом вашего почтового ящика, то Google никогда и ни за что не авторизует неопознанного субъекта на чтение вашей переписки.

Разница между авторизацией, аутентификацией и идентификацией

Авторизацию не следует путать с идентификацией и аутентификацией пользователя. Она происходит по завершении этих процессов.

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

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

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

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

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

Что еще важно знать

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

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

По материалам сайтов kaspersky.ru, support.google.com

Что такое Авторизация

И последнее, что необходимо знать о входе на сайт – это авторизация.

Данная процедура подразумевает попадание на страницу в случае успешного прохождения аутентификации и идентификации.

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

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

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

OpenID Connect

• C помощью OAuth 2.0 мы только авторизовали пользователя т.е. о пользователе мы знаем только access token, с помощью которого можем получать определенные данные из Соцсети. Но access token ничего не говорит о личности пользователя и с помощью него мы не можем предоставить доступ к закрытым данным пользователя на нашем сайте MySite. OpenID Connect — добавляет сведения о логине и профиле пользователя (identity). Это как раз и позволяет реализовать его аутентификацию.
• OpenID Connect также добавляет возможность динамической регистрации и обнаружения сервисов “service discovery”. Это дает возможность строить системы SSO (Single Sign-On), в которых используется один логин для многих не связанных между собой сервисов.

• Authorization Server, помимо access token и refresh token, возвращает “identity token” (ID Token). Он содержится в том же JWT. Из ID Token можно извлечь следующую информацию: имя пользователя, время входа в учетную запись, срок окончания действия ID Token. ID Token можно передавать между участниками.
• OIDC предоставляет дополнительное API, которые позволяет запрашивать информацию о пользователе и его текущих сессиях.

• В первичном запросе на получение code добавляется дополнительный атрибут scope=openid.
• В результате работы алгоритма Client, помимо access и refresh token, получает ID Token.

OpenID Connect: Лабораторная работа (Google)

• адрес — это точка логина на Google
• response_type=code — ожидаем получить в ответ code
• client_id — Client ID, выданный при регистрации
• scope=openid email — к каким данным мы хотим получить доступ
• redirect_uri — redirect_uri заданный при регистрации приложения
• state — сгенерированное Client-ом число, которое передается между Client и AS для защиты от вмешательства злоумышленника.

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

Последствия нехватки безопасности API

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

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

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

В целом, аутентификация и авторизация с помощью API служат следующим целям:

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

Что такое JSON веб-токены?

JSON Web Token (JWT) — это открытый стандарт (RFC 7519), который определяет компактный и автономный способ безопасной передачи информации между сторонами в виде объекта JSON. Эта информация может быть подтверждена благодаря цифровой подписи. JWT может быть подписан с помощью секрета (с помощью алгоритма HMAC) или иным образом, например, по схемам RSA или ECDSA.

В своей компактной форме веб-токены JSON состоят из трех частей, разделенных точками: заголовок, полезная нагрузка, подпись. Поэтому JWT выглядит обычно выглядит следующим образом: «xxxx.yyyy.zzzz».

Заголовок состоит из двух частей: типа токена, которым является JWT, и используемого алгоритма подписи, такого как HMAC SHA256 или RSA.

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

Зарегистрированная — это набор ключей, который не является обязательными, но рекомендуются для обеспечения улучшения безопасности. Например, iss — уникальный идентификатор стороны, генерирующей токен, exp — время в формате Unix Time, определяющее момент, когда токен станет не валидным, и другие.

Публичная информация может быть определена по желанию теми, кто использует JWT. Но они должны быть определены в реестре веб-токенов IANA JSON или определены как URI, который содержит устойчивое к коллизиям пространство имен. Частная — это пользовательская информация, созданная для обмена данными между сторонами, которые согласны их использовать. Получим вторую часть с помощью кодирования Base64Url.

Тоже не понял, что за прикол там происходит.

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

Выходные данные представляют собой три строки Base64-URL, разделенные точками, которые могут быть легко переданы в средах HTML и HTTP, будучи при этом более компактными по сравнению со стандартами на основе XML, такими как SAML.

Пример:

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

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

Примеры второго фактора

СМС-код с подтверждением. Предполагается, что человек не передаёт свой телефон другим людям, поэтому если отправить ему СМС, то прочитает его именно он. Так работают почти все интернет-банки. 

Также код могут отправить на почту или в приложение. Смысл тот же. 

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

Подтверждение в приложении. Если у сервиса есть приложение и вы его установили, сервис может связаться с приложением на вашем телефоне и задать вам там вопрос: «Это вы входите?». Вход в аккаунт Гугла, например, работает именно так.

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

Таким методом пользуются для входа в некоторые почтовые сервисы или в защищённые контуры корпоративных сетей. Например, если у вас почта Яндекса, можно настроить вход через «Яндекс-ключ».

Аутентификация по QR-коду. В приложении может быть функция «Считать QR-код»: подносите камеру к компьютеру, и система убеждается, что перед экраном сидите именно вы. 

Так работает аутентификация в веб-версию WhatsApp или в почту Яндекса через приложение «Ключ».

Устройство-аутентификатор. Обычно их делают в виде флешки с кнопкой и экранчиком. Нажимаете на кнопку — высвечивается код. Потеряется флешка — нужно будет идти к тому, кто её выдавал, без этого система никуда просто по логину и паролю не пустит.

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

Пример токена, который продаётся на сайте secure-market.ru. Сам по себе он бесполезен — его нужно привязывать к системе аутентификации вашего софта, чтобы они знали друг о друге. Если просто купить этот токен, его коды ничего вам не откроют

NFC-карта или карта с магнитной лентой. Иногда у сотрудников банков к компьютеру подключён специальный ридер для карт. Чтобы совершить важную операцию, сотрудник должен подтвердить её своей картой: мол, это точно я.

Биометрия. Биометрия — это всё, что касается вашего тела: распознавание отпечатков, лица, голоса, биоритмов, ауры и что там ещё придумают. Как правило, применяется на крупных и важных объектах с повышенными требованиями к безопасности. 

Аутентификация и авторизация: прояснение понятий

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

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

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

Так из чего состоит авторизация?

Авторизация это что определяет, к каким системным ресурсам авторизованный пользователь сможет получить доступ , Тот факт, что вы успешно прошли проверку подлинности, не означает, что вы сможете использовать систему полностью как администратор. В соответствии с рядом правил, правил и положений, специфичных для каждой внутренней сети, определяется, что пользователь A будет иметь доступ к ресурсам X и Y. Однако пользователь B сможет получить доступ только к ресурсу Z.

Если бы вы были администратором, у вас был бы доступ к ресурсам X, Y и Z, а также к ресурсам 1, 2 и 3, которые являются уникальными для тех, у кого есть права администратора.

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

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

Описание решения

Задача

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

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

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

На “бумаге” (во внутренних организационно-распорядительных документах ) указано, что сотрудник самостоятельно обеспечивает требования к безопасному хранению и использованию собственных паролей и устройств — носителей ключевой информации.

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

• Игнорирование требований безопасности к составу паролей в системах и сервисах, где не настроены соответствующие политики
• Преднамеренное или непреднамеренное игнорирование необходимости менять пароли с заданной периодичностью там, где это не настроено автоматически
• Выполнение всех требований безопасности к ведению паролей, но и одновременная их фиксация на материальном носителе или в текстовом файле
• Забывание паролей и просьба к специалистам ИТ/ИБ сбросить их (после чего не все их меняют, если нет принудительной смены после первого входа)
• В случае наличия нескольких устройств — путаница с их использованием или хранение их в небезопасных местах

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

Сложности с использованием и администрированием паролей, с управлением цифровыми сертификатами и их носителями ведут к снижению управляемости ИТ-инфраструктурой и снижению уровня ИБ. Оптимальным решением будет использование связки специализированных программных комплексов классов Public Key Infrastructure Management (PKI-Management), Authentication Management (или Access Management) и Two-Factor Authentication (2FA)

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