Привет! Я Диана. Сейчас я работаю системным аналитиком, а раньше была биологом и преподавателем. Биологические системы гораздо сложнее тех, что придумывают люди, поэтому, если человек разобрался с митохондриями и клеточным дыханием, то межсистемной аутентификацией его не испугаешь. Я написала статью для начинающих аналитиков с базовыми знаниями, чтобы объяснить основные принципы межсистемной аутентификации. Осторожно, ниже много мемов с котами 😂
Сейчас расскажу:
Как в общих чертах выглядит взаимодействие систем;
Разберем, что такое аутентификация и какая она бывает;
Подробнее познакомимся с аутентификацией по токенам и как в целом выглядит этот процесс;
В конце список источников [сохраняй, если полезно].
1. Сравним схему модулей с живой клеткой 😮
Когда начинаете работать с новой системой, то обычно узнаете, что она состоит из нескольких подсистем или модулей, которые в свою очередь тоже имеют сложную структуру. Могут включать набор микросервисов, собственные базы данных и выполняют разные функции. Иногда это выглядит запутанно.
Количество систем может быть действительно большим, а взаимодействия между ними выглядят сложными. Но поверьте, бывает и хуже. Например, когда речь идет о строении животной клетки.
Если рассмотрим взаимодействие систем на более низком уровне, то скорее всего, будет не так страшно: вот на следующем рисунке уже более-менее понятно, что в модуле есть несколько фронтовых и мидловых микросервисов, а свои базы данных представлены в Redis и Mongo.
Внутри модуля обращение происходит, как правило, напрямую, а с другими системами интеграция может осуществляться через посредника — шины, брокеры сообщений, балансировщики или другим способом. На самом деле, если нужно разобраться с видами интеграции, то это может стать темой для отдельной статьи [проявите активность, если интересно 😉].
Но как обеспечить безопасное взаимодействие модулей/систем? Потому что именно из-за соображений безопасности и возникает потребность в идентификации, аутентификации и авторизации.
2. Классификация аутентификации
Плавно переходим к понятию аутентификации. Если вы, как и я любите этимологию, то сразу догадались, что слово перед нами греческоеαὐθεντικός [authentikos] «реальный, подлинный», которое имеет в своем составе еще одно греческое словоαὐτός [autos] «сам; он самый». И теперь понятно, аутентификация — процесс проверки этой самой подлинности.
Как же проверяется подлинность? Тут могут быть самые разные подходы и способы, поэтому давайте их классифицируем:
- по факторам аутентификации;
- по количеству факторов, используемых в процессе.
И рассмотрим, что такое фактор аутентификации и какой он бывает.
Фактор аутентификации (или credentials) — блок данных для аутентификации субъекта или объекта доступа. То есть, это какие-то категории свойств пользователя или системы, которые являются уникальными и позволяют однозначно определить пользователя или систему, обеспечивают ли они доступ к другой системе.
Обычно выделяют три типа факторов аутентификации, но можно встретить дополнительные – четвертый, а иногда и пятый тип:
Фактор знания Knowledge factors — то, что знает система или объект и предъявляет в качестве доказательства, что это она и есть. Довольно старый способ, который используется людьми давно, и его придумали задолго до первых компьютеров.
Секретный вопрос и ответ на него, могут стать пропуском в крепость или на секретную вечеринку. Да и сейчас пара логин/пароль используется практически повсеместно, по крайней мере как один из факторов аутентификации. Помимо пароля может использоваться так-же PIN-code, что не меняет принцип: чтобы получить доступ к системе, объект или другая система должны это знать.
Фактор обладания Possession factors — то, чем субъект должен обладать, чтобы получить доступ к системе. Идея запирать что-то ценное на замок, который открывается специальным ключом, пришла в голову человеку примерно 4-5 тысяч лет назад, но до сих пор остается рабочей. В качестве “ключа” может выступать сим-карта, ключ безопасности или токен, но так или иначе, чтобы получить доступ, нужно обладать этим самым фактором.
Фактор неотъемлемости Inherence factor в отличие от предыдущего — неотъемлемая часть субъекта, получающего доступ. Это может быть отпечаток пальца или сетчатки, голос или ДНК. Особенности аутентификации по факторам неотъемлемости в том, что фактор сложнее передать сторонней системе и сложнее подделать, но и проверяющая система должна уметь работать с такими факторами. Как минимум, иметь соответствующие принимающие и распознающие устройства.
В последнее время выделяют еще два дополнительных фактора, которые редко используются сами по себе, но могут выступать в качестве дополнительных.
Фактор нахождения Location factor — информация, которая подтверждает ваше местонахождение в определенной локации или сети. Доступ может определяться по гео-локации, IP-адресу, MAC-адресу.
Поведенческий фактор Behavioral factor основан на том, что делает пользователь. Предварительно задается определенная последовательность действий, которая и будет служить фактором аутентификации. Если вы когда-либо нажимали точки в определенной последовательности, чтобы разблокировать свой телефон или использовали графический пароль для Windows8 — вы как раз использовали этот фактор. В качестве пассивных факторов поведенческой биоидентификации может служить анализ нажатия клавиш, сила давления, распознавание походки, шаблоны скроллинга и даже угол наклона телефона.
Ну и, как говорится, одна голова хорошо, а две — лучше. Давайте рассмотрим виды аутентификации по количеству используемых факторов:
С однофакторной аутентификацией все просто: используется один фактор — если все хорошо, доступ дается, если нет — получите 401.
А вот с многофакторной разобраться немного сложнее. Казалось бы, если вы используете более одного фактора, то у вас уже все хорошо. Но нет, если эти факторы относятся к одному и тому же типу (например, используется пара логин/пароль и PIN-code или отпечаток пальца плюс сетчатка), то хотя факторов технически два, но такая аутентификация все равно не является многофакторной — дополнительный фактор аутентификации обязательно должен относиться к другому типу.
Помимо факторов аутентификации и их количества для того, чтобы действительно разобраться с этим вопросом, нужно еще и понимать механизмы или способы самого процесса аутентификации. Кроме того, следует учитывать, что даже для одного способа могут использоваться различные протоколы. Например, казалось бы, самый простой способ по логину и паролю (однофакторная аутентификация по фактору знания) для web-приложения может осуществляться по типу HTTP или Forms аутентификации, либо вообще каким-то кастомным образом.
Краткий обзор некоторых способов аутентификации
Подробнее разберем аутентификацию при помощи программных токенов.
Уже упомянутый выше способ аутентификации по паролю подразумевает, что система или пользователь предоставляет логин и пароль (фактор аутентификации), а при успешном прохождении предоставляется доступ. Детали могут отличаться в зависимости от используемого протокола: HTTP (например, при basic логин и пароль передается в заголовке Authorization в незашифрованном виде, но использование HTTPS делает такой способ достаточно безопасным); Forms (логин и пароль вводятся через специальную форму и передаются на сервер через HTTP POST, в ответ предоставляется session token); нестандартные протоколы.
Аутентификация по сертификатам использует более сложный механизм. В схему взаимодействия клиента (пользователь или система, которые запрашивают доступ) и сервера (система, к которой запрашивается доступ) добавляется еще одна сущность — certificate authority, который выступает в роли посредника, который гарантирует подлинность сертификатов (фактор аутентификации). Отмечу, что в качестве протокола выступает SSL/TLS, что обеспечивает высокий уровень безопасности.
Аутентификация по одноразовым паролям (OTP — One-Time Password), которые генерируются на основе секретного ключа и времени (если это Time-based OTP) или HMAC (hash-based message authentication code, код проверки подлинности сообщений, использующий односторонние хеш-функции). Секретный ключ хранится одновременно и на клиенте, и на сервере, поэтому сервис может проверить подлинность сгенерированного одноразового пароля, который или имеет ограниченное действие по времени, или генерируется каждый раз при входе в систему. В случае пользователя OTP либо генерируются на устройстве принадлежащем пользователю, либо присылаются каким-либо мессенджером. Обычно OTP отправляются через специальную форму.
По ключам доступа — в качестве секрета применяются ключи доступа access key, API key (сервисы): длинные произвольные строки, которые гораздо сложнее взломать или подобрать, чем классическую пару логин/пароль. Действие ключа можно ограничить по времени и аннулировать в случае его дискредитации. К тому же есть более сложные схемы, где часть ключа является публичной, а часть секретной. Не существует единого протокола, ключи могут передаваться в разных частях HTTP-запроса: URL query, request body или HTTP header.
По токенам — фактором аутентификации является токен. Разберем подробнее.
3. Аутентификация по токенам
Аутентификация по токенам позволяет пользователю или системе один раз аутентифицировать себя и получить токен, который будет обеспечивать доступ к сервису на все время валидности токена.
Казалось бы ничего сложного — разберись, что такое токены, как осуществляется процесс и все будет хорошо. Но на самом деле, для начала нужно познакомиться с еще некоторыми определениями, чтобы в последующем обилие аббревиатур не вводило в заблуждение. Или это только я терпеть не могу аббревиатуры без расшифровки? Они нам понадобятся, не только чтобы понять аутентификацию по токенам, но и в целом как системы “договариваются” о взаимодействии между собой.
Federated identity management (FIM) — соглашение между двумя или более доменами или системами управления идентификацией о доверительном отношении. Самое широкое понятие, которое может включать (а может и нет) остальные.
Single sign-on (SSO) — метод аутентификации, который позволяет пользователям безопасно аутентифицироваться сразу в нескольких приложениях и сайтах, используя один набор учетных данных. Например, через аутентификацию через соцсети.
OAuth 2.0 — стандартный протокол авторизации, который определяет механизм получения доступа одного приложения к другому от имени пользователя. Заметьте, что именно авторизации, то есть получение ролей тоже возможно.
OpenID Connect (OIDC) — уровень аутентификации, наложенный на базу OAuth 2.0, чтобы обеспечить фунциональность SSO (дополнительный токен с данными о пользователе).
Security Access Markup Language (SAML) — открытый стандарт, который также разработан для обеспечения функциональности SSO, описывает способы взаимодействия и протоколы между identity provider и service provider для обмена данными аутентификации и авторизации посредством токенов.
На схеме можно увидеть, как эти понятия соотносятся между собой:
Если внимательно посмотреть на пересечение этих множеств, то становится понятно, что когда кто-то говорит, что используется метод SSO — это не обязательно означает, что и протокол авторизации будет OAuth 2.0, и уровень аутентификации будет именно OpenID Connect. Но если у нас указан именно этот OIDC, то это точно про Single sign-on аутентификацию. Надеюсь, теперь не запутаемся.
Еще один ключевой термин, без которого нам не обойтись — токен. Поскольку данное понятие вы можете встретить и в статьях о криптовалюте, BPMN, лексическом анализе, семиотике и настольных играх, то давайте явно обозначим, что в данном случае под токеном мы имеем в виду фактор аутентификации. Но даже в этом случае можно иметь дело с двумя видами токенов: аппаратный и программный.
Аппаратный токен — устройство, позволяющее идентифицировать его владельца и обеспечивающее безопасный доступ к ресурсам. Как правило, такое устройство либо содержит, либо генерирует уникальный пароль по определенным правилам. Обычно используется, как дополнительный фактор при аутентификации пользователя.
Программный токен представляет собой зашифрованную строку символов, которая позволяет аутентифицировать пользователя или систему, а также определить уровень прав (т.е. авторизировать). Токен может также содержать дополнительную информацию и использоваться многократно, пока не истечет срок его действия.
Как может шифроваться токен
Simple Web Token (SWT) — наиболее простой формат, представляющий собой набор произвольных пар имя/значение в формате кодирования HTML form. Подписывается симметричным ключом.
Security Assertion Markup Language (SAML) — определяет токены (SAML assertions) в XML-формате, включающем информацию об эмитенте, о субъекте, необходимые условия для проверки токена, набор дополнительных утверждений о пользователе. Подписывается ассиметрично.
JSON Web Token (JWT) — содержит заголовок, набор полей (claims) и подпись. Первые два блока представлены в JSON-формате и дополнительно закодированы в формат base64. Может подписываться и симметрично, и ассиметрично.
А теперь разберем подробнее сам механизм аутентификации при помощи программного токена. Но для начала парочка определений (потерпите чуть-чуть, без этого никак), просто чтобы обозначить с какими сущностями нам предстоит иметь дело.
Клиент (client) — приложение или пользователь, которые аутентифицируется.
Сервис (service provider SP) — приложение, доступ к которому хочет получить клиент и которое делегирует аутентификацию третьей сущности.
Провайдер идентификации (identity provider IP) — приложение, обеспечивающее идентификацию, аутентификацию, а зачастую и авторизацию client.
Если клиент напрямую попробует обратиться к сервису, то скорее всего сервис отправит его провайдеру идентификации за токеном, но чтобы не усложнять схему выше, давайте представим, что клиент уже и так знает, что без токена к сервису нечего и соваться.
Аутентификация клиента провайдером идентификации IP. Реализовать процесс можно любым образом, в простейшем случае это аутентификация по логину и паролю, но может быть и любая другая. Например, двухфакторная по паролю и по локации. Главное, чтобы IP мог идентифицировать, аутентифицировать (а при необходимости и авторизовать) клиента.
Генерация и передача клиенту токена. После того, как IP идентифицировал клиента, создается фактор аутентификации для конкретного клиента — токен, в который зашивается вся необходимая информация (про токены и какие они бывают поговорим чуть позже). Токен передается клиенту, который, как правило, хранит токен где-то у себя пока сохраняется его срок действия.
Аутентификация сервером по токену. Вот теперь клиент может отправить запрос серверу только с дополнительной нагрузкой в виде токена, по которому будет проходить аутентификация.
Валидация токена сервером. В целях безопасности валидировать токен все-таки надо — не истек ли срок, тем провайдером был выдан и тому ли клиенту, соответствует ли тело подписи, верны ли утверждения. На схеме изображено, что сервер проверяет токен, обращаясь к IP, но есть варианты, где сервер валидирует токен самостоятельно.
Ответ и возвращение ресурса. Если валидация прошла успешно, то сервер вернет соответствующий ответ. Кстати, может быть и 403, потому что авторизация — немного другая история, а коды ошибок должны быть информативными.
На самом деле, процесс может быть немного сложнее, включать разные виды токенов и разные способы их проверки, но без перечисленных шагов никак не обойтись. Если кто-то знаком с процессом аутентификации по сертификатам, то может заметить много общего — разве что вместо certificate authority — провайдер идентификации, а вместо сертификатов — токены. И действительно, зачем изобретать велосипед, если и так все прекрасно работает?
Небольшой итог
Межсистемная аутентификация — не такая уж пугающая тема, как может показаться на первый взгляд. Если разобраться в факторах, протоколах и токенах, становится ясно, что всё это — всего лишь инструменты для обеспечения безопасного и удобного взаимодействия систем.
Каждый метод аутентификации, будь то классический пароль, сертификаты или токены, имеет свои особенности и применимость. Токены, например, — отличный способ упрощения процессов: они работают как временные пропуска, которые дают доступ только там и тогда, где это нужно. При этом такие стандарты, как OAuth 2.0 или SAML, помогают системам "договориться" между собой.
Конечно, тема безопасности всегда требует внимания к деталям. Применение многофакторной аутентификации и современных подходов не только защищает данные, но и делает взаимодействие более надежным.
Дальше — больше. Если вы хотите углубиться в тему, источники и стандарты, упомянутые в статье, дадут отличное начало для самостоятельного изучения. Ну и обещанный список, тоже прилагается.
И если вам зашел такой формат, то могу поделиться и своими соображениями по поводу использования Keycloak в межсистемной аутентификации, как раз в продолжении темы. Напишите об этом в комментариях.
