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

• Tutorial

Автор: Вячеслав Михайлов, Solutions Architect Это вводная часть материала, основанного на докладе, прочитанном мной прошлым летом. Печатный материал предполагает больше информации, т.к. в одном докладе обычно не получается рассказать обо всех деталях. Мы разберемся с процессом аутентификации пользователя, работой технологии единого входа (Single sign-on/SSO), дадим общее представлении о технологии OAuth2 и принципах ее работы, не углубляясь в особенности конкретной технической реализации. В следующей статье в качестве примера удачной реализации мы рассмотрим библиотеку Thinktecture Identity Server v3, подробнее остановимся на ее функциональных возможностях, поговорим, как собрать минимальный набор компонент, необходимый для работы в микросервисной архитектуре и достойный использования в боевой системе. В третьей части мы покажем, как расширять эту библиотеку, подстраиваясь под нужды вашей системы, а завершит цикл статей разбор различных сценариев, встречавшихся в жизни многих разработчиков с рекомендациями для каждого случая. На процессах аутентификации и авторизации основано разделения прав доступа, без которого не обходится ни одно более или менее серьезное приложение. Поэтому понимать, как они происходили раньше и происходят теперь, очень важно, но, прежде чем углубиться в описание технологии, давайте разберемся с ключевыми терминами. Идентификация — процесс определения, что за человек перед нами. Аутентификация — процесс подтверждения, что этот человек именно тот, за кого себя выдает. Авторизация — процесс принятия решения о том, что именно этой аутентифицированной персоне разрешается делать. То есть, это три разных, последовательных и взаимно не заменяемых понятия. Идентификацию часто подразумевают в составе аутентификации. Самое главное — четко различать аутентификацию и авторизацию. В ходе аутентификации мы удостоверяемся, что человек, который к нам пришел, обладает доказательствами, подтверждающими личность. В этой статье речь в основном пойдет как раз об аутентификации. При использовании 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

Следующее поколение способов аутентификации представляет Token Based Authentication, который обычно применяется при построении систем Single sign-on (SSO). При его использовании запрашиваемый сервис делегирует функцию проверки достоверности сведений о пользователе другому сервису. Т. е. провайдер услуг доверяет выдачу необходимых для доступа токенов собственно токен-провайдеру (Identity provider). Это то, что мы видим, например, входя в приложения через аккаунты в социальных сетях. Вне IT самой простой аналогией этого процесса можно назвать использование общегражданского паспорта. Официальный документ как раз является выданным вам токеном — все государственные службы по умолчанию доверяет отделу полиции, который его вручил, и считает паспорт достаточным для вашей аутентификации на протяжении всего срока действии при сохранении его целостности. На схеме хорошо видно, как и в какой последовательности приложения обмениваются информацией при использовании аутентификацией по токенам. На следующей схеме дополнительно отражены те этапы взаимодействия, в которых пользователь принимает непосредственное участие. Этот момент и является недостатком подобной схемы — нам всегда нужен пользователь, чтобы получить доступ к ресурсу.

OAuth2 & Open ID Connect

Дальнейшее усовершенствование процесса понадобилось ввиду того, что токен-аутентификация требует присутствия пользователя в момент получения доступа к защищенному ресурсу. Потому что Identity provider при передаче ему управления будет с пользователем взаимодействовать, запрашивая, например, логин и пароль. В случае сервиса, который от имени пользователя должен через определенные промежутки времени опрашивать некий третий ресурс, — допустим, получать доступ к списку контактов в социальной сети — токен-аутентификация работать уже не будет. Дело в том, что идентификаторы сессии обычно живут очень недолго, чтобы в случае их перехвата злоумышленники получили доступ к сервису лишь на ограниченное время. Но из-за короткого срока действия токена не хватает, например, на ночной процесс. В 2006 году в ходе работы над реализацией протокола Open ID для Twitter обнаружилась потребность в новом открытом протоколе авторизации. В 2007 инженеры Google и AOL начали совместную работу над ним, а в 2009 Twitter предложил своим пользователям решение, делегировавшее сторонним сервисам доступ к аккаунтам и основанное на протоколе OAuth. Три года спустя была опубликована новая версия — OAuth 2, упростившая разработку клиентских приложений и получившая целый ряд новых возможностей, среди которых оказалось и обновление токена без участия пользователя. Многие сервисы начали использовать этот протокол еще до его официального утверждения. В данный момент на слуху следующие протоколы:

1. OpenID — для проверки учетных данных пользователя (identification & authentication).
2. OAuth — про то, чтобы получать доступ к чему-то.
3. OpenID Connect — и про и то, и про другое одновременно.

Все три протокола позволяют пользователю не разглашать свои секретные логин и пароль недоверенным приложениям. OpenID & OAuth разрабатывались параллельно вплоть до 2014 года и объединились в итоге в OpenID connect.OpenID 1.0 (2006) & OpenID 2.0 (2007) позволяли приложению(арб) запрашивать у доверенного сервера (authority) проверку пользователя(user). Отличия между версиями для нас несущественны.

• User –> App: Привет, это Миша.
• App –> Authority: Вот «это» Миша?
• Authority и User общаются тет-а-тет.
• Authority –> App: Да, это Миша.

OpenID Attribute Exchange 1.0 (2007) расширяет OpenID 2.0 разрешая получать и хранить профиль пользователя.

• User –> App: Привет, это Миша.
• App –> Authority: Вот «это» Миша? И если это Миша, то пришлите мне его email.
• Authority и User общаются тет-а-тет.
• Authority –> App: Да, это Миша. И его email xxx@xxx.xxx.

OAuth 1.0 (2010) позволяет пользователю разрешать приложению получать ограниченный доступ на третьесторонних серверах(third-party server), доверяющих удостоверяющему центру.

• App –> User: Mы бы хотели получить ваши картинки с другого сервера.
• Authority и User общаются тет-а-тет.
• Authority –> App: Вот вам билет (access token) на 15 минут.
• App –> Third-party server: Нам тут по билету можно получить фотографии для этого пользователя.

OAuth 2.0 (2012) делает тоже самое, что и OAuth 1.0, но только протокол существенно поменялся и стал проще.OpenID Connect (2014) объединяет возможности OpenID 2.0, OpenID Attribute Exchange 1.0, и OAuth 2.0 в один общий протокол. Он позволяет приложениям использовать удостоверяющий центр для:

• Проверять учетные данные пользователя.
• Получать профиль пользователя (или его части).

Важно понимать, что OpenID Connect не дает доступ к внешним ресурсам. Он использует OAuth 2.0 для того, чтобы представить параметры профиля как будто это такие ресурсы. Обычно в системах встречаются разные компоненты: пользователи, работающие через браузер, пользователи, взаимодействующие с сервером через мобильные приложения, и просто серверные приложения, нуждающиеся в принадлежащих вам данных, хранящихся на других серверах, доступ к которым осуществляется через Web API. Single sign-on — технология единого входа — позволяет пользователю переключаться между различными приложениями без повторной аутентификации. Используя SSO можно избежать множественных логинов, так что пользователь просто не будет замечать этих переключений. При этом ситуации, когда в рамках вашей инфраструктуры таких приложений будет больше одного, встречаются постоянно. Технология единого входа особенно удобна в больших энтерпрайз-системах, состоящих из десятков приложений, слабо связанных между собой. Вряд ли пользователи будут довольны, вводя логин и пароль при каждом обращении к системе учета рабочего времени, корпоративному форуму или внутренней базе документов. В качестве реализации мы рассматриваем протокол OAuth2. В принципе, существуют и другие, например, Kerberos, успешно взаимодействующий с Windows, но в случае гетерогенной сети, в которой существуют компьютеры, использующие и Windows-, и Mac-, и UNIX-системы, использовать проприетарные протоколы зачастую неудобно. Тем более, это касается случаев, когда доступ к вашим сервисам осуществляется через веб — здесь OAuth2 оказывается лучшим кандидатом. На рисунке выше показано, какие именно протоколы используются при каждом типе взаимодействия.

Как мы знаем из раздела «разбираемся детально ху из ху», OpenID Сonnect нужен, чтобы получить у пользователя его учетные данные и проверить их. OAuth 2.0 нужен, чтобы получать токены доступа и с ними обращаться к ресурсам.

• OpenID Connect Provider (OP)
• Client
• User
• Scope
  • Identity scopes – openid, profile, email
  • Resource scopes – various API
• Authentication/Token Request
• Identity Token
• Access Token
• Refresh Token

Open ID Connect Provider — важнейший объект всей конструкции централизованного сервиса аутентификации, он также может называться Security Token Service, Identity Provider authorization server и т. д. Различные источники называют его по-разному, но по смыслу это сервис, который выдает токены клиентам. Основные функции:

• Аутентифицировать пользователей, используя внутреннее хранилище пользователей или внешний источник (например, Active Directory).
• Управлять клиентами (хранить) и аутентифицировать их.
• Предоставлять управление сессией и возможность реализации Single sing-on.
• Выдавать identity-токены и access-токены клиентам.
• Проверять ранее выданные токены.

Клиент

Client — устройство или программа (браузер, приложение), которым требуется либо токен для аутентификации пользователя, либо токен для доступа к какому-то ресурсу (подразумевается, что данный ресурс «знаком» с тем конкретным «Security Token Service» у которого клиент запрашивает токен для доступа).

Пользователь

User — собственно конечный пользователь — человек. Scope — идентификатор ресурса, к которому клиент хочет получить доступ. Список scope посылается в адрес сервиса выдачи токенов в составе запроса на аутентификацию. По умолчанию все клиенты имеют возможность запрашивать любые области, но это можно (и нужно) ограничивать в конфигурации сервиса выдачи токенов. Scopes бывают двух видов:

1. Identity scopes — это запрос информации о пользователе. Его имя, профиль, пол, фотография, адрес электронной почты и т. д.
2. Resource scopes — имена внешних ресурсо (Web APIs), к которым клиент хочет получить доступ.

Authentication/Token Request — процесс запроса аутентификации. В зависимости от того какие области (scopes) запрошены, сервис выдачи токенов вернет:

1. Только Identity Token, если запрошены только Identity scopes.
2. Identity Token и Access Token, если запрошены также и Resources scopes.
3. Access Token и Refresh Token, если запрошeн Offline Access.

Более подробно про процесс аутентификации можно прочесть в разделе «процесс aутентификации». 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, который обычно не фигурирует в незащищенных средах, в частности в режиме доступа из браузера он вообще не используется. Какие именно токены будут возвращены клиенту в процессе аутентификации, разберемся в следующей части.

Основные поля

Кратко остановимся на том, какие есть стандартные полях в токене и зачем они нужны:

• iss — адрес или имя удостоверяющего центра.
• sub — идентификатор пользователя. Уникальный в рамках удостоверяющего центра, как минимум.
• aud — имя клиента для которого токен выпущен.
• exp — срок действия токена.
• nbf — время, начиная с которого может быть использован (не раньше чем).
• iat — время выдачи токена.
• jti — уникальный идентификатор токен (нужен, чтобы нельзя был «выпустить» токен второй раз).

В этой статье мы постарались дать теоретический и терминологический фундамент, который понадобится нам создании работающего решения в следующих статьях. Stay tuned.Спойлер второй частиМинимальная реализация интеграция Identity Server в ваше приложение выглядит так:

public void Configuration(IAppBuilder app) {     var factory = new IdentityServerServiceFactory();     factory.UseInMemoryClients(Clients.Get())            .UseInMemoryScopes(Scopes.Get())            .UseInMemoryUsers(Users.Get());      var options = new IdentityServerOptions     {         SiteName = Constants.IdentityServerName,         SigningCertificate = Certificate.Get(),         Factory = factory,     };      app.UseIdentityServer(options); } 

Минимальная реализация интеграции веб-клиента с Identity Server:

public void Configuration(IAppBuilder app) {     app.UseCookieAuthentication(new CookieAuthenticationOptions     {         AuthenticationType = "Cookies"     });      app.UseOpenIdConnectAuthentication(new OpenIdConnectAuthenticationOptions     {         ClientId = Constants.ClientName,         Authority = Constants.IdentityServerAddress,         RedirectUri = Constants.ClientReturnUrl,         ResponseType = "id_token",         Scope = "openid email",         SignInAsAuthenticationType = "Cookies",     }); } 

Минимальная реализация интеграции веб-API с Identity Server:

public void Configuration(IAppBuilder app) {     app.UseIdentityServerBearerTokenAuthentication(         new IdentityServerBearerTokenAuthenticationOptions         {             Authority = Constants.IdentityServerAddress,             RequiredScopes = new[] { "write" },             ValidationMode = ValidationMode.Local,              // credentials for the introspection endpoint             ClientId = "write",             ClientSecret = "secret"         });      app.UseWebApi(WebApiConfig.Register()); } 

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

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

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

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

Наконец-то открывается заветная дверь, и охранник допускает сотрудника к определенной двери. Допуск получен – состоялась авторизация.

В виртуальном мире все практически так же, как в реальном. Только имена “персонажей” меняются. Сотрудник охраны – это сервер, контролирующий вход на сайт. А пришедший на работу менеджер – пользователь, который хочет попасть в свой аккаунт.

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

Все три понятия – этапы одного и того же процесса, который управляет доcтупом пользователей к их аккаунтам.

Чтобы выполнить какие-либо действия на сайте, клиент должен “представиться” системе. Идентификация пользователя – предъявление им оснований для входа на сайт или сервис. Обычно в роли идентификаторов выступают логин или адрес электронной почты, указанный при регистрации. Если сервер находит в своей базе данные, совпадающие с указанными, то происходит идентификация клиента.

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

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

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

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

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

Two factor authentication может быть как односторонней – когда только пользователь доказывает системе свою истинность, так и двусторонней – сервер и клиент взаимно подтверждают свою подлинность по системе “запрос-ответ”. Такой тип 2FA используется в токене Protectimus Ultra и позволяет, среди прочего, устранить риск попадания на фишинговые сайты.

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

Между терминами “авторизация” и “аутентификация” разница довольно значительна. Часто можно услышать или прочитать в интернете выражение “двухфакторная авторизация”, но оно, строго говоря, не является корректным. Ведь авторизация пользователя – это предоставление ему полномочий в какой-либо системе, окончательный ответ на вопрос: “Можно ли допустить этого человека к той или иной информации или функциям?”. И в силу своей однозначности авторизация никак не может быть двухфакторной.

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

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

Subscribe To Our Newsletter

Join our mailing list to receive the latest news and updates from our team.

You have Successfully Subscribed!

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

Содержание статьи

Определение

Аутентификация – прохождение проверки подлинности.

Авторизация – предоставление и проверка прав на совершение каких-либо действий в системе.

Естественно, и аутентификацию, и авторизацию используют не только в процессе получения доступа к сетевым аккаунтам. Автоматизированные системы, EDI, передача данных, пластиковые банковские карты – мы не один раз в день проходим эти процедуры в автоматическом режиме.

В англоязычных системах путаницы с терминологией не возникает: пользователь вообще не задумывается, чем отличается аутентификация от авторизации, ведь обе процедуры от его глаз скрыты. Предлагается «войти в систему» – «log in, logging in».

Рекламак содержанию ↑

Сравнение

Как проходит процедура аутентификации? Вот некий пользователь вознамерился прочитать свежий спам в своем электронном почтовом ящике. Он заходит на сайт почтового сервиса, читает рекламу и новости, но никаких писем ему пока не показывают – система не знает ни о его личности, ни о его намерениях. Когда в форму ввода логина и пароля он впишет свои «username/qwerty» и отправит эту информацию, начнется процесс аутентификации. Система проверит, существует ли пользователь с таким именем, совпадает ли введенный пароль с его учетной записью. Во многих случаях соответствия подобных идентификаторов достаточно, однако сервисы, где безопасность данных в приоритете, могут запрашивать и другие сведения: наличие сертификата, определенный IP-адрес или дополнительный код верификации.

Пройденная аутентификация означает, что пользователь действительно тот, кем представляется. Однако этого мало для предоставления ему доступа к данным – начинается процесс авторизации. В случае с почтовыми сервисами клиенты имеют равные права: каждый из них может просматривать письма и документы, редактировать их и создавать новые. А вот в социальных сетях или на форумах посетители принадлежат к определенной группе, и авторизация помогает системе определить, что позволено Юпитеру и не позволено быку. К примеру, у вас нет права писать сообщения пользователю, который добавил вас в черный список; вы не можете добавлять в сообщения ссылки на видео, пока не набрали определенное количество постов; вы можете просматривать фотографии человека, добавившего вас «в друзья». В локальных системах у учетной записи пользователя может не быть доступа к некоторым программам, стоять запрет на редактирование или копирование документов.

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

Запомнить, в чем разница между аутентификацией и авторизацией, обычно позволяет аналогия с закрытыми объектами промышленных комплексов. При входе посетитель предъявляет удостоверение личности (ввод логина и пароля), а сотрудник охраны проверяет по базе данных, можно ли этого человека впустить. Если документ подлинный и фамилия есть в списке – вход на территорию объекта разрешен. Чтобы попасть в лабораторию, нужен один пропуск, в пресс-центр – другой, на вывоз мусора – третий. Служба безопасности проверяет право на доступ к объектам и разрешает или запрещает персоналу определенные действия. Так проходит авторизация.

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

к содержанию ↑

Таблица

Дата публикации: 29.01.2017

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

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

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

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

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

Факторы аутентификации

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

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

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

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

Примером MFA является использование банковских карт. Наличие карты – первый фактор защиты, введение пин-кода – второй.

Авторизация

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

Например, процесс проверки и подтверждения идентификаторов сотрудников и паролей в организации называется аутентификацией, но определение того, какой сотрудник имеет доступ к определенным ресурсам, называется авторизацией. Предположим, что вы путешествуете и собираетесь сесть на самолет. Когда вы предъявляете свой билет и удостоверение личности перед регистрацией, то получаете посадочный талон, который подтверждает, что администрация аэропорта удостоверила вашу личность. Но это не все. Чтобы получить доступ к внутренней части самолета и его ресурсам, вам необходимо получить разрешение бортпроводника на посадку.

Заключение

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

Какие уровни входа и ввода сведений существуют

Условно данный процесс делится на два уровня:

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

Довольно часто вместо этих терминов используются упрощенные термины – авторизация и проверка подлинности.

Данный процесс достаточно простой, его можно рассмотреть на примере одной из соцсетей:

• Регистрация – юзер вписывает свой email, телефонный номер, код. Это уникальные сведения, их нельзя дублировать в системе, поэтому нельзя зарегистрировать больше одной учетной записи на пользователя;
• Идентификация – вы вписываете указанные в процессе регистрации данные, в нашем случае это электронка и пароль;
• Аутентификация – когда вы нажимаете клавишу «вход», страничка связывается с сервером и выполняет сканирование наличия этой комбинаций пароля и логина. Если все введено корректно, будет открыта страничка соцсети.

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

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

Есть несколько типов определения подлинности, различающихся по уровню защиты и использованию:

• Защита с паролем. Юзер знает ключ, неизвестный никому. Сюда же относится идентификация через получение SMS;
• Привлечение предметов. Привлекают компании и фирмы. То есть тут используются карточки, брелки, флешки и прочее;
• Биометрическая проверка. Проверяется глазная сетчатка, голос, отпечатки пальцев. Это практически самая мощная системная защита;
• Скрытые данные. Чаще всего привлекается для защиты ПО. Проверяется кэш обозревателя, местоположение, которое установлено на компьютер.

Пароли

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

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

Что делать, если появилось сообщение: «Аудиозапись недоступна для прослушивания в вашем регионе»?Способы просмотра статистики в ИнстаграмеСоздание стикеров в TelegramОнлайн генераторы случайных чисел для розыгрышаКак включить ленту новостей Яндекс.ДзенОшибка 502 bad gateway — перевод на русский и причины появления

Специальные предметы

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

Биометрические системы

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

Отличие авторизации от аутентификации

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

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

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

Используемые источники:

• https://habr.com/post/311376/
• https://www.protectimus.com/blog/ru-identification-authentication-authorization/
• https://thedifference.ru/chem-otlichaetsya-autentifikaciya-ot-avtorizacii/
• https://artismedia.by/blog/difference-between-authentication-and-authorization/
• https://life-v.ru/authorization-and-authentication-difference/