Для чего применяется аутентификация и идентификация
Идентификация, аутентификация и авторизация – в чем разница?
Мы постоянно идентифицируемся, аутентифицируемся и авторизуемся в разнообразных системах. И все же многие путают значение этих слов и часто употребляют термин «идентификация» или «авторизация», хотя на самом деле речь идет об аутентификации. Ничего страшного в этом нет, часто обе стороны диалога понимают, что в действительности имеется в виду. Но всегда лучше знать и понимать слова, которые употребляем.
Определения
Что же значат все эти термины, и чем соответствующие процессы отличаются друг от друга?
Примеры
Пользователь хочет войти в свой аккаунт Google (Google подходит лучше всего, потому что там процедура входа явным образом разбита на несколько простейших этапов). Вот что при этом происходит:
Аутентификация без предварительной идентификации лишена смысла – пока система не поймет, подлинность чего же надо проверять, совершенно бессмысленно начинать проверку. Для начала надо представиться.
Идентификация без аутентификации не работает. Потому что мало ли кто ввел существующий в системе логин! Системе обязательно надо удостовериться, что этот кто-то знает еще и пароль. Но пароль могли подсмотреть или подобрать, поэтому лучше подстраховаться и спросить что-то дополнительное, известное только данному пользователю: например, одноразовый код для подтверждения входа.
А вот авторизация без идентификации и аутентификации очень даже возможна. Например, в Google Документах можно публиковать документы так, чтобы они были доступны всем. В этом случае вы как владелец файла увидите сверху надпись, гласящую, что его читает неопознанный субъект. Несмотря на это, система его все же авторизовала – то есть выдала право прочитать этот документ.
Но если вы открыли этот документ для чтения только определенным пользователям, то им в таком случае сперва пришлось бы идентифицироваться (ввести свой логин), потом аутентифицироваться (ввести пароль и одноразовый код) и только потом получить право на чтение документа – авторизоваться.
Если же речь идет о содержимом вашего почтового ящика, то Google никогда и ни за что не авторизует неопознанного субъекта на чтение вашей переписки.
Что еще важно знать
Аутентификация – пожалуй, самый важный из этих процессов с точки зрения безопасности вашего аккаунта. Если вы ленитесь и используете для аутентификации только простенький пароль, то какой-нибудь злоумышленник может ваш аккаунт угнать. Поэтому:
Идентификация, аутентификация, авторизация — в чем разница?
Перед серией уроков по информационной безопасности нам нужно разобраться с базовыми определениями.
Сегодня мы узнаем, что такое идентификация, аутентификация, авторизация и в чем разница между этими понятиями
Что такое идентификация?
Сначала давайте прочитаем определение:
Идентификация — это процедура распознавания субъекта по его идентификатору (проще говоря, это определение имени, логина или номера).
Идентификация выполняется при попытке войти в какую-либо систему (например, в операционную систему или в сервис электронной почты).
Сложно? Давайте перейдём к примерам, заодно разберемся, что такое идентификатор.
Пример идентификатора в социальной сети ВКонтакте
Когда нам звонят с неизвестного номера, что мы делаем? Правильно, спрашиваем “Кто это”, т.е. узнаём имя. Имя в данном случае и есть идентификатор, а ответ вашего собеседника — это будет идентификация.
Идентификатором может быть:
Подробнее об идентификаторах и ID рекомендую прочитать здесь.
Что такое аутентификация?
После идентификации производится аутентификация:
Аутентификация – это процедура проверки подлинности (пользователя проверяют с помощью пароля, письмо проверяют по электронной подписи и т.д.)
Чтобы определить чью-то подлинность, можно воспользоваться тремя факторами:
Отпечаток пальца может быть использован в качестве пароля при аутентификации
Получается, что каждый раз, когда вы вставляете ключ в замок, вводите пароль или прикладываете палец к сенсору отпечатков пальцев, вы проходите аутентификацию.
Ну как, понятно, что такое аутентификация? Если остались вопросы, можно задать их в комментариях, но перед этим разберемся еще с одним термином.
Что такое авторизация?
Когда определили ID, проверили подлинность, уже можно предоставить и доступ, то есть, выполнить авторизацию.
Авторизация – это предоставление доступа к какому-либо ресурсу (например, к электронной почте).
Разберемся на примерах, что же это за загадочная авторизация:
Дверь открылась? Вы авторизованы!
Взаимосвязь идентификации, аутентификации и авторизации
Наверное, вы уже догадались, что все три процедуры взаимосвязаны:
Инфографика: 1 — Идентификация; 2 — Аутентификация; 3 — Авторизация
Проблемы безопасности при авторизации
Помните, как в сказке «Красная Шапочка» бабушка разрешает внучке войти в дом? Сначала бабушка спрашивает, кто за дверью, затем говорит Красной Шапочке, как открыть дверь. Волку же оказалось достаточным узнать имя внучки и расположение дома, чтобы пробраться в дом.
Какой вывод можно сделать из этой истории?
Каждый этап авторизации должен быть тщательно продуман, а идентификатор, пароль и сам принцип авторизации нужно держать в секрете.
Заключение
Итак, сегодня вы узнали, что такое идентификация, аутентификация и авторизация.
Теперь мы можем двигаться дальше: учиться создавать сложные пароли, знакомиться с правилами безопасности в Интернете, настраивать свой компьютер с учетом требований безопасности.
А в заключение, занимательная задачка для проверки знаний: посчитайте, сколько раз проходят идентификацию, аутентификацию и авторизацию персонажи замечательного мультфильма «Петя и Красная Шапочка» (ответы в комментариях).
P.S. Самые внимательные могут посчитать, сколько раз нарушены рассмотренные в данном уроке процедуры.
Копирование запрещено, но можно делиться ссылками:
Идентификация, аутентификация и авторизация — в чем разница?
Объясняем на енотах, в чем разница между идентификацией и авторизацией, а также зачем нужна аутентификация, тем более двухфакторная.
Это происходит с каждым из нас, причем ежедневно: мы постоянно идентифицируемся, аутентифицируемся и авторизуемся в разнообразных системах. И все же многие путают значение этих слов и часто употребляют термин «идентификация» или «авторизация», когда на самом деле речь идет об аутентификации.
Ничего такого уж страшного в этом нет — пока идет бытовое общение и обе стороны диалога по контексту понимают, что в действительности имеется в виду. Но всегда лучше знать и понимать слова, которые употребляешь, а то рано или поздно нарвешься на зануду-специалиста, который вынет всю душу за «авторизацию» вместо «аутентификации», кофе среднего рода и такое душевное, но неуместное в серьезной беседе слово «ихний».
Идентификация, аутентификация и авторизация: серьезные определения
Итак, что же значат термины «идентификация», «аутентификация» и «авторизация» — и чем соответствующие процессы отличаются друг от друга? Для начала проконсультируемся с «Википедией»:
Объясняем идентификацию, аутентификацию и авторизацию на енотах
Выше было очень много умных слов, теперь давайте упростим до конкретных примеров. Скажем, пользователь хочет войти в свой аккаунт Google. Google подходит лучше всего, потому что там процедура входа явным образом разбита на несколько простейших этапов. Вот что при этом происходит:
Аутентификация без предварительной идентификации лишена смысла — пока система не поймет, подлинность чего же надо проверять, совершенно бессмысленно начинать проверку. Для начала надо представиться.
Идентификация без аутентификации — это просто глупо. Потому что мало ли кто ввел существующий в системе логин! Системе обязательно надо удостовериться, что этот кто-то знает еще и пароль. Но пароль могли подсмотреть или подобрать, поэтому лучше подстраховаться и спросить что-то дополнительное, что может быть известно только данному пользователю: например, одноразовый код для подтверждения входа.
А вот авторизация без идентификации и тем более аутентификации очень даже возможна. Например, в Google Документах можно публиковать документы так, чтобы они были доступны вообще кому угодно. В этом случае вы как владелец файла увидите сверху надпись, гласящую, что его читает неопознанный енот. Несмотря на то, что енот совершенно неопознанный, система его все же авторизовала — то есть выдала право прочитать этот документ.
А вот если бы вы открыли этот документ для чтения только определенным пользователям, то еноту в таком случае сперва пришлось бы идентифицироваться (ввести свой логин), потом аутентифицироваться (ввести пароль и одноразовый код) и только потом получить право на чтение документа — авторизоваться.
А уж если речь идет о содержимом вашего почтового ящика, то Google никогда и ни за что не авторизует неопознанного енота на чтение вашей переписки — если, конечно, он не идентифицируется с вашим логином и не аутентифицируется с вашим паролем. Но тогда это уже не будет неопознанный енот, поскольку Google однозначно определит этого енота как вас.
Теперь вы знаете, чем идентификация отличается от аутентификации и авторизации. Что еще важно понимать: аутентификация — пожалуй, самый важный из этих процессов с точки зрения безопасности вашего аккаунта. Если вы ленитесь и используете для аутентификации только слабенький пароль, то какой-нибудь енот может ваш аккаунт угнать. Поэтому:
Аутентификация и авторизация в микросервисных приложениях
Автор: Вячеслав Михайлов, Solutions Architect
Это вводная часть материала, основанного на докладе, прочитанном мной прошлым летом. Печатный материал предполагает больше информации, т.к. в одном докладе обычно не получается рассказать обо всех деталях.
Что такое аутентификация?
На процессах аутентификации и авторизации основано разделения прав доступа, без которого не обходится ни одно более или менее серьезное приложение. Поэтому понимать, как они происходили раньше и происходят теперь, очень важно, но, прежде чем углубиться в описание технологии, давайте разберемся с ключевыми терминами.
Идентификация — процесс определения, что за человек перед нами. Аутентификация — процесс подтверждения, что этот человек именно тот, за кого себя выдает. Авторизация — процесс принятия решения о том, что именно этой аутентифицированной персоне разрешается делать. То есть, это три разных, последовательных и взаимно не заменяемых понятия. Идентификацию часто подразумевают в составе аутентификации. Самое главное — четко различать аутентификацию и авторизацию.
В ходе аутентификации мы удостоверяемся, что человек, который к нам пришел, обладает доказательствами, подтверждающими личность. В этой статье речь в основном пойдет как раз об аутентификации.
Способы аутентификации
При использовании HTTP-протокола простейший способ аутентификации — Basic access authentication. В принципе этот протокол устарел и уже редко используется в интернете, особенно в незащищенных соединениях, но еще сохраняется во внутрикорпоративных системах, просто потому что некоторые из них созданы достаточно давно. Стоит разобраться, как он работает.
HTTP Basic Authentication
Первым, что при обращении к защищенному ресурсу сервер выдаст пользователю, не имеющему доступа, будет ошибка 401 Unauthorized. При этом ответ также содержит информацию о типе аутентификации (в нашем случае – Basic), который он может принимать, и контекст, в рамках которого эта аутентификация действует (Realm). Пользователь вводит логин и пароль, они упаковываются в Base64 и отправляются на сервер для проверки. Здесь существуют различные опасности. Самая распространенная — угроза man-in-the-middle attack, или атаки посредника, в ходе которой при использовании незащищенного соединения учетные данные могут перехватить злоумышленники в момент передачи от клиента к серверу или обратно.
HTTP Digest Authentication
Следующим этапом развития технологии стала чуть более сложная система HTTP digest authentication, которая исключает передачу учетных данных в открытом виде — здесь для проверки используется MD5-хеш с некоторыми примесями, что позволяет избежать подбора логина и пароля. Конечно, этот алгоритм выглядит более надежным, но и он подвержен целому ряду не самых сложных атак. Например, вот тут можно почитать об атаках более подробно.
Forms Authentication
Позднее появился процесс Forms authentication, при котором аутентификация происходит на более высоком уровне модели абстракции. HTTP-сервер при этом не сообщает об ошибке доступа, а просто перенаправляет неаутентифицированного пользователя на другую страницу. Обычно на этой странице отображаются поля для ввода логина и пароля, после заполнения которых формируется POST-запрос с данными и через защищенный канал направляется на сервер. Серверная сторона в свою очередь возвращает пользователю токен или идентификатор сессии, который сохраняется в Cookies и в дальнейшем используется для доступа к защищенному ресурсу.
Token Authentication
На схеме хорошо видно, как и в какой последовательности приложения обмениваются информацией при использовании аутентификацией по токенам.
На следующей схеме дополнительно отражены те этапы взаимодействия, в которых пользователь принимает непосредственное участие. Этот момент и является недостатком подобной схемы — нам всегда нужен пользователь, чтобы получить доступ к ресурсу.
OAuth2 & Open ID Connect
Дальнейшее усовершенствование процесса понадобилось ввиду того, что токен-аутентификация требует присутствия пользователя в момент получения доступа к защищенному ресурсу. Потому что Identity provider при передаче ему управления будет с пользователем взаимодействовать, запрашивая, например, логин и пароль.
В случае сервиса, который от имени пользователя должен через определенные промежутки времени опрашивать некий третий ресурс, — допустим, получать доступ к списку контактов в социальной сети — токен-аутентификация работать уже не будет. Дело в том, что идентификаторы сессии обычно живут очень недолго, чтобы в случае их перехвата злоумышленники получили доступ к сервису лишь на ограниченное время. Но из-за короткого срока действия токена не хватает, например, на ночной процесс.
В 2006 году в ходе работы над реализацией протокола Open ID для Twitter обнаружилась потребность в новом открытом протоколе авторизации. В 2007 инженеры Google и AOL начали совместную работу над ним, а в 2009 Twitter предложил своим пользователям решение, делегировавшее сторонним сервисам доступ к аккаунтам и основанное на протоколе OAuth. Три года спустя была опубликована новая версия — OAuth 2, упростившая разработку клиентских приложений и получившая целый ряд новых возможностей, среди которых оказалось и обновление токена без участия пользователя. Многие сервисы начали использовать этот протокол еще до его официального утверждения.
Разбираемся детально ху из ху
OpenID 1.0 (2006) & OpenID 2.0 (2007) позволяли приложению(арб) запрашивать у доверенного сервера (authority) проверку пользователя(user). Отличия между версиями для нас несущественны.
Взгляд сверху
Обычно в системах встречаются разные компоненты: пользователи, работающие через браузер, пользователи, взаимодействующие с сервером через мобильные приложения, и просто серверные приложения, нуждающиеся в принадлежащих вам данных, хранящихся на других серверах, доступ к которым осуществляется через Web API.
Single sign-on — технология единого входа — позволяет пользователю переключаться между различными приложениями без повторной аутентификации. Используя SSO можно избежать множественных логинов, так что пользователь просто не будет замечать этих переключений. При этом ситуации, когда в рамках вашей инфраструктуры таких приложений будет больше одного, встречаются постоянно. Технология единого входа особенно удобна в больших энтерпрайз-системах, состоящих из десятков приложений, слабо связанных между собой. Вряд ли пользователи будут довольны, вводя логин и пароль при каждом обращении к системе учета рабочего времени, корпоративному форуму или внутренней базе документов.
В качестве реализации мы рассматриваем протокол OAuth2. В принципе, существуют и другие, например, Kerberos, успешно взаимодействующий с Windows, но в случае гетерогенной сети, в которой существуют компьютеры, использующие и Windows-, и Mac-, и UNIX-системы, использовать проприетарные протоколы зачастую неудобно. Тем более, это касается случаев, когда доступ к вашим сервисам осуществляется через веб — здесь OAuth2 оказывается лучшим кандидатом.
На рисунке выше показано, какие именно протоколы используются при каждом типе взаимодействия.
Как мы знаем из раздела «разбираемся детально ху из ху», OpenID Сonnect нужен, чтобы получить у пользователя его учетные данные и проверить их. OAuth 2.0 нужен, чтобы получать токены доступа и с ними обращаться к ресурсам.
Терминология OAuth2 & OpenID Connect
Сервис выдачи токенов
Open ID Connect Provider — важнейший объект всей конструкции централизованного сервиса аутентификации, он также может называться Security Token Service, Identity Provider authorization server и т. д. Различные источники называют его по-разному, но по смыслу это сервис, который выдает токены клиентам.
Клиент
Client — устройство или программа (браузер, приложение), которым требуется либо токен для аутентификации пользователя, либо токен для доступа к какому-то ресурсу (подразумевается, что данный ресурс «знаком» с тем конкретным «Security Token Service» у которого клиент запрашивает токен для доступа).
Пользователь
User — собственно конечный пользователь — человек.
Область (scope)
Scope — идентификатор ресурса, к которому клиент хочет получить доступ. Список scope посылается в адрес сервиса выдачи токенов в составе запроса на аутентификацию.
По умолчанию все клиенты имеют возможность запрашивать любые области, но это можно (и нужно) ограничивать в конфигурации сервиса выдачи токенов.
Scopes бывают двух видов:
Запрос на аутентификацию
Authentication/Token Request — процесс запроса аутентификации.
Токен личности
Identity Token — подтверждение аутентификации. Этот токен содержит минимальный набор информации о пользователе.
Токен доступа
Access Token — информация, что конкретному пользователю разрешается делать. Клиент запрашивает Access Token и затем использует его для доступа к ресурсам (Web APIs). Access Token содержит информацию о клиенте и пользователе, если она присутствует. Важно понимать, что есть такие типы авторизации, при которых пользователь в процессе непосредственно не участвует (подробнее об этом в следующей части)
Токен обновления
Refresh Token — токен, по которому STS вернет новый Access Token. В зависимости от режима работы, Refresh Token может быть многоразовым и одноразовым. В случае с одноразовым токеном, при запросе нового Access Token будет также сформирован готовый Refresh Token, который следует использовать при повторном обновлении. Очевидно, что одноразовые токены более безопасны.
Более подробно о составе токенов в разделе «структура токена».
Процесс аутентификации
При обращении пользователя к клиенту, тот перенаправляет пользователя на Open ID Connect Provider, который запрашивает у пользователя логин и пароль. В случае успешного прохождения проверки параметров аутентификации он возвращает назад identity token и access token, с которыми пользователь может обращаться к защищенному ресурсу.
Структура токена
Формат
В реализации OAuth2 используется так называемый jwt-токен, который состоит из трех частей. Допустим, при обращении к Identity provider вы отправляете логин/пароль и в ответ получаете токен. Он будет включать в себя: Header (заголовок), Payload (контент) и Signature (подпись). На сайте jwt.io его можно декодировать и посмотреть содержимое формате JSON. На этом сайте вы также найдете описание правил формирования jwt-токенов.
В том, что токены в процессе обмена передаются незашифрованными, ничего страшного нет. Мы изначально исходим из предположения, что коммуникация происходит по защищенному HTTPS-каналу, и повторное шифрование токена было бы избыточным. Единственное, в чем нам нужно убедиться – то, что токен не был подменен или сфальсифицирован на клиентской стороне, для этого достаточно иметь подпись и проверять ее на сервере. Кроме того, токен не содержит никакой критически важной информации.
Кроме identity tokens, есть еще и аccess tokens, которые содержат информацию о выданных пользователю клеймах. Срок действия access token достаточно короткий, потому что его хищение может обеспечить несанкционированный доступ к ресурсу. Т. е. злоумышленник, если ему удастся заполучить токен этого типа, доступ получит на очень непродолжительное время. Для получения нового access token используется refresh token, который обычно не фигурирует в незащищенных средах, в частности в режиме доступа из браузера он вообще не используется. Какие именно токены будут возвращены клиенту в процессе аутентификации, разберемся в следующей части.
Основные поля
Кратко остановимся на том, какие есть стандартные полях в токене и зачем они нужны:
Заключение первой части
В этой статье мы постарались дать теоретический и терминологический фундамент, который понадобится нам создании работающего решения в следующих статьях.
Минимальная реализация интеграция Identity Server в ваше приложение выглядит так:
Минимальная реализация интеграции веб-клиента с Identity Server:
Минимальная реализация интеграции веб-API с Identity Server:
Чем отличаются идентификация, аутентификация и авторизация?
В наши дни не обязательно идти в банк, чтобы совершить какие-либо денежные переводы; не обязательно идти в энергопоставляющую компанию, чтобы оплатить счет за электрический свет; не обязательно идти на железнодорожный вокзал, чтобы приобрести билеты на поезд — все эти и другие подобные вопросы, занимающие массу времени, упрощаются и решаются с помощью Интернета.
Сегодня есть множество областей, где выполнение задачи достигается за счет взаимодействия человека с компьютером — путем использования какого-либо сайта или приложения на мобильном устройстве. Подобные системы должны иметь надлежащий уровень защиты и первое с чем сталкивается пользователь при их использование — это идентификация, аутентификация и авторизация. В чем разница между ними? Давайте рассмотрим подробнее.
Что такое идентификация?
Предположим, что есть определенная система или база данных, где содержится ряд из параметров (идентификаторов), например:
Каждый раз, когда что-либо покупаете в Интернете, где-либо регистрируетесь, Вы получаете идентификатор — определенный параметр позволяющий взаимодействовать с системой. Как правило, он является уникальным — не пересекается с другими информационными системами, участниками и пользователями. Таким образом, при необходимости получить доступ к системе или узнать какие-либо сведения, потребуется предоставить один или несколько идентификаторов. Исходя из этого, можно сказать, что идентификации — процесс позволяющий однозначно определить (распознать) субъект или объект, по его идентификатору, в той или иной системе.
Для большего понимания давайте рассмотрим на примере простой ситуации. Вы находитесь дома, занимаетесь своими делами: смотрите фильмы для взрослых, делаете физические упражнения или читаете статью про кибербезопасность на моём сайте. В один момент Вы слышите звонок в дверь, прекращаете заниматься своей деятельностью и направляетесь открывать. Подойдя к двери смотрите в глазок, но никого не видите, спрашиваете: «Кто там?» и слышите в ответ: «Это я, ИМЯ человека!». Имя человека по ту стороны двери, в данной ситуации, является идентификатором. Правильный или неправильный ответ на вопрос — процесс идентификации.
Рассмотрим на примере другой ситуации. Вы совершаете звонок в банк с целью получить какую-либо информацию по Вашей банковской карте. Сотрудник, отвечающий на Ваш звонок, прежде чем предоставить информацию, обязан Вас идентифицировать. Помимо номера телефона, он может запросить у Вас другой идентификатор, например, номер банковской карты или ФИО. Ваш ответ, в данном случае — идентификация.
Что такое аутентификация?
Для того чтобы предотвратить несанкционированный доступ к системе и данным, одной лишь идентификации недостаточно, поэтому применяют аутентификацию, а в последнее время, все более актуальным становится вопрос — двухфакторной аутентификации. Использование той или иной характеристики в системе зависит от требуемой надёжности, защищённости и стоимости внедрения.
Понятие аутентификации подразумевает проверку подлинности идентификатора или человека (объекта или субъекта). Для этого выделяют три основных фактора аутентификации:
Для общего понимания, рассмотрим на предыдущих примерах. В первом случае, когда к Вам приходят незваные гости и на вопрос «Кто там?» в ответ слышите только имя — это будет идентификация. Порой ее недостаточно, поэтому если спросить какую-либо информацию (фактор аутентификации), которую знает только данный человек, например: «Какое у Вас имя? Сколько лет? На какой ягодице у Вас родинка? и т.д.», то ответ данного человека — аутентификация.
Во случае общения с сотрудником в банке, если информация или требуемые действия будут выходить за рамки идентификации, то сотрудник, для подтверждения подлинности, попросит уточнить фактор аутентификации, например, кодовое слово или последние 3 операции по карте (с точным перечислением содержимого и стоимости). Ваш ответ на его запрос — процесс аутентификации.
Что такое авторизация?
Предоставление доступа к той или иной системе, присутствие в ней и выполнения определенных действий — авторизация. Понятие подразумевает, что человек прошедший авторизацию получает полное право выполнять действия в рамках его привилегий и полномочий, для этого в информационной системе могут применять три основные категории:
Если рассмотреть на приведенных примерах, то в первом случае, если человек пройдет идентификацию и аутентификацию, и Вы откроете ему дверь для доступа в квартиру — это будет считаться авторизацией.
Связь между идентификацией, аутентификацией и авторизацией
«. скованные одной цепью
связанные одной целью. »
Все три выше перечисленных процесса взаимодействуют между собой и не существуют друг без друга. В первую формируется идентификатор, затем происходит подтверждения подлинности и соответствия, а в последствие — Вы пользуетесь всеми возможностями и преимуществами системы, в рамках своих полномочий.
В Интернете на каком-либо сайте это будет выглядеть подобным образом:
К слову говоря, Вы сразу же перейти к практике — зарегистрироваться здесь на сайте, затем войти с помощью логина и пароля и воспользоваться возможностями, которые имеют только пользователи, например, написать комментарий.