Аутентификация и авторизация разница: Чем отличается аутентификация от авторизации

Чем отличается аутентификация от авторизации

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

Определение

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

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

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

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

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

Сравнение

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

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

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

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

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

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

Таблица

В чем состоит разница между аутентификацией и авторизацией

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

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

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

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

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

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

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

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

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

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

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

Авторизация

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

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

Заключение

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

Авторизация и аутентификация – в чём отличие [ОБЗОР]

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

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

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

Основные определения

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

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

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

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

Принцип работы

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

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

Читайте также на сайте:

…

…

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

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

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

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

Основные отличия терминов

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

1. Технология предназначена для непосредственной проверки личности пользователя.
2. Проведение данной процедуры полностью зависит от информации, которую даёт юзер. Другими словами, если указать неверный логин, либо же допустить ошибку в пароле, то система не сможет распознать пользователя, соответственно, аутентификация не будет произведена.
3. Процедура производится однократно для того, чтобы попасть в учётную запись конкретного ресурса в рамках одной сессии.

Что же касается авторизации, то она характеризуется следующими особенностями:

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

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

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

ПОЛЕЗНОЕ ВИДЕО

…

…

Я только обозреваю программы!

Любые претензии — к их производителям!

Комментарии публикуются после модерации.

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

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

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

Определения

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

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

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

Механизмы идентификации, аутентификации и авторизации

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

Ввод этих данных необходим для идентификации человека за монитором как пользователя конкретно этого банка.

Если пользователь в качестве идентификатора ввел «Александр Петров», и система нашла в своей базе запись о пользователе с таким именем, то идентификация завершилась.

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

• Нечто, присущее только пользователю. Биометрические данные: сканеры лица, отпечатки пальцев или сетчатки глаза.
• Нечто, известное только пользователю. Сюда относятся pin-коды, пароли, графические ключи, секретные слова.
• Нечто, имеющееся у пользователя. В данном качестве может выступать токен, то есть компактное устройство, предназначенное для обеспечения информационной безопасности пользователя, также используется для идентификации владельца. Самые простые токены не требуют физического подключения к компьютеру – у них имеется дисплей, где отображается число, которое пользователь вводит в систему для осуществления входа; более сложные подключаются к компьютерам посредством USB и Bluetooth-интерфейсов.

Самый распространенный тип аутентификационных данных – это пароль. Именно поэтому так важно создавать и правильно хранить свои пароли. Подробнее об этом можно прочитать в статьях «Создание надежных паролей» и «Как правильно выбирать и хранить пароли».
После ввода пользователем пароля система проверяет: соответствует ли условный пароль «Q45fp02@13» пользователю с именем Александр Петров. Таким образом происходит аутентификация.
Если все верно, и пара логин-пароль верны, то система предоставит пользователю доступ к его ресурсам и совершение банковских операций, то есть произойдет авторизация.

Описанные процессы всегда происходят только в таком порядке: идентификация, аутентификация, авторизация. Вся цепочка потеряет смысл, если, например, сайт сначала предоставит доступ к денежным средствам пользователя, а потом будет уточнять, он ли это на самом деле.
Процессы идентификации, аутентификации и авторизации характерны не только для онлайн-банкинга, но и для электронной почты, социальных сетей и других ресурсов.
В реальной жизни мы также сталкиваемся идентификацией, аутентификацией и авторизацией. Примером может служить проверка документов сотрудником полиции. Вы представились как Александр Петров, и сотрудник полиции идентифицировал Вас как Александра Петрова. Для аутентификации необходим паспорт, в котором видно, что Александр Петров выглядит так же, как и вы. Авторизацией в данном случае будет то, что сотрудник отпустит вас и пожелает счастливого пути, т.е. предоставит право свободного перемещения.
Процессы идентификации, аутентификации и авторизации есть во многих сферах. Даже в простейших детских сказках. Сказка «Волк и семеро козлят» является идеальным примером для демонстрации.
Здесь козлята выступают в роли системы безопасности, идентифицируя каждого, кто подходит к двери. В качестве данных для аутентификации выступает биометрия – тонкий голосок мамы-козы. И если в первый раз волк не смог пройти аутентификацию (его выдал грубый голос), то со второй попытки (после того как ему перековали горло, и он запел тонким голоском) он аутентифицировался как мама-коза и козлята «авторизовали» его в свою избу.
Несмотря на то, что сказка закончилась благополучно, доступ к козлятам был получен неправомерно. Волку удалось обмануть процессы идентификации и аутентификации и тем самым пройти авторизацию.
Если в старой детской сказке это оказалось возможным, то что говорить о современных злоумышленниках. Чтобы защитить свои денежные средства и персональные данные и козлят от волка от злоумышленника необходимо использовать более сложные способы аутентификации.

Многофакторная аутентификация

Многофакторная аутентификация представляет собой метод, при котором пользователю для доступа к учетной записи или подтверждения операции с денежными средствами необходимо двумя различными факторами доказать, что именно он владелец учетной записи или что именно он осуществляет вход.
Среди видов многофакторной аутентификации наиболее распространена двухфакторная аутентификация (2FA — 2-factor authentication) – метод, при котором пользователю для получения доступа необходимо предоставить два разных типа аутентификационных данных, например, что-то известное только пользователю (пароль) и что-то присущее только пользователю (отпечаток пальца).

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

Однофакторная двухэтапная аутентификация

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

Аутентификация происходит следующим образом:

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

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

Рекомендации

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

Авторизация и аутентификация для всех

Оригинальная статья: Kim Maida — Authorization and Authentication For Everyone

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

Аутентификация — это сложно. Почему так? Стандарты Auth хорошо определены, но в них сложно разобраться. И это нормально! Мы собираемся пройти через это максимально доступным способом. Мы рассмотрим концепции идентификации шаг за шагом, опираясь на наши знания по мере продвижения вперед. К тому времени, когда мы закончим, вы должны иметь фундамент и знать, куда нужно обратиться если вам нужно будет больше информации.

Введение

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

Появление OAuth

Все эти недостатки приводит нас к OAuth.

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

Используя OAuth, пользователь теперь может делегировать HireMe123 для вызова MyCalApp от имени пользователя. MyCalApp может ограничить доступ к своему API при вызове сторонними клиентами без риска совместного использования информации для входа или предоставления слишком большого доступа. Это делается с помощью:

Сервер авторизации

Сервер авторизации — это набор конечных точек (методов API) для взаимодействия с пользователем и выдачи токенов. Как это работает?

Давайте вернемся к ситуации с HireMe123 и MyCalApp, только теперь у нас есть OAuth 2.0:

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

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

HireMe123 отправляет запрос авторизации на сервер авторизации MyCalApp. В ответ сервер авторизации MyCalApp предлагает вам — пользователю — войти в систему с помощью MyCalApp (если вы еще не вошли в систему). Вы аутентифицируетесь с MyCalApp.

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

Если вы скажете «да» и дадите свое согласие, то сервер авторизации MyCalApp отправит код авторизации в HireMe123. Это позволяет HireMe123 знать, что пользователь MyCalApp (вы) действительно согласился разрешить HireMe123 добавлять события с использованием пользовательского (вашего) MyCalApp.

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

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

А как насчет аутентификации?

На данный момент, я надеюсь, стало ясно, что OAuth предназначен для делегированного доступа. Это не распространяется на аутентификацию. В любой момент, когда аутентификация включалась в процессы, которые мы рассмотрели выше, вход в систему осуществлялся любым процессом входа в систему, который HireMe123 или MyCalApp реализовали по своему усмотрению. OAuth 2.0 не прописывал, как это должно быть сделано: он только покрывал авторизацию доступа сторонних API.

Так почему же аутентификация и OAuth так часто упоминаются вместе друг с другом?

Проблема входа в систему

То, что происходит после того, как OAuth 2.0 установил способ доступа к сторонним API, заключается в том, что приложение также требуется регистрировать пользователей у себя. Используя наш пример: HireMe123 нужно, чтобы пользователь MyCalApp мог залогиниться, используя свою учетную запись MyCalApp, даже несмотря на то, что он не был зарегистрирован в HireMe123.

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

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

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

Например:

• Кто-то мог украсть токен доступа у другого пользователя
• Маркер доступа мог быть получен от другого клиента (не HireMe123) и введен в HireMe123

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

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

OpenID Connect

Это подводит нас к спецификации под названием OpenID Connect, или OIDC. OIDC — это спецификация OAuth 2.0, в которой говорится, как аутентифицировать пользователей. OpenID Foundation (OIDF) является руководителем стандартов OIDC.

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

ID Токены

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

OIDC объявляет фиксированный формат для токенов ID, которым является JWT.

JSON Web Token (JWT)

JSON Web Tokens, или JWT (иногда произносится как «jot»), состоит из трех URL-безопасных сегментов строки, соединенных точками. Сегмент заголовка, сегмента полезной нагрузки и крипто сегмента.

Сегмент заголовка

Первый сегмент является сегментом заголовка (header segment). Он может выглядеть примерно так:

eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9

Сегмент заголовка — это объект JSON, содержащий в закодирован виде алгоритм и тип токена. Он закодирован в base64Url (байтовые данные представлены в виде текста, который является URL-адресом и безопасным для имени файла).

Декодированный заголовок выглядит примерно так:

{
  "alg": "RS256",
  "typ": "JWT"
}

Сегмент полезной нагрузки

Второй сегмент — это сегмент полезной нагрузки (payload segment). Он может выглядеть так:

eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWUsImlhdCI6MTUxNjIzOTAyMn0

Это объект JSON, содержащий фрагмент данных называемый claim, который содержат информацию о пользователе и событии аутентификации. Например:

{
  "sub": "1234567890",
  "name": "John Doe",
  "admin": true,
  "iat": 1516239022
}

Оно также кодируется в base64Url.

Крипто сегмент

Последний сегмент — крипто сегмент (crypto segment) или подпись (signature). JWT подписаны, поэтому они не могут быть изменены в процессе использования. Когда сервер авторизации выдает токен, он подписывает его с помощью ключа.

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

Claim

Claim можно перевести как требование, утверждение или как заявление.

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

Аутентификационный Claim

Начнем с информации о событии аутентификации. Вот несколько примеров:

{
   "iss": "https://{you}.authz-server.com",
    "aud": "RxHBtq2HL6biPljKRLNByqehlKhN1nCx",
    "exp": 1570019636365,
   "iat": 1570016110289,
   "nonce": "3yAjXLPq8EPP0S",
  ...
}

Некоторые строки аутентификации в токене ID включают:

• iss (issuer — эмитент): издатель JWT, например, сервер авторизации
• aud (audience — аудитория): предполагаемый получатель JWT; для идентификаторов токенов это должен быть идентификатор клиента приложения, получающего токен
• exp (expiration time — время истечения): время истечения; идентификационный токен не должен быть принят после этого времени
• iat (issued at time — время выпуска): время, когда выдан идентификационный токен

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

Идентификационные данные (Identity Claim)

Claim также включают информацию о конечном пользователе. Вот несколько примеров таких данных:

{
  "sub": "google-oauth3|102582972157289381734",
  "name": "Kim Maida",
  "picture": "https://gravatar[...]",
  "twitter": "https://twitter.com/KimMaida",
  "email": "[email protected]",
  ...
}

Некоторые из стандартных строк профиля в токене ID включают:

• sub (subject): уникальный идентификатор пользователя; строка обязательна
• email
• email_verified
• birthdate
• etc.

После того как мы рассмотрели спецификации OAuth 2.0 и OpenID Connect пришло посмотреть, как применить наши знания в области идентификации.

Аутентификация с помощью ID токенов

Давайте посмотрим на OIDC аутентификацию на практике.

Обратите внимание, что это упрощенная схема. Есть несколько разных потоков в зависимости от архитектуры вашего приложения.

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

Затем клиентское приложение декодирует маркер идентификатора (который является JWT) и проверяет его. Это включает в себя проверку подписи, и мы также должны проверить данные claim. Вот некоторые примеры проверок:

• issuer (iss): был ли этот токен выдан ожидаемым сервером авторизации?
• audience (aud): наше приложение — целевой получатель этого токена?
• expiration (exp): этот токен в течение допустимого периода времени для использования?
• nonce (nonce): мы можем связать этот токен с запросом на авторизацию, сделанным нашим приложением?

После того как мы установили подлинность токена ID, пользователь проходит аутентификацию. Теперь у нас есть доступ к identity claims и мы знаем, кто этот пользователь.

Теперь пользователь аутентифицирован. Пришло время взаимодействовать с API.

Доступ к API с помощью токенов доступа

Мы немного поговорили о токенах доступа ранее, еще когда мы смотрели, как делегированный доступ работает с OAuth 2.0 и серверами авторизации. Давайте посмотрим на некоторые детали того, как это работает, возвращаясь к нашему сценарию с HireMe123 и MyCalApp.

Токены доступа

Токены доступа (Access Token) используются для предоставления доступа к ресурсам. С токеном доступа, выданным сервером авторизации MyCalApp, HireMe123 может получить доступ к API MyCalApp.

В отличие от токенов ID, которые OIDC объявляет как веб-токены JSON, токены доступа не имеют определенного формата. Они не должны быть (и не обязательно) JWT. Однако во многих решениях для идентификации используются JWT как маркеры доступа, поскольку есть готовый формат и он обеспечивает хорошую проверку.

В итоге HireMe123 получает два токена от сервера авторизации MyCalApp: токен идентификации (Token ID) (если проверка пользователя прошла успешна) и токен доступа (Access Token) для доступа к ресурсам конечному пользователю.

Токены доступа прозрачны для клиента

Токены доступа предназначены для API ресурса, и важно, чтобы они были прозрачны для клиента. Зачем?

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

Доступ к ресурсным API

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

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

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

# HTTP заголовок запроса
Authorization: 'Bearer eyj[...]'

Затем авторизованный запрос отправляется в API, который проверяет токен с помощью промежуточного программного обеспечения middleware. Если все проверено, то API возвращает данные (например, JSON) в приложение, запущенное в браузере.

Это замечательно, но есть кое-что, что может произойти с вами прямо сейчас. Ранее мы заявляли, что OAuth решает проблемы с излишним доступом. Как это решается здесь?

Делегирование со Scopes

Как API узнает, какой уровень доступа он должен предоставить приложению, запрашивающему использование его API? Мы делаем это с помощью scopes.

Scopes (Области действия) «ограничивают возможности приложения от имени пользователя». Они не могут предоставлять привилегии, которых у пользователя еще нет. Например, если у пользователя MyCalApp нет разрешения на создание новых корпоративных учетных записей MyCalApp, scopes, предоставленные HireMe123, также никогда не позволят пользователю создавать новые корпоративные учетные записи.

Scopes делегируют управление доступом к API или ресурсу. Затем API отвечает за объединение входящих scopes с фактическими правами пользователя для принятия соответствующих решений по управлению доступом.

Давайте рассмотрим это на нашем примере.

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

• sub: (пользовательский ID на MyCalApp )
• aud: MyCalAppAPI (то есть этот токен предназначен только для API MyCalApp)
• scope: write: events (scope — область действия, в которой говорится, что HireMe123 имеет право использовать API для записи событий в мой календарь)

HireMe123 отправляет запрос в API MyCalApp с токеном доступа в своем заголовке авторизации. Когда MyCalApp API получает этот запрос, он может увидеть, что токен содержит scope write: events.

Но MyCalApp размещает учетные записи календаря для сотен тысяч пользователей. В дополнение к рассмотрению scope в токене, промежуточному программному обеспечению (middleware) API MyCalApp необходимо проверить sub идентификатор пользователя, чтобы убедиться, что этот запрос от HireMe123 может только использовать мои привилегии для создания событий с моей учетной записью MyCalApp.

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

Предоставление согласия

Помните, когда сервер авторизации спрашивал пользователя HireMe123 о его согласии разрешить HireMe123 использовать привилегии пользователя для доступа к MyCalApp?

Этот диалог согласия может выглядеть примерно так:

HireMe123 может запросить множество различных областей, например:

• write:events
• read:events
• read:settings
• write:settings
• …etc.

В общем, мы должны избегать увеличения количества областей с правами пользователя. Тем не менее, можно добавить разные области для отдельных пользователей, если ваш сервер авторизации обеспечивает управление доступом на основе ролей (Role-Based Access Control — RBAC).

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

Ресурсы и что дальше?

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

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

Если вы хотите узнать больше, гораздо больше по этим темам, вот несколько полезных ресурсов для вас:

Выучить больше

Серия видеороликов Learn Identity в документах Auth0 — это лекционная часть нового учебного курса по найму для инженеров в Auth0, представленного главным архитектором Витторио Берточчи. Если вы хотите лично узнать, как это делается в Auth0, она абсолютно бесплатна и доступна для всех.

Спецификации OAuth 2.0 и OpenID Connect являются сложными, но как только вы ознакомитесь с терминологией и получите базовые знания об идентификации, они будут полезны, информативны и станут намного более удобочитаемыми. Почитать их можно здесь: The OAuth 2.0 Authorization Framework и OpenID Connect Specifications..

JWT.io — это ресурс о JSON Web Token, который предоставляет инструмент отладчика и каталог библиотек подписи/проверки JWT для различных технологий.

OpenID Connect Playground — это отладчик, который позволяет разработчикам шаг за шагом исследовать и тестировать вызовы и ответы OIDC.

Спасибо!

Если вы хотите пообщаться, я доступен в Твиттере на @KimMaida, и я также выступаю на конференциях и мероприятиях. Я надеюсь увидеть вас когда-нибудь, и большое спасибо за чтение!

Была ли вам полезна эта статья?

[5 / 4.6]

Аутентификация, Идентификация, Авторизация — в чём разница, что такое Двухфакторная Аутентификация (2FA — двухэтапная)

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

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

Также назовем, чем эти три термина связаны и чем отличаются.

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

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

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

• Пароль – это введенное при регистрации слово, выданный графический ключ либо PIN-код.
• Механизм – в качестве такого устройства может быть использована карточка либо USB-ключ.
• Биометрика – это сетчатка глаза, отпечаток пальца, голос либо фото.

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

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

Аутентификация состоит из следующих операций:

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

1. Пользователем вводится логин и пароль.
2. Веденная информация сравнивается с информацией в базе данных: при правильном вводе, пользователь попадает в нужный ему раздел (кабинет, страницу).

Пароль проходит проверку:

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

1. С применение шифров SSL или TLS.
2. В открытом виде.

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

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

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

Двухфакторная Аутентификация подразумевает высший уровень защиты и состоит из таких этапов:

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

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

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

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

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

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

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

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

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

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

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

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

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

В целом процедура идентификации и процедура аутентификации напрямую зависят друга от друга. Успешное завершение этих операций подразумевает доступ к запрашиваемой системе — авторизация.

Регистрируясь на каком-либо сайте либо в приложении вы получаете номер либо имя – логин – который и является идентификатором.

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

• Серия и номер паспорта.
• Номер мобильного телефона.
• Адрес электронной почты.
• Номер аккаунта в социальной сети.
• Номер банковской карточки.
• Номер машины.
• IMEI телефона.
• Другое.

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

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

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

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

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

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

Какие могут быть Ошибки

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

• В первую очередь, проверьте, правильно ли вы написали ключевую фразу, далее посмотрите, не активирована ли на клавиатуре клавиша Caps Lock (печать большими буквами). Если причины не в этом, то, скорее всего, неверно введен пароль.
• Если вы не помните свой пароль, то его можно посмотреть в настройках к вайфай-роутеру.

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

• Итак, вы проверили правильность указанных данных, учитывая язык и размер букв.

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

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

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

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

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

Читайте также: Что такое Стартап, Майнинг, Биткоин-Краны, символ @

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

Однако также мы можем сказать, что они не могут существовать друг без друга.

👥 Что такое AAA (аутентификация, авторизация и аккаунтинг)? — Information Security Squad

AAA (Authentication, Authorization and Accounting) или аутентификация, авторизация и аккаунтинг  — это термин, используемый для описания трех функций в ИТ.

В основном AAA используется для управления доступом к различным ИТ-ресурсам, таким как сеть, службы, сервера и т. д.

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

Что такое аутентификация?

Аутентификация — это процесс идентификации пользователя или инстанса.

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

Например, во время входа в Gmail нам потребуется ввести правильное существующее имя пользователя и пароль для аутентификации.

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

Существуют также различные методы аутентификации, такие как сертификаты, открытые/закрытые ключи, токены, изображения и т. д., а также биометрия.

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

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

Второй шаг в AAA — авторизация.

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

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

Авторизация будет строго указывать и устанавливать права аутентифицированного пользователя.

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

Что такое аккаунтинг?

Когда пользователь аутентифицирован и успешно авторизован, он заходит в систему и ему предоставляется какой-то ресурс.

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

При использовании этих ресурсов доступ пользователей регистрируется и сохраняется, что называется «Accounting», чтобы отслеживать действия пользователей.

TACACS и AAA

Tacacs или Tacacs+ — это протокол AAA, созданный Cisco для использования ее сетевых продуктов.

Tacacs — это первое поколение протокола, а Tacacs+ — это протокол AAA следующего поколения с расширенными функциями.

RADIUS и AAA

Radius — еще один протокол AAA, который предоставляет функции и службы, очень похожие на Tacac.

Radius — это открытый стандарт и широко используемый протокол, который определяется RFC.

LDAP и AAA

LDAP — еще один популярный протокол, обеспечивающий аутентификацию и авторизацию, связанный с AAA.

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

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

LDAP также предоставляет пользователям информацию об авторизации.

Спонсор статьи — https://www.consult-soft.ru/1c-fresh/

Разница между аутентификацией и авторизацией (со сравнительной таблицей)

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

Содержимое: аутентификация против авторизации

1. Таблица сравнения
2. Определение
3. Ключевые отличия
4. Заключение

Таблица сравнения

Определение аутентификации

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

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

Пример:

Например, отправитель A отправляет электронный документ получателю B через Интернет. Как система определяет, что отправитель A отправил сообщение, предназначенное получателю B. Злоумышленник C может перехватить, изменить и воспроизвести документ, чтобы обмануть или украсть информацию. Этот тип атаки называется , фабрикация .

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

Определение полномочий

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

Пример:

Например, пользователь X хочет получить доступ к определенному файлу с сервера. Пользователь отправит запрос на сервер. Сервер проверит личность пользователя. Затем он находит соответствующие привилегии, которые есть у аутентифицированного пользователя, а также определяет, разрешен ли ему / ей доступ к этому конкретному файлу или нет.В следующем случае права доступа могут включать просмотр, изменение или удаление файла, если у пользователя есть полномочия для выполнения следующих операций.

Ключевые различия между аутентификацией и авторизацией

1. Аутентификация используется для проверки личности пользователя, чтобы разрешить доступ к системе. С другой стороны, авторизация определяет, кто и к чему должен иметь доступ.
2. В процессе аутентификации проверяются учетные данные пользователя, тогда как в процессе авторизации проверяется список доступа аутентифицированного пользователя.
3. Первый процесс — это аутентификация, затем происходит авторизация.
4. Возьмем для примера услуги онлайн-банкинга. Когда пользователь хочет получить доступ к услуге, личность пользователя определяется, чтобы гарантировать, что человек является праведным человеком, которым он / она себя называет. После идентификации пользователя аутентификация включает авторизацию, которая определяет, что пользователю разрешено делать. Здесь пользователь авторизуется для доступа к своей учетной записи онлайн после аутентификации.

Заключение

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

.

Разница между аутентификацией и авторизацией по сравнительной таблице

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

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

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

Что такое аутентификация?

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

• Система использует учетные данные объекта, чтобы определить, верна ли предоставленная информация.
• В частных и общедоступных сетях пароли для входа в систему используются системами для аутентификации личности пользователя.
• Существует несколько факторов аутентификации, которые могут быть реализованы для проверки личности перед предоставлением доступа к чему-либо — будь то доступ к файлу, запрос банковских транзакций или предоставление разрешений на использование ресурсов системы / портала.
• В случае аутентификации в целях безопасности необходимо обязательно проверить минимум 2-3 фактора аутентификации, чтобы разрешение было предоставлено любой системе.
• Факторы аутентификации могут варьироваться от однофакторной аутентификации с простым паролем до многофакторной аутентификации.В данном случае расширенные методы аутентификации, требующие двух или более уровней безопасности, относящиеся к независимым скобкам аутентификации, могут использоваться для предоставления пользователю доступа к различным системам.

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

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

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

• Авторизация определяет возможность пользователя получить доступ к системе и до какой степени. Пользователь может получить доступ к проверке и аутентификации почтовой системы, ресурсам заказа.
• Авторизация проверяет права пользователя на доступ к таким ресурсам, как информация, базы данных, файлы и т. Д.
• Любая попытка получить доступ к данной системе может быть аутентифицирована путем ввода действительных учетных данных; однако эти учетные данные принимаются только после успешной авторизации.Если попытка подтверждена, но не авторизована, данная система не предоставит доступ пользователю.

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

Основное различие между авторизацией и аутентификацией

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

Заключение

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

.

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

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

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

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

Вот краткий обзор различий между аутентификацией и авторизацией:

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

.

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

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

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

Аутентификация ASP.Net

Схема проверки подлинности ASP.NET, которая используется для идентификации пользователей, просматривающих ASP.NET-приложение. Приложение ASP.net имеет два отдельных уровня проверки подлинности, поскольку все запросы, поступающие через IIS, обрабатываются ASP.NET. После схем проверки подлинности IIS ASP.NET реализует дополнительные схемы проверки подлинности. Их:

1. Аутентификация Windows
2. Аутентификация с помощью форм
3. Аутентификация паспорта

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

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

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

Если вам нужна аутентификация «Нет», используйте следующую конфигурацию Web.config:

Авторизация

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

Авторизация Asp.Net

ASP.NET допускает два способа авторизации доступа к определенным ресурсам: авторизация URL и авторизация файла.

URL авторизации

URL-авторизация сопоставляет пользователей и роли с URL-адресами в ASP.NET-приложений

Авторизация файла

Авторизация файла проверяет ACL (список управления доступом) файла обработчика .aspx или .asmx, чтобы определить, должен ли пользователь иметь доступ к файлу.

Как осуществить авторизацию?

В следующем примере показан пример реализации логики авторизации в файле web.config.

.