Что такое авторизация программы

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

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

Проверка подлинности — это процесс, подтверждающий, что вы являетесь тем, за кого себя выдаете. Это достигается путем проверки удостоверения пользователя или устройства. Иногда для этого термина используется сокращение AuthN (Authentication). Для обработки операций проверки подлинности в платформе удостоверений Майкрософт применяется протокол OpenID Connect.

Авторизация

Авторизация — это акт предоставления разрешения на выполнение какого-либо действия стороне, прошедшей проверку подлинности. Она указывает, к каким данным разрешено получить доступ и что с ними можно делать. Авторизация иногда сокращенно обозначается AuthZ (Authorization). Для обработки операций авторизации в платформе удостоверений Майкрософт применяется протокол OAuth 2.0.

Значение слова авторизация. Что такое авторизация.

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

Многофакторная проверка подлинности — это предоставление дополнительного фактора проверки подлинности для учетной записи. Она часто используется для защиты от атак методом подбора. Иногда для этого термина используется сокращение MFA или 2FA. Microsoft Authenticator можно использовать в качестве приложения для обработки двухфакторной проверки подлинности. Дополнительные сведения см. в статье Многофакторная проверка подлинности.

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

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

Azure Active Directory (Azure AD) — это централизованный поставщик удостоверений в облаке. Делегирование ему проверки подлинности и авторизации позволяет использовать такие сценарии:

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

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

В этом видео рассматриваются платформа удостоверений Майкрософт и основы современных технологий проверки подлинности:

Вот сравнение протоколов, которые использует платформа удостоверений Майкрософт:

• OAuth и OpenID Connect: платформа использует OAuth для авторизации и OpenID Connect (OIDC) для проверки подлинности. В основе OpenID Connect лежит OAuth 2.0, поэтому терминология и последовательность операций в них аналогичные. В одном запросе можно даже проверить подлинность пользователя (с помощью OpenID Connect) и получить авторизацию для доступа к защищенному ресурсу, которым владеет пользователь (с помощью OAuth 2.0). Дополнительные сведения см. в статьях Протоколы OAuth 2.0 и OpenID Connect и Протокол OpenID Connect.
• OAuth и SAML: платформа использует протокол OAuth 2.0 для авторизации и SAML для проверки подлинности. Дополнительные сведения о том, как использовать эти протоколы для проверки подлинности пользователя и авторизации доступа к защищенному ресурсу см. в статье Платформа удостоверений Майкрософт и поток утверждения носителя OAuth 2.0 SAML.
• OpenID Connect и SAML: платформа использует для проверки подлинности пользователя и включения единого входа как OpenID Connect, так и SAML. Проверка подлинности SAML обычно используется с поставщиками удостоверений, такими как службы федерации Active Directory (ADFS) с федерацией в Azure AD, и поэтому часто применяется в корпоративных приложениях. OpenID Connect обычно используется для приложений, которые полностью находятся в облаке (например, для мобильных приложений, веб-сайтов и веб-API).

Дальнейшие действия

Другие статьи по основам проверки подлинности и авторизации:

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

Источник: learn.microsoft.com

Что такое авторизация простыми словами

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

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

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

Как обычно, начну рассказ с определения термина. Он пришел к нам из английского языка и образован от слова authorization, что переводится на русский как «разрешение» или «уполномочивание».

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

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

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

Где вас могут попросить авторизоваться

Пользователи сталкиваются с необходимостью авторизоваться в интернете где бы то ни было:

1. электронная почта;
2. системы банковских платежей;
3. электронные кошельки;
4. форумы;
5. контентные сайты;
6. интернет-магазины;
7. сайты по поиску работы;
8. фриланс-биржи;
9. развлекательные порталы;
10. личные кабинеты в коммунальных службах;
11. и так далее.

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

Этапы авторизации

Обычно процесс состоит из двух этапов:

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

Основные преимущества

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

Преимущества для пользователей

1. возможность использовать интернет-ресурсом под своим именем;
2. возможность выполнения действий, недоступных неавторизованным пользователям: оставление комментариев, заказ товаров в интернет-магазинах, отправка писем с почты и так далее;
3. возможность встретить знакомого собеседника и пообщаться с ним;
4. уменьшение риска спама;
5. возможность заполнения профиля, загрузки медиафайлов и так далее.

Преимущества для владельцев сайтов

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

Что такое ошибка авторизации и что с этим делать

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

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

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

А я буду с вами прощаться до следующего раза. Напоследок предлагаю посмотреть прикрепленное

Источник: ktonanovenkogo.ru

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

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

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

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

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

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

Вступление

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

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

Цифровая идентичность

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

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

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

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

Авторизация

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

Стандарты

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

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

Инженерный совет Интернета

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

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

OpenID Foundation (OIDF)

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. В результате вы вводите свой логин и пароль для MyCalApp на сайте HireMe123.

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

Но разглашать логин и пароль это плохо!

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

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

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

И тут появляется Oauth

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

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

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

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

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

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

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

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

После этого сервер авторизации MyCalApp запрашивает у вас согласие на то, что HireMe123 получит доступ к API MyCalApp от вашего имени. Происходит это следующим образом:

1. В браузере откроется приглашение.
2. В нем у вас запросят согласие на то, чтобы приложение HireMe123 получило возможность добавлять события в календарь (и только это, ничего кроме этого!).
3. Если вы скажете «да» и зафиксируете свое согласие, сервер авторизации MyCalApp пошлет HireMe123 код авторизации. Таким образом HireMe123 узнает, что пользователь MyCalApp (т. е., вы) точно согласился разрешить HireMe123 добавлять события, используя пользовательский (ваш) MyCalApp.

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

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

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

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

Так почему же аутентификацию частенько связывают с OAuth?

Это мы рассмотрим в следующей части статьи.

Источник: techrocks.ru