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

Добавление Scaffold Identity

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

• Правой кнопкой мыши щелкнуть на название проекта (в нашем случае BSAdminPanel).
• В контекстном меню выбрать Добавить->Создать шаблонный элемент.
• В диалоговом окне, слева, выбрать Удостоверение
• В диалоге Добавить Удостоверение отмечаем два файла для переопределения: Account\Login и Account\Register
• Класс контекста данных выбрать который уже есть в приложении
• Выбор страницы макета оставьте нетронутым. Макет сформируется автоматически.

После cформирования всей структуры папок в приложении два файла _LoginPartial.cshtml. Структура формируется на новый файл, который находится в папке «/Pages/Shared/_LoginPartial.cshtml», его оставляем. А в папке «/Areas/Identity/Pages/Shared/_LoginPartial.cshtml» можно удалить. Структура строится по типу шаблона для Razor Pages.

Способ 1: Настройки учетной записи

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

Шаг 1: Восстановление аккаунта

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

Подробнее: Как восстановить аккаунт Google

Шаг 2: Подключение приложения

1. Откройте страницу с настройками учетной записи по нижепредставленной ссылке и переключитесь на вкладку «Безопасность». Здесь необходимо найти пункт «Двухэтапная аутентификация». Перейти к настройкам аккаунта

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

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

Чтобы добавить новое устройство, пролистайте окно еще ниже и в отмеченном нами разделе нажмите «Создать».

Укажите разновидность телефона, который хотите использовать для подтверждения, и нажмите «Далее».

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

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

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

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

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

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

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

Требования нормативных документов к механизму идентификации и аутентификации

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

Прежде всего, обратимся к формализованным требованиям в
области защиты информации, попробуем в них найти ответ на вопрос, какими же
функциями должен быть наделен механизм идентификации и аутентификации?
Формализованные требования к механизму идентификации и аутентификации
пользователей задаются действующим сегодня нормативным документом
«Гостехкомиссия России. Руководящий документ. Средства вычислительной
техники. Защита от несанкционированного доступа к информации. Показатели
защищенности от НСД к информации».

Для СЗИ от НСД, используемых для защиты конфиденциальной
информации (5 класс СВТ) требования к механизму идентификации и аутентификации
состоят в следующем:

●     Комплекс
средств защиты информации (КСЗ) должен требовать от пользователей
идентифицировать себя при запросах на доступ.

●     КСЗ
должен подвергать проверке подлинность идентификации — осуществлять
аутентификацию.

●     КСЗ
должен располагать необходимыми данными для идентификации и аутентификации.

●     КСЗ
должен препятствовать доступу к защищаемым ресурсам неидентифицированных
пользователей и пользователей, подлинность идентификации которых при
аутентификации не подтвердилась.

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

Заметим, что в требованиях к СВТ 4-го класса защищенности
вообще задачи идентификации и аутентификации пользователя при входе в систему и
при запросе на доступ разделены на две самостоятельные задачи, кроме того,
здесь появляется некое понятие «субъект» в общем виде.

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

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

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

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

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

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

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

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

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

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

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

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

Как происходит аутентификация

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

• Клиент подключается к беспроводной сети;
• Если она защищена, то запросит ввести пароль, клиент вводит его;
• Роутер начинает считывать данные по защитным алгоритмам;
• Если расшифрованные данные оказались верные, тогда допускает клиента к сети, если нет – запрещает.

Аутентификацию можно отключить, если сделать сеть открытой (незащищенной). В такую сеть можно зайти лишь одним нажатием кнопки «Подключить», никаких данных она не потребует. Такое подходит для кафе и общественных заведений, но дома обязательно следует использовать шифрование, причем современные и надежные способы аутентификации wi-fi.

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

Предположим, что есть определенная система или база данных, где содержится ряд из параметров (идентификаторов), например:

• ID пользователя;
• ФИО (фамилия, имя и отчество);
• номер телефона;
• IMEI-устройства;
• адрес электронной почты;
• логин (никнейм);
• реквизиты банковской карты;
• номер автомобиля;
• серийный номер (штрих-код);
• трек-номер;
• смарт-карта;
• адрес веб-сайта;
• и т. д.

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

Для большего понимания давайте рассмотрим на примере простой ситуации. Вы находитесь дома, занимаетесь своими делами: смотрите фильмы для взрослых, делаете физические упражнения или читаете статью про кибербезопасность на моём сайте. В один момент Вы слышите звонок в дверь, прекращаете заниматься своей деятельностью и направляетесь открывать. Подойдя к двери смотрите в глазок, но никого не видите, спрашиваете: «Кто там?» и слышите в ответ: «Это я, ИМЯ человека!». Имя человека по ту стороны двери, в данной ситуации, является идентификатором. Правильный или неправильный ответ на вопрос — процесс идентификации.

Рассмотрим на примере другой ситуации. Вы совершаете звонок в банк с целью получить какую-либо информацию по Вашей банковской карте. Сотрудник, отвечающий на Ваш звонок, прежде чем предоставить информацию, обязан Вас идентифицировать. Помимо номера телефона, он может запросить у Вас другой идентификатор, например, номер банковской карты или ФИО. Ваш ответ, в данном случае — идентификация.

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

После идентификации производится аутентификация:

Чтобы определить чью-то подлинность, можно воспользоваться тремя факторами:

1. Пароль – то, что мы знаем (слово, PIN-код, код для замка, графический ключ)
2. Устройство – то, что мы имеем (пластиковая карта, ключ от замка, USB-ключ)
3. Биометрика – то, что является частью нас (отпечаток пальца, портрет, сетчатка глаза)

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

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

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

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

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

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

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

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

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

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

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

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

Пример:

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

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

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

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

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

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

Идентификация, аутентификация и авторизация: серьезные определения

Итак, что же значат термины «идентификация», «аутентификация» и «авторизация» — и чем соответствующие процессы отличаются друг от друга? Для начала проконсультируемся с «Википедией»:

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

Интеграция личности в Интернете.

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

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

Для того, чтобы разрешить эту идентификацию пользователи должны связать свою учетную запись пользователя Windows ID онлайн. Включение в Windows протокола Public Key Cryptography Based User-to-User (PKU2U) разрешает проходить идентификацию при помощи свидетельств.

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

TACACS+

Данный протокол разработан компанией Cisco и является развитием прошлых версий TACACS и XTACACS. Несмотря на схожесть названий, TACACS+ был сильно видоизменен и не имеет обратной совместимости с TACACS, который сейчас практически нигде не применяется. Основная сфера использования TACACS+ – это администрирование сетевых устройств, однако он может применяться для некоторых типов AAA при доступе в сеть. TACACS + использует Transmission Control Protocol (TCP) порт 49, а не UDP, так как он обладает большей надежностью и позволяет заранее получать информацию о потенциальных ошибках благодаря пакету TCP-RST. ТСP более медленный протокол, но обладает дополнительными преимуществами: возможность разделения аутентификации, авторизации и учета в качестве отдельных и независимых функций, множественная авторизация после одной аутентификации, шифрование всего содержимого пакета.

Для наглядности объединим основные характеристики в таблицу:

	RADIUS	TACACS+
Используемые протоколы и порты	UDP: 1812 & 1813 или UDP: 1645 & 1646	TCP: 49
Сервисы	Объединяет аутентификацию и авторизацию	Разные процессы для аутентификации, авторизации и учета
Шифрование	Шифруется только пароль	Шифруется все тело пакета
Поддерживаемые типы    аутентификации	Clear text (ASCII, PAP), CHAP	Clear text (ASCII, PAP),                    CHAP, ARAP
Возможность перенаправления запроса	Есть	Нет
Основное назначение	Доступ к сети	Администрирование устройств

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

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

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

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

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

Меры организационной идентификации

Из метааналитического обзора Рикетты (2005) мы можем сделать вывод, что мера OI Маэла и Эшворта (1992) более узкая и более отличная от аффективной организационной приверженности, в то время как анкета OI больше перекликается с аффективной организационной приверженностью. Кроме того, показатель OI Маэла и Эшворта (1992) может быть более полезным, чем шкала OIQ или шкала эмоциональной приверженности при изучении или прогнозировании поведения сотрудников, выполняющих дополнительные роли, и вовлеченности в работу. Тем не менее, анкета OI является лучшим индикатором намерений сотрудников покинуть организацию, чем шкала эмоциональной приверженности или показатель OI Маэла и Эшворта.

Эдвардс и Печчеи (2007) разработали показатель OI, который включает три отдельных, но тесно связанных фактора OI. Эти три фактора включают: а) категоризацию себя как члена организации, б) интеграцию целей и ценностей организации, а также в) развитие эмоциональной привязанности, принадлежности и членства в организации. Соответственно, эти три фактора включают в себя основные компоненты определений OI на протяжении всего исследования OI. Поскольку каждый фактор измерялся двумя отдельными пунктами, Эдвардс и Печчеи смогли провести подтверждающий факторный анализ для своей трехфакторной модели, соответствующей двум независимым выборкам.

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

Сравнение

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

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

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

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

Рекомендации по аутентификации на основе токенов

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

Правильный веб-токен. Хотя существует целый ряд веб-токенов, ни один из них не может обеспечить ту же надежность, которую предоставляет веб-токен JSON (JWT). JWT считается открытым стандартом (RFC 7519) для передачи конфиденциальной информации между несколькими сторонами. Обмен информацией осуществляется цифровой подписью с использованием алгоритма или сопряжения открытого и закрытого ключей для обеспечения оптимальной безопасности.
Приватность.
Использование HTTPS-соединений. HTTPS-соединения были построены с использованием протоколов безопасности, включающих шифрование и сертификаты безопасности, предназначенные для защиты конфиденциальных данных

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

Запрос авторизации

Приложение отправляет запрос авторизации на сервер Модульбанка. Запрос авторизации отправляется из браузера клиента.

Параметры запроса:

Параметры	Тип	Описание
clientId	string	Идентификатор приложения. Для получения идентификатора для приложения напишите нам на api@modulbank.ru
state	string	параметр будет добавлен к redirectUri c тем же значением
redirectUri	string	URI, на который сервер OAuth передает результат авторизации. Значение этого параметра при посимвольном сравнении должно быть идентично значению redirect_uri, указанному при регистрации приложения. При сравнении не учитываются индивидуальные параметры приложения, которые могут быть добавлены в конец строки URI.
scope	string	Список запрашиваемых прав. Разделитель элементов списка — пробел. Элементы списка чувствительны к регистру.

По запросу авторизации пользователь перенаправляется на страницы OAuth авторизации Модульбанка. Пользователь вводит свой логин и пароль, просматривает список запрашиваемых прав, подтверждает либо отклоняет запрос авторизации приложения. Результат авторизации возвращается как HTTP 302 Redirect. Приложение должно обработать ответ HTTP Redirect. Можно получить только одну авторизацию для одного пользователя. Повторная авторизация (с тем же значением параметра clientId) аннулирует выданные ранее разрешения. Параметры перенаправления с результатом авторизации:

Параметры	Тип	Описание
code	string	Временный токен (authorization code), подлежащий обмену на постоянный токен авторизации. Присутствует если пользователь подтвердил авторизацию приложения
error	string	Код ошибки. Присутствует в случае ошибки или отказа в авторизации пользователем
description	string	Дополнительное текстовое пояснение ошибки
state	string	Транслируется из метода выше, если был передан

Возможные ошибки:

Значение поля error	Описание
invalid_request	В запросе отсутствуют обязательные параметры, либо параметры имеют некорректные или недопустимые значения.
invalid_scope	Параметр scope отсутствует, либо имеет некорректное значение или имеет логические противоречия.
unauthorized_client	Неверное значение параметра client_id, либо приложение заблокировано
access_denied	Пользователь отклонил запрос авторизации приложения.

Пример ответа при успешной авторизации:

Ответ при отказе в авторизации:

Какие операции не требуют идентификации

Некоторые операции, признанные малоопасными в законе № 115-ФЗ, допускается проводить без процедуры идентификации. Это:

• Денежные переводы без открытия счета на суммы в пределах 15 000 руб. (или в эквиваленте не более чем 15 000 руб.). Перечень исключений — товаров и услуг, на операции с которыми не распространяется освобождение от идентификации устанавливается Правительством РФ.
• Покупка физлицом валюты на сумму (эквивалент) не более 40 000 руб.
• Покупка физлицом изделий из драгметаллов и драгкамней в розницу на сумму (эквивалент) не более 40 000 руб. То же самое, но с применением физлицом электронных средств расчетов — на сумму (эквивалент) до 100 000 руб.

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

Подобный подход связан с тем, что большинство отзывов банковских лицензий происходят именно на основании инкриминирования банкам нарушений закона № 115-ФЗ. Это вынуждает банки перестраховываться.

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

Сначала давайте прочитаем определение:

Идентификация выполняется при попытке войти в какую-либо систему (например, в операционную систему или в сервис электронной почты).

Сложно? Давайте перейдём к примерам, заодно разберемся, что такое идентификатор.

Пример идентификатора в социальной сети ВКонтакте

Когда нам звонят с неизвестного номера, что мы делаем? Правильно, спрашиваем “Кто это”, т.е. узнаём имя. Имя в данном случае и есть идентификатор, а ответ вашего собеседника — это будет идентификация.

Идентификатором может быть:

• номер телефона
• номер паспорта
• e-mail
• номер страницы в социальной сети и т.д.

Подробнее об идентификаторах и ID рекомендую прочитать здесь.

Смарт-карты.

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

• Смарт-карты Plug and Play
• Личные удостоверения проверки (PIV), стандарт национального института стандартов и технологий США (NIST)
• Поддержка для входа смарт-карты Kerberos.
• Шифрование дисков  BitLocker
• Документы и электронная почта
• Использование с бизнес-приложениями.

Почему двухфакторная аутентификация в домене по токену с PIN-кодом безопаснее обычной парольной схемы?

PIN-код привязан к определенному устройству, в нашем случае к токену. Знание PIN-кода само по себе ничего не дает.

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

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

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