Что будет с аутентификацией и паролями? перевод отчета javelin «состояние строгой аутентификации» с комментариями

Подробный обзор

Введение

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

Разбираемся детально ху из ху

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

OpenID 1.0OpenID 2.0

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

OpenID Attribute Exchange 1.0

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

OAuth 1.0

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

OAuth 2.0OpenID Connect

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

Взгляд сверху

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

Терминология OAuth2 & OpenID Connect

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

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

Двухфакторная аутентификация (2FA) улучшает безопасность доступа за счёт использования двух методов (также называемых факторами) проверки личности пользователя. Это разновидность многофакторной аутентификации. Наверное, вам не приходило в голову, но в банкоматах вы проходите двухфакторную аутентификацию: на вашей банковской карте должна быть записана правильная информация, и в дополнение к этому вы вводите PIN. Если кто-то украдёт вашу карту, то без кода он не сможет ею воспользоваться. (Не факт! — Примеч. пер.) То есть в системе двухфакторной аутентификации пользователь получает доступ только после того, как предоставит несколько отдельных частей информации.

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

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

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

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

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

То есть это универсальное решение? Возможно, нет.

И всё же двухфакторка поможет усилить безопасность аутентификации в вашем приложении. Как реализовать? Возможно, стоит не велосипедить, а воспользоваться существующими решениями вроде Auth0 или Duo.

Особенности работы протокола HTTP¶

Как вы узнали из прошлой главы, работа с веб-сайтами в интернете происходит по протоколу HTTP.
Это замечательный и простой протокол, который действует по схеме «запрос-ответ». То есть клиент (браузер) пользователя посылает на сервер запрос, состоящий, как правило, только из заголовков, а затем получает ответ в виде заголовков ответа и тела самого документа.

В отличие от многих других протоколов, HTTP не сохраняет своего состояния. Это означает отсутствие сохранения промежуточного состояния между парами «запрос-ответ».

Иными словами, сервер не «запоминает» клиентов; каждый запрос он обрабатывает с «чистого листа».

Для сервера нет никакой разницы: запросил один пользователь страницу десять раз или десять разных пользователей по разу. Для него все запросы одинаковые.

Чем это неудобно для нас?

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

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

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

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

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

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

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

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

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

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

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

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

Что будет с аутентификацией и паролями? перевод отчета javelin «состояние строгой аутентификации» с комментариями

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

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

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

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

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

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

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

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

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

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

Что будет с аутентификацией и паролями? перевод отчета javelin «состояние строгой аутентификации» с комментариями

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

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

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

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

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

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

https://youtube.com/watch?v=44TCi7O_oPk

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

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

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

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

Ошибка третья: токены API

JSON Web TokensзаявитруководствоСони Панди

  1. Ключи JWT в GitHub-репозитории.
  2. Для хранения паролей используется . Это означает, некто может завладеть ключом шифрования и расшифровать все пароли. К тому же, тут наблюдаются неправильные взаимоотношения между ключом шифрования и секретным ключом JWT.
  3. Здесь, для шифрования данных в хранилище паролей, используется алгоритм AES-256-CTR. AES вообще не стоит использовать, и данный его вариант ничего не меняет. Я не знаю, почему был выбран именно этот алгоритм, но только одно это делает зашифрованные данные уязвимыми.

JWT-токен, полученный из программы, описанной в руководстве scotch.ioЧто может быть лучше пароля в виде обычного текстаОноСледующее руководство

Образцы разделов авторизации

Ниже приведены несколько примеров разделов авторизации в документации API.

SendGrid

Что будет с аутентификацией и паролями? перевод отчета javelin «состояние строгой аутентификации» с комментариямиAPI ключ SendGrid

SendGrid предлагает подробное объяснение ключей API, начиная с основ, поясняя: «Что такое ключи API?». Контекстно раздел ключей API появляется вместе с другими разделами по управлению учетными записями.

Что будет с аутентификацией и паролями? перевод отчета javelin «состояние строгой аутентификации» с комментариямиавторизация Twitter

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

Amazon Web Services

Что будет с аутентификацией и паролями? перевод отчета javelin «состояние строгой аутентификации» с комментариямиавторизация Amazon

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

Dropbox

Что будет с аутентификацией и паролями? перевод отчета javelin «состояние строгой аутентификации» с комментариямиАвторизация в Dropbox

Как и Twitter, Dropbox также использует OAuth 2.0. Их документация включает в себя не одну, а две диаграммы и подробное объяснение процесса.

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

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

Тем не менее нужно объяснить необходимую информацию:

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

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

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

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

Аутентификация на основе токенов в последние годы стала очень популярна из-за распространения одностраничных приложений, веб-API и интернета вещей. Чаще всего в качестве токенов используются Json Web Tokens (JWT). Хотя реализации бывают разные, но токены JWT превратились в стандарт де-факто.

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

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

  1. Пользователь вводит имя и пароль.
  2. Сервер проверяет их и возвращает токен (JWT), который может содержать метаданные вроде user_id, разрешений и т. д.
  3. Токен хранится на клиентской стороне, чаще всего в локальном хранилище, но может лежать и в хранилище сессий или кук.
  4. Последующие запросы к серверу обычно содержат этот токен в качестве дополнительного заголовка авторизации в виде Bearer {JWT}. Ещё токен может пересылаться в теле POST-запроса и даже как параметр запроса.
  5. Сервер расшифровывает JWT, если токен верный, сервер обрабатывает запрос.
  6. Когда пользователь выходит из системы, токен на клиентской стороне уничтожается, с сервером взаимодействовать не нужно.

У метода есть ряд преимуществ:

  • Главное преимущество: поскольку метод никак не оперирует состояниями, серверу не нужно хранить записи с пользовательскими токенами или сессиями. Каждый токен самодостаточен, содержит все необходимые для проверки данные, а также передаёт затребованную пользовательскую информацию. Поэтому токены не усложняют масштабирование.
  • В куках вы просто храните ID пользовательских сессий, а JWT позволяет хранить метаданные любого типа, если это корректный JSON.
  • При использовании кук бэкенд должен выполнять поиск по традиционной SQL-базе или NoSQL-альтернативе, и обмен данными наверняка длится дольше, чем расшифровка токена. Кроме того, раз вы можете хранить внутри JWT дополнительные данные вроде пользовательских разрешений, то можете сэкономить и дополнительные обращения поисковые запросы на получение и обработку данных.
    Допустим, у вас есть API-ресурс /api/orders, который возвращает последние созданные приложением заказы, но просматривать их могут только пользователи категории админов. Если вы используете куки, то, сделав запрос, вы генерируете одно обращение к базе данных для проверки сессии, ещё одно обращение — для получения пользовательских данных и проверки, относится ли пользователь к админам, и третье обращение — для получения данных.
    А если вы применяете JWT, то можете хранить пользовательскую категорию уже в токене. Когда сервер запросит его и расшифрует, вы можете сделать одно обращение к базе данных, чтобы получить нужные заказы.
  • У использования кук на мобильных платформах есть много ограничений и особенностей. А токены сильно проще реализовать на iOS и Android. К тому же токены проще реализовать для приложений и сервисов интернета вещей, в которых не предусмотрено хранение кук.

Благодаря всему этому аутентификация на основе токенов сегодня набирает популярность.

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

Серия видеороликов 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 — это отладчик, который позволяет разработчикам шаг за шагом исследовать и тестировать вызовы и ответы .

Элементы аутентификации

  1. Субъект — пользователь
  2. Характеристика субъекта — информация, предоставляемая пользователем для проверки подлинности.
  3. Владелец системы аутентификации — владелец ресурса.
  4. Механизм аутентификации — принцип проверки
  5. Механизм авторизации — управление доступом

Методы аутентификации

  1. Парольные
  2. Комбинированные
  3. Биометрические
  4. Информация о пользователе
  5. Пользовательские данные

Парольные

Самый распространенный метод. Аутентификация может проходить по одноразовым и многоразовым паролям. Многоразовый пароль задает пользователь, а система хранит его в базе данных. Он является одинаковым для каждой сессии. К ним относятся PIN-коды, слова, цифры, графические ключи. Одноразовые пароли — разные для каждой сессии. Это может быть SMS с кодом. 

Комбинированные

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

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

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

Информация о пользователе

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

Пользовательские данные

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

Классификация видов аутентификации

В зависимости от политики безопасности систем и уровня доверия

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

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

Типы протоколов обусловлены тем, где происходит аутентификация — на PC или в сети.

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

  • Login
  • PAP (Password Authentication Protocol) — логин и пароль
  • Карта доступа — USB и сертификаты
  • Биометрические данные

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

  • Cookies. Используются для отслеживания сеанса, сохранения предпочтений и сбора статистики. Степень защиты невысокая, однако привязка к IP-адресу решает эту проблему.
  • Kerberos. Протокол взаимной аутентификации с помощью криптографического ключа.
  • SAML (Security Assertion Markup Language) Язык разметки, который позволяет сторонам обмениваться данными аутентификации.
  • SNMP (Simple Network Management Protocol) Протокол, который контролирует подключенные к сети устройства.
  • Сертификаты X.509 Сертификаты с открытым ключом.
  • OpenID Connect. Используется для создания единой учетной записи для аутентификации на разных ресурсах.

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

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

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

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

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

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

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

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

Единая точка входа (Single Sign On, SSO)

Обращали внимание, что, когда логинишься в браузере в каком-нибудь Google-сервисе, например Gmail, а потом идёшь на Youtube или иной Google-сервис, там не приходится логиниться? Ты автомагически получаешь доступ ко всем сервисам компании. Впечатляет, верно? Ведь хотя Gmail и Youtube — это сервисы Google, но всё же раздельные продукты

Как они аутентифицируют пользователя во всех продуктах после единственного входа?

Этот метод называется единой точкой входа (Single Sign On, SSO).

Реализовать его можно по-разному. Например, использовать центральный сервис для оркестрации единого входа между несколькими клиентами. В случае с Google этот сервис называется Google Accounts. Когда пользователь логинится, Google Accounts создаёт куку, которая сохраняется за пользователем, когда тот ходит по принадлежащим компании сервисам. Как это работает:

  1. Пользователь входит в один из сервисов Google.
  2. Пользователь получает сгенерированную в Google Accounts куку.
  3. Пользователь идёт в другой продукт Google.
  4. Пользователь снова перенаправляется в Google Accounts.
  5. Google Accounts видит, что пользователю уже присвоена кука, и перенаправляет пользователя в запрошенный продукт.

Очень простое описание единой точки входа: пользователь входит один раз и получает доступ ко всем системам без необходимости входить в каждую из них. В этой процедуре используется три сущности, доверяющие другу прямо и косвенно. Пользователь вводит пароль (или аутентифицируется иначе) у поставщика идентификационной информации (identity provider, IDP), чтобы получить доступ к поставщику услуги (service provider (SP). Пользователь доверяет IDP, и SP доверяет IDP, так что SP может доверять пользователю.

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

Литература

  • Ричард Э. Смит. Аутентификация: от паролей до открытых ключей = Authentication: From Passwords to Public Keys First Edition. — М.: Вильямс, 2002. — С. 432. — ISBN 0-201-61599-1.
  • под. редакцией А.А. Шелупанова, С.Л. Груздева, Ю.С. Нахаева. Аутентификация. Теория и практика обеспечения доступа к информационным ресурсам. = Authentication. Theory and practice of ensuring access to information resources.. — М.: Горячая линия – Телеком, 2009. — С. 552. — ISBN 978-5-9912-0110-0.
  • Шнайер Б. Прикладная криптография. Протоколы, алгоритмы, исходные тексты на языке Си = Applied Cryptography. Protocols, Algorithms and Source Code in C. — М.: Триумф, 2002. — 816 с. — 3000 экз. — ISBN 5-89392-055-4.
  • Linn J. Common Authentication Technology Overview,.
  • Bellovin S. and M. Merritt. Limitations of the Kerberos Authentication System.
  • Kaufman, C. Distributed Authentication Security Service (DASS).
  • Anderson, B.,. TACACS User Identification Telnet Option. — December 1984.
  • Tardo J. and K. Alagappan. SPX: Global Authentication Using Public Key Certificates. — М.California, 1991. — С. pp.232-244.
  • А.А. Гладких, В.Е. Дементьев. Базовые принципы информационной безопасности вычислительных сетей.. — Ульяновск: УлГТУ, 2009. — С. 156.
admin
Оцените автора
( Пока оценок нет )
Добавить комментарий