Как работает HTTPS. (описание к предыдущему посту)
Прежде всего есть два протокола:
1. HTTP (без S) — это протокол для обмена данными, который чаще всего используется между веб-браузером и веб-сайтом.
2. HTTPS — это защищённая версия этого протокола.
Почему HTTPS защищённый? Благодаря шифрованию.
Данные шифруются таким образом, что только веб-браузер и веб-сайт (сервер) знают, как их прочитать.
Без этого атаки типа «человек посередине» (MITM) могли бы перехватить ваш трафик и прочитать конфиденциальные данные, такие как пароли, данные кредитных карт и т. д.
Протокол, используемый для шифрования данных в HTTPS, — это TLS (Transport Layer Security):
💡 HTTPS = HTTP + TLS
HTTPS использует асимметричное шифрование для шифрования данных. У вас есть:
* 🔑 один закрытый ключ — секретный ключ SSL-сертификата веб-сайта, который никому не передаётся;
* 🔑 один открытый ключ — открытый ключ сертификата, который передаётся всем, кто хочет взаимодействовать с веб-сайтом.
💡 Асимметричное шифрование просто означает, что информация, зашифрованная открытым ключом, может быть расшифрована только закрытым ключом.
В отличие от этого, симметричное шифрование — это когда используется только один ключ, и данные могут быть зашифрованы/расшифрованы с помощью этого же ключа.
На самом деле HTTPS использует оба типа!
Асимметричное шифрование используется для проверки сервера и безопасного создания ключа сеанса. Ключ сеанса будет использоваться для симметричного шифрования.
Ключ сеанса, как следует из названия, существует только в течение сеанса и используется как клиентом, так и сервером для шифрования/дешифрования данных.
Самое интересное, что этот ключ детерминированно генерируется локально как клиентом, так и сервером независимо — он никогда не передаётся по сети.
Итак, какие шаги выполняются?
1. Клиент (браузер) подключается к серверу (веб-странице).
2. Сервер отправляет свой SSL-сертификат (включающий открытый ключ).
3. Клиент и сервер выполняют TLS-рукопожатие и генерируют ключ сеанса для шифрования/дешифрования будущих HTTP-данных.
4. Всё как обычно.
Подробности находятся в TLS-рукопожатии, и это, честно говоря, самая интересная часть работы HTTPS.
TLS-рукопожатие служит трём целям:
* 🔍 проверка подлинности сервера;
* ✨ генерация ключей сеанса для шифрования во время этого сеанса;
* 🤝 выбор версии TLS и наборов шифров, которые будут использоваться.
Пошагово (используя алгоритм TLS 1.2 RSA, потому что он проще):
1. Client Hello Request: клиент инициирует рукопожатие с сообщением, включающим версию TLS и поддерживаемые шифры, а также строку случайных байтов (называемую client random).
2. Server Hello Response: сервер выбирает набор шифров и генерирует свою строку случайных байтов (server random). Он отвечает с набором шифров, своим SSL-сертификатом и server random.
3. Client Verification: клиент проверяет сертификат через доверенный центр сертификации, который его выдал. SSL-сертификат имеет цифровую подпись, которая подписана закрытым ключом CA, поэтому клиент использует открытый ключ CA для её расшифровки.
После этого шага клиент проверил, что сертификат является легитимным и подтверждён через CA — не поддельным.
Примечание: он всё ещё не знает наверняка, действительно ли сервер владеет этим сертификатом (т. е. имеет закрытый ключ).
🤔 Кто определяет, какому центру сертификации можно доверять?
Компания, создавшая ваш браузер! Apple, Microsoft, Google, Mozilla и другие поддерживают свой список центров сертификации. Ваш браузер/ОС поставляется с этим списком доверенных центров сертификации.
Всё основано на доверии, так что лучше им доверять...
Продолжаем:
Прежде всего есть два протокола:
1. HTTP (без S) — это протокол для обмена данными, который чаще всего используется между веб-браузером и веб-сайтом.
2. HTTPS — это защищённая версия этого протокола.
Почему HTTPS защищённый? Благодаря шифрованию.
Данные шифруются таким образом, что только веб-браузер и веб-сайт (сервер) знают, как их прочитать.
Без этого атаки типа «человек посередине» (MITM) могли бы перехватить ваш трафик и прочитать конфиденциальные данные, такие как пароли, данные кредитных карт и т. д.
Протокол, используемый для шифрования данных в HTTPS, — это TLS (Transport Layer Security):
💡 HTTPS = HTTP + TLS
HTTPS использует асимметричное шифрование для шифрования данных. У вас есть:
* 🔑 один закрытый ключ — секретный ключ SSL-сертификата веб-сайта, который никому не передаётся;
* 🔑 один открытый ключ — открытый ключ сертификата, который передаётся всем, кто хочет взаимодействовать с веб-сайтом.
💡 Асимметричное шифрование просто означает, что информация, зашифрованная открытым ключом, может быть расшифрована только закрытым ключом.
В отличие от этого, симметричное шифрование — это когда используется только один ключ, и данные могут быть зашифрованы/расшифрованы с помощью этого же ключа.
На самом деле HTTPS использует оба типа!
Асимметричное шифрование используется для проверки сервера и безопасного создания ключа сеанса. Ключ сеанса будет использоваться для симметричного шифрования.
Ключ сеанса, как следует из названия, существует только в течение сеанса и используется как клиентом, так и сервером для шифрования/дешифрования данных.
Самое интересное, что этот ключ детерминированно генерируется локально как клиентом, так и сервером независимо — он никогда не передаётся по сети.
Итак, какие шаги выполняются?
1. Клиент (браузер) подключается к серверу (веб-странице).
2. Сервер отправляет свой SSL-сертификат (включающий открытый ключ).
3. Клиент и сервер выполняют TLS-рукопожатие и генерируют ключ сеанса для шифрования/дешифрования будущих HTTP-данных.
4. Всё как обычно.
Подробности находятся в TLS-рукопожатии, и это, честно говоря, самая интересная часть работы HTTPS.
TLS-рукопожатие служит трём целям:
* 🔍 проверка подлинности сервера;
* ✨ генерация ключей сеанса для шифрования во время этого сеанса;
* 🤝 выбор версии TLS и наборов шифров, которые будут использоваться.
Пошагово (используя алгоритм TLS 1.2 RSA, потому что он проще):
1. Client Hello Request: клиент инициирует рукопожатие с сообщением, включающим версию TLS и поддерживаемые шифры, а также строку случайных байтов (называемую client random).
2. Server Hello Response: сервер выбирает набор шифров и генерирует свою строку случайных байтов (server random). Он отвечает с набором шифров, своим SSL-сертификатом и server random.
3. Client Verification: клиент проверяет сертификат через доверенный центр сертификации, который его выдал. SSL-сертификат имеет цифровую подпись, которая подписана закрытым ключом CA, поэтому клиент использует открытый ключ CA для её расшифровки.
После этого шага клиент проверил, что сертификат является легитимным и подтверждён через CA — не поддельным.
Примечание: он всё ещё не знает наверняка, действительно ли сервер владеет этим сертификатом (т. е. имеет закрытый ключ).
🤔 Кто определяет, какому центру сертификации можно доверять?
Компания, создавшая ваш браузер! Apple, Microsoft, Google, Mozilla и другие поддерживают свой список центров сертификации. Ваш браузер/ОС поставляется с этим списком доверенных центров сертификации.
Всё основано на доверии, так что лучше им доверять...
Продолжаем:
❤10🔥1👏1
4. Client Key Exchange: клиент создаёт случайную строку байтов, называемую «premaster secret». Он шифрует её с помощью открытого ключа сервера, полученного из SSL-сертификата, и отправляет. Поскольку для шифрования используется алгоритм асимметричного шифрования, клиент знает, что сервер может получить секрет только если расшифрует его с помощью закрытого ключа (что подтверждает владение сертификатом).
5. Session Key Generation: сервер расшифровывает premaster secret с помощью закрытого ключа SSL-сертификата. Клиент и сервер независимо генерируют ключи сеанса локально, используя комбинацию client random, server random и premaster secret.
Поскольку они используют одни и те же данные и детерминированный алгоритм, они должны прийти к одинаковым результатам.
Если это не так, последующее шифрование/дешифрование данных при записи не будет соответствовать протоколу HTTP/HTTPS и завершится ошибкой.
💡 Шаг 5 косвенно подтверждает клиенту, что сервер владеет предоставленным им SSL-сертификатом (а не просто делает вид, что он у него есть).
После этого сеансовый ключ может использоваться для симметричного шифрования/дешифрования HTTP-данных.
5. Session Key Generation: сервер расшифровывает premaster secret с помощью закрытого ключа SSL-сертификата. Клиент и сервер независимо генерируют ключи сеанса локально, используя комбинацию client random, server random и premaster secret.
Поскольку они используют одни и те же данные и детерминированный алгоритм, они должны прийти к одинаковым результатам.
Если это не так, последующее шифрование/дешифрование данных при записи не будет соответствовать протоколу HTTP/HTTPS и завершится ошибкой.
💡 Шаг 5 косвенно подтверждает клиенту, что сервер владеет предоставленным им SSL-сертификатом (а не просто делает вид, что он у него есть).
После этого сеансовый ключ может использоваться для симметричного шифрования/дешифрования HTTP-данных.
👍10👏3🔥2
На сопровождающих JavaScript-библиотеки на сервисе NPM была совершена масштабная фишинг-атака, в ходе которой от имени сервиса NPM было разослано сообщение о необходимости подтвердить свой email. Проведённая атака позволила злоумышленникам получить NPM-токены сопровождающего одного из крупных JavaScript-проектов и выпустить обновления с вредоносным кодом для пяти NPM-пакетов, в сумме насчитывающих около 100 млн загрузок в неделю.
Отправленное сопровождающим сообщение было стилизовано под типовые уведомления NPM, отправляемые с адреса "support@npmjs.org", но в качестве ссылки для перехода был указан домен "npnjs.com" вместо "npmjs.com" (третья буква "n" вместо "m").
В ходе атаки были сгенерированы новые версии пакетов:
eslint-config-prettier: 8.10.1, 9.1.1, 10.1.6, 10.1.7.
eslint-plugin-prettier: 4.2.2, 4.2.3.
synckit: 0.11.9.
@pkgr/core: 0.2.8.
napi-postinstall: 0.3.1.
В пакеты был добавлен вредоносный код для атаки на пользователей Windows - они загружали библиотеку node-gyp.dll с функциональностью для удалённого выполнения команд.
Неизвестно, сколько пользователей успело загрузить вредоносные версии (например, вредоносная версия пакета eslint-plugin-prettier оставалась в репозитории около двух дней), но данные пакеты довольно широко используются. Так, за прошлую неделю пакет eslint-config-prettier насчитывал 30 млн загрузок и использовался в качестве зависимости у 11762 тысячи пакетов, пакет eslint-plugin-prettier - 21 млн загрузок (8468 зависимых пакетов), synckit - 18 млн, @pkgr/core - 16 млн и napi-postinstall - 10 млн.
https://socket.dev/blog/npm-phishing-campaign-leads-to-prettier-tooling-packages-compromise
Отправленное сопровождающим сообщение было стилизовано под типовые уведомления NPM, отправляемые с адреса "support@npmjs.org", но в качестве ссылки для перехода был указан домен "npnjs.com" вместо "npmjs.com" (третья буква "n" вместо "m").
В ходе атаки были сгенерированы новые версии пакетов:
eslint-config-prettier: 8.10.1, 9.1.1, 10.1.6, 10.1.7.
eslint-plugin-prettier: 4.2.2, 4.2.3.
synckit: 0.11.9.
@pkgr/core: 0.2.8.
napi-postinstall: 0.3.1.
В пакеты был добавлен вредоносный код для атаки на пользователей Windows - они загружали библиотеку node-gyp.dll с функциональностью для удалённого выполнения команд.
Неизвестно, сколько пользователей успело загрузить вредоносные версии (например, вредоносная версия пакета eslint-plugin-prettier оставалась в репозитории около двух дней), но данные пакеты довольно широко используются. Так, за прошлую неделю пакет eslint-config-prettier насчитывал 30 млн загрузок и использовался в качестве зависимости у 11762 тысячи пакетов, пакет eslint-plugin-prettier - 21 млн загрузок (8468 зависимых пакетов), synckit - 18 млн, @pkgr/core - 16 млн и napi-postinstall - 10 млн.
https://socket.dev/blog/npm-phishing-campaign-leads-to-prettier-tooling-packages-compromise
Socket
Active Supply Chain Attack: npm Phishing Campaign Leads to P...
Popular npm packages like eslint-config-prettier were compromised after a phishing attack stole a maintainer’s token, spreading malicious updates.
🕊16😱9💊7
Несколько дней назад исследователи по безопасности также обратили внимание на 28 NPM-пакетов, авторами которых было включено изменение категории Protestware. Изменение приводило к воспроизведению украинского гимна и отключению обработки событий от мыши на сайтах в доменных зонах "ru", "su", "by" и "рф", если пользователь ранее уже открывал сайт более трёх дней назад и в его браузере была включена поддержка русского языка.
https://socket.dev/blog/protestware-update-28-npm-packages-affected-by-payload-targeting-russian-language-users
https://socket.dev/blog/protestware-update-28-npm-packages-affected-by-payload-targeting-russian-language-users
Socket
Tracking Protestware Spread: 28 npm Packages Affected by Pay...
Undocumented protestware found in 28 npm packages disrupts UI for Russian-language users visiting Russian and Belarusian domains.
😁24🤡17👎3🤮3🔥2😱2👏1🤬1💊1
Как масштабировать базы данных?
Партиционирование (разделение) базы данных — это процесс разделения большой таблицы или базы данных на более мелкие, удобные для управления части, известные как партиции. Это позволяет нам запрашивать только части данных, что ускоряет их загрузку.
В целом существует два типа партиционирования:
1. Горизонтальное партиционирование (шардинг). Разделяет таблицы по строкам, при этом каждая партиция содержит одинаковую схему, но разные строки. Идеально подходит для многопользовательских приложений, где данные можно разделить по клиентам или пользователям для распределённых вычислений, или когда данные слишком велики для хранения в одной базе данных.
Существуют различные виды шардинга:
* Хеш-шардинг (Hash-based sharding). Шард определяется с помощью хеш-функции на определённом ключевом столбце в каждой записи. Эта хеш-функция равномерно распределяет записи по доступным шардам. Основное преимущество — равномерное распределение данных и нагрузки, но это может усложнить запросы, охватывающие несколько шардов, и затруднить повторную шардизацию.
* Ранг-шардинг (Range-based sharding). Разделение данных на шарды на основе диапазонов определённого ключа. Например, идентификаторы клиентов от 1 до 1000 могут храниться в одном шарде, а идентификаторы 1001–2000 — в другом. Этот подход упрощает запросы, включающие операции с диапазонами, но может привести к неравномерному распределению данных и горячим точкам, если данные распределены неравномерно.
* Директивный шардинг (Directory-based sharding). Этот метод использует справочную таблицу для сопоставления ключей с соответствующими шардами. Он обеспечивает отличную гибкость, позволяя легко добавлять или удалять шарды и выполнять простую повторную шардизацию.
При шардинге каждый сервер базы данных должен быть структурно идентичен, а записи данных должны быть разделены по шардированной базе данных.
2. Вертикальное партиционирование. Разделяет таблицы по столбцам или таблицам, отделяя часто используемые столбцы от менее используемых, оптимизируя время доступа и эффективность кэширования. Таким образом, каждая таблица может быть размещена в отдельной базе данных.
Однако шардинг базы данных — сложная задача. Это отнимает много времени, поскольку необходимо настроить множество вещей, таких как перемещение данных и сопоставление запросов. Кроме того, это требует финансовых затрат.
Вот несколько эффективных практик при возникновении проблем с базой данных:
1. Вертикальное масштабирование — добавление дополнительных ресурсов на сервер БД (CPU, память и т. д.).
2. Репликация — создание реплики для чтения из вашей БД. Это помогает улучшить производительность чтения, но также необходимо включить кэширование.
Если всё вышеперечисленное не помогает, то можно прибегнуть к партиционированию:
* Используйте горизонтальное партиционирование для больших таблиц, где масштабируемость и производительность для определённых запросов имеют решающее значение.
* Используйте вертикальное партиционирование, когда у вас есть таблицы со множеством столбцов, но не все они часто используются вместе.
Партиционирование (разделение) базы данных — это процесс разделения большой таблицы или базы данных на более мелкие, удобные для управления части, известные как партиции. Это позволяет нам запрашивать только части данных, что ускоряет их загрузку.
В целом существует два типа партиционирования:
1. Горизонтальное партиционирование (шардинг). Разделяет таблицы по строкам, при этом каждая партиция содержит одинаковую схему, но разные строки. Идеально подходит для многопользовательских приложений, где данные можно разделить по клиентам или пользователям для распределённых вычислений, или когда данные слишком велики для хранения в одной базе данных.
Существуют различные виды шардинга:
* Хеш-шардинг (Hash-based sharding). Шард определяется с помощью хеш-функции на определённом ключевом столбце в каждой записи. Эта хеш-функция равномерно распределяет записи по доступным шардам. Основное преимущество — равномерное распределение данных и нагрузки, но это может усложнить запросы, охватывающие несколько шардов, и затруднить повторную шардизацию.
* Ранг-шардинг (Range-based sharding). Разделение данных на шарды на основе диапазонов определённого ключа. Например, идентификаторы клиентов от 1 до 1000 могут храниться в одном шарде, а идентификаторы 1001–2000 — в другом. Этот подход упрощает запросы, включающие операции с диапазонами, но может привести к неравномерному распределению данных и горячим точкам, если данные распределены неравномерно.
* Директивный шардинг (Directory-based sharding). Этот метод использует справочную таблицу для сопоставления ключей с соответствующими шардами. Он обеспечивает отличную гибкость, позволяя легко добавлять или удалять шарды и выполнять простую повторную шардизацию.
При шардинге каждый сервер базы данных должен быть структурно идентичен, а записи данных должны быть разделены по шардированной базе данных.
2. Вертикальное партиционирование. Разделяет таблицы по столбцам или таблицам, отделяя часто используемые столбцы от менее используемых, оптимизируя время доступа и эффективность кэширования. Таким образом, каждая таблица может быть размещена в отдельной базе данных.
Однако шардинг базы данных — сложная задача. Это отнимает много времени, поскольку необходимо настроить множество вещей, таких как перемещение данных и сопоставление запросов. Кроме того, это требует финансовых затрат.
Вот несколько эффективных практик при возникновении проблем с базой данных:
1. Вертикальное масштабирование — добавление дополнительных ресурсов на сервер БД (CPU, память и т. д.).
2. Репликация — создание реплики для чтения из вашей БД. Это помогает улучшить производительность чтения, но также необходимо включить кэширование.
Если всё вышеперечисленное не помогает, то можно прибегнуть к партиционированию:
* Используйте горизонтальное партиционирование для больших таблиц, где масштабируемость и производительность для определённых запросов имеют решающее значение.
* Используйте вертикальное партиционирование, когда у вас есть таблицы со множеством столбцов, но не все они часто используются вместе.
❤7🔥2👏2
Вертикальное и горизонтальное масштабирование базы данных (к предыдущему посту)
Балансировщик нагрузки vs Обратный прокси vs API Gateway (продолжение)
Балансировщик нагрузки (Load Balancer)
- Равномерно распределяет трафик между серверами для повышения эффективности.
- Работает на уровне 4 (TCP) или уровне 7 (HTTP/HTTPS).
- Сценарии использования: высоконагруженные сайты, отказоустойчивость.
- Преимущества: повышает отказоустойчивость, обрабатывает всплески нагрузки, позволяет масштабирование.
- Недостатки: может стать единой точкой отказа без избыточности.
- Примеры: HAProxy, AWS ELB, Nginx.
Обратный прокси (Reverse Proxy)
- Пересылает клиентские запросы на серверы, скрывая детали серверов.
- Работает на уровне 7 (HTTP/HTTPS).
- Сценарии использования: SSL-терминирование, кэширование, публичный доступ к API.
- Преимущества: улучшает производительность, добавляет безопасность, позволяет фильтровать контент.
- Недостатки: добавляет сетевую задержку.
- Примеры: Nginx, Apache HTTP Server.
API Gateway (API Шлюз)
- Маршрутизирует запросы к правильным сервисам.
- Работает на уровне 7 (HTTP/HTTPS).
- Сценарии использования: микросервисы, мобильные API.
- Преимущества: центральная точка входа для API, обрабатывает аутентификацию и дросселирование.
- Недостатки: добавляет задержку и сложность, может стать бутылочным горлышком.
- Примеры: Kong, AWS API Gateway, Apigee, Tyk.
Балансировщик нагрузки (Load Balancer)
- Равномерно распределяет трафик между серверами для повышения эффективности.
- Работает на уровне 4 (TCP) или уровне 7 (HTTP/HTTPS).
- Сценарии использования: высоконагруженные сайты, отказоустойчивость.
- Преимущества: повышает отказоустойчивость, обрабатывает всплески нагрузки, позволяет масштабирование.
- Недостатки: может стать единой точкой отказа без избыточности.
- Примеры: HAProxy, AWS ELB, Nginx.
Обратный прокси (Reverse Proxy)
- Пересылает клиентские запросы на серверы, скрывая детали серверов.
- Работает на уровне 7 (HTTP/HTTPS).
- Сценарии использования: SSL-терминирование, кэширование, публичный доступ к API.
- Преимущества: улучшает производительность, добавляет безопасность, позволяет фильтровать контент.
- Недостатки: добавляет сетевую задержку.
- Примеры: Nginx, Apache HTTP Server.
API Gateway (API Шлюз)
- Маршрутизирует запросы к правильным сервисам.
- Работает на уровне 7 (HTTP/HTTPS).
- Сценарии использования: микросервисы, мобильные API.
- Преимущества: центральная точка входа для API, обрабатывает аутентификацию и дросселирование.
- Недостатки: добавляет задержку и сложность, может стать бутылочным горлышком.
- Примеры: Kong, AWS API Gateway, Apigee, Tyk.
👍5❤3👏1
Добавил два новых мобильных приложения на Android для руководств с сайта:
Руководство по ассемблеру NASM:
https://www.rustore.ru/catalog/app/com.metanit.nasm
Руководство по созданию мобильных приложений для Android:
https://www.rustore.ru/catalog/app/com.metanit.android
Ну и из интереса сделал еще одну небольшую игру для Andoid - Судоку
Если кому интересно, игра в Rustore - https://www.rustore.ru/catalog/app/com.metanit.sudoku
Игра в Google Play - https://play.google.com/store/apps/details?id=com.metanit.sudoku
Руководство по ассемблеру NASM:
https://www.rustore.ru/catalog/app/com.metanit.nasm
Руководство по созданию мобильных приложений для Android:
https://www.rustore.ru/catalog/app/com.metanit.android
Ну и из интереса сделал еще одну небольшую игру для Andoid - Судоку
Если кому интересно, игра в Rustore - https://www.rustore.ru/catalog/app/com.metanit.sudoku
Игра в Google Play - https://play.google.com/store/apps/details?id=com.metanit.sudoku
RuStore
Руководство по ассемблеру NASM в каталоге RuStore
🚀 Руководство по ассемблеру NASM — Руководство по ассемблеру NASM 📱 Скачайте за 799 рублей на смартфон, ТВ или планшет. Официальная версия (1.0) в RuStore — до 1 тыс установок, рейтинг 0,0★. Безопасно для 0+.
👍21👎4🥰2👏1
SSO (Single Sign-On / Единый вход) (продолжение к предыдущему посту)
SSO можно представить как главный ключ, открывающий все разные замки. Эта технология позволяет пользователю входить в различные системы, используя единый набор учётных данных.
В наше время, когда мы получаем доступ к большему количеству приложений, чем когда-либо прежде, SSO становится важным решением для борьбы с усталостью от множества паролей и упрощает пользовательский опыт.
Чтобы полностью понять процесс SSO, давайте рассмотрим, как пользователь входит в LinkedIn с помощью Google в качестве поставщика удостоверений:
1. Запрос на доступ
Сначала пользователь пытается получить доступ к поставщику услуг (LinkedIn). На этом этапе пользователю предлагаются варианты входа в систему, и в этом примере он выбирает «Войти через Google».
2. Запрос на аутентификацию
Поставщик услуг (LinkedIn) перенаправляет пользователя к поставщику удостоверений (Google) с запросом на аутентификацию.
3. Проверка активной сессии
Получив запрос, поставщик удостоверений (Google) проверяет наличие активной сессии. Если она не найдена, запрашивается аутентификация.
4. Пользователь отправляет учётные данные
На этом этапе пользователь отправляет свои учётные данные (имя пользователя и пароль) поставщику удостоверений (IdP).
5. Проверка учётных данных
Поставщик удостоверений сверяет предоставленные учётные данные с каталогом пользователей (базой данных). Если учётные данные верны, IdP создаёт токен аутентификации или утверждение.
6. Поставщик удостоверений отправляет токен поставщику услуг
После создания токена или утверждения IdP отправляет его обратно поставщику услуг, подтверждая личность пользователя. Теперь пользователь аутентифицирован и может получить доступ к поставщику услуг (LinkedIn).
7. Доступ предоставлен с использованием существующей сессии
Поскольку поставщик удостоверений установил сессию, при попытке пользователя получить доступ к другому поставщику услуг (например, GitHub) ему не нужно повторно вводить свои учётные данные. Будущие поставщики услуг будут запрашивать аутентификацию у поставщика удостоверений, распознавать существующую сессию и предоставлять пользователю доступ на основе ранее подтверждённой сессии.
Рабочие процессы SSO, подобные описанному выше, работают на протоколах SSO — наборе правил, которые регулируют взаимодействие и доверие между IdP и SP. Распространённые протоколы включают язык разметки утверждений безопасности (SAML), OpenID Connect и OAuth.
SSO можно представить как главный ключ, открывающий все разные замки. Эта технология позволяет пользователю входить в различные системы, используя единый набор учётных данных.
В наше время, когда мы получаем доступ к большему количеству приложений, чем когда-либо прежде, SSO становится важным решением для борьбы с усталостью от множества паролей и упрощает пользовательский опыт.
Чтобы полностью понять процесс SSO, давайте рассмотрим, как пользователь входит в LinkedIn с помощью Google в качестве поставщика удостоверений:
1. Запрос на доступ
Сначала пользователь пытается получить доступ к поставщику услуг (LinkedIn). На этом этапе пользователю предлагаются варианты входа в систему, и в этом примере он выбирает «Войти через Google».
2. Запрос на аутентификацию
Поставщик услуг (LinkedIn) перенаправляет пользователя к поставщику удостоверений (Google) с запросом на аутентификацию.
3. Проверка активной сессии
Получив запрос, поставщик удостоверений (Google) проверяет наличие активной сессии. Если она не найдена, запрашивается аутентификация.
4. Пользователь отправляет учётные данные
На этом этапе пользователь отправляет свои учётные данные (имя пользователя и пароль) поставщику удостоверений (IdP).
5. Проверка учётных данных
Поставщик удостоверений сверяет предоставленные учётные данные с каталогом пользователей (базой данных). Если учётные данные верны, IdP создаёт токен аутентификации или утверждение.
6. Поставщик удостоверений отправляет токен поставщику услуг
После создания токена или утверждения IdP отправляет его обратно поставщику услуг, подтверждая личность пользователя. Теперь пользователь аутентифицирован и может получить доступ к поставщику услуг (LinkedIn).
7. Доступ предоставлен с использованием существующей сессии
Поскольку поставщик удостоверений установил сессию, при попытке пользователя получить доступ к другому поставщику услуг (например, GitHub) ему не нужно повторно вводить свои учётные данные. Будущие поставщики услуг будут запрашивать аутентификацию у поставщика удостоверений, распознавать существующую сессию и предоставлять пользователю доступ на основе ранее подтверждённой сессии.
Рабочие процессы SSO, подобные описанному выше, работают на протоколах SSO — наборе правил, которые регулируют взаимодействие и доверие между IdP и SP. Распространённые протоколы включают язык разметки утверждений безопасности (SAML), OpenID Connect и OAuth.
👍5🥰1👏1