Вот что я узнал на прошлой неделе о безопасности.
Если кто-то разбудит меня посреди ночи и скажет, что у нас проблемы с Хьюстоном с SAML, и я думаю, что SAML похож на космический корабль креонов из моего последнего сна, я открою эту записку и узнаю, что это на самом деле механизм аутентификации и авторизации, а не космический корабль креона. Или, может быть, это так? ;)). Давайте копнем ниже и узнаем!
Безопасность — это одна из тех тем, в которых используется такое количество терминологии, что кажется, что вам нужен словарь безопасности. Ниже приведены некоторые из основных терминов и понятий в области безопасности.
Однако вы уже знаете, что такое безопасность, вам просто нужно связать пугающие термины с тем, что вы уже знаете о безопасности из реальной жизни!
SAML — космический корабль или кофе?
Безопасность в основном связана с правильностью. Вы хотите быть уверены, кто тот человек/служба, с которой вы общаетесь (аутентификация). И вы хотите убедиться, что этот персональный сервис делает только то, что ему разрешено делать. (авторизация)
Мы собираемся быстро просмотреть следующие термины:
- Базовая аутентификация — Когда мама и папа думали о безопасности.
- SAML — когда крупные корпорации задумались о безопасности.
- OAuth 2.0 — приемный ребенок мамы, папы и крупных корпораций.
- JWT — ребенок-стартап, ушедший из сферы безопасности.
- Токены — Обмен овец на онлайн-сервисы.
- Носитель авторизации: — Всемогущий заголовок.
- Ключи и $$$ — Расскажите, как мне заработать $$$ на безопасности.
Базовая аутентификация
Это настолько просто, насколько это возможно. Вы просите этого пользователя или службу о чем-то известном только ему, чтобы подтвердить свою личность. Мы используем имя пользователя и какой-то секрет, пароль.
Авторизация: Basic Base64(пользователь,пароль)
Базовая аутентификация не указывает, что вам нужно шифровать данные, которые вам просто нужны для их base64. Итак, чистый текст.
Открытый текст! использовать https для шифрования
Но поскольку это открытый текст, вы хотите его зашифровать, иначе любой человек, подключенный к сети, или любой, кто имеет доступ к сервису, сможет увидеть ваши учетные данные. Итак, вы используете шифрование, https.
SAML
Мы закончили с базовой аутентификацией протокола номер 1. Протокол №2 SAML. (язык разметки подтверждения безопасности).
Аутентификация и авторизация
Подумайте, если это еще один протокол для аутентификации (например, базовая аутентификация), но он также поддерживает авторизацию. Это означает, что он также скажет, что вам разрешено делать.
XML
SAML был создан в те дни, когда XML был королем, поэтому неудивительно, что протокол SAML передает данные для учетных данных и авторизации с помощью XML.
Стороны
В SAML у нас есть две стороны.
- Поставщик услуг. Вы можете купить кофе у поставщика услуг.
- Поставщик удостоверений, Вы доказываете, кто вы, с провайдером идентификации, сильно отличается от покупки кофе, даже если он очень хорошо пахнет!
Поставщик услуг
Это продуктовый магазин, он заинтересован в продаже мне продуктов, а не в управлении идентификацией, поэтому он будет использовать поставщика идентификации, чтобы идентифицировать меня, чтобы авторизовать и аутентифицировать меня.
Поставщик удостоверений
Поставщик удостоверений занимается управлением удостоверениями и тем, что им разрешено делать.
Обеспечивает стандартный единый вход
SAML предоставляет стандартный SingleSignOn, поэтому вы можете использовать одно и то же удостоверение для входа на несколько сайтов, это здорово, это похоже на то, как вы используете Google для входа в разные службы, только на этот раз это протокол SAML. Видите ли, вы уже знали, что такое SAML.
Обмен аутентификацией с цифровой подписью XML
Цифровая подпись означает, что мы можем доказать, кто подписал ваши данные аутентификации.
Сложный
И последнее, но не менее важное: SAML более сложен, чем современные методы SSO, такие как OAuth 2.0. Итак, давайте перейдем к OAuth 2.0, не так ли?
ОАут 2.0
Вы спросите, а как насчет версии 1.0? она была более сложной, поэтому мы перешли на версию 2.0, где нам нужно выполнять меньше операций для аутентификации.
НЕ Аутентификация
Повторяю, oauth2.0 — это не протокол аутентификации, он касается авторизации. Однако это не означает, что мы не используем OAuth для аутентификации, OpenId — это протокол поверх OAuth2.0, который служит для аутентификации.
Авторизация
Вы используете oauth2.0, чтобы разрешить службам проверять, авторизованы ли вы или службы для выполнения операций.
HTTP
OAuth ничего не шифрует внутри, он не требует от вас этого, он не принуждает вас использовать https или другой механизм шифрования, но вы можете использовать их, но просто помните, что внутри протокола нет https или встроенного шифрования. сам.
Токены — это новые учетные данные
Помните учетные данные? имя пользователя Пароль? забудьте о них, теперь вместо них мы используем токены. Это то же самое, у вас есть какой-то ключ, похожий на ваше имя пользователя, и у вас есть секретный ключ, похожий на ваши пароли, скажем, токены не говорят имя пользователя и пароль, хотя это почти то же самое.
Изменение с 1.0 не нужно подписывать каждый вызов
В OAuth1.0 вам нужно было подписать его, вызов oauth 2.0 упрощает его с помощью предоставленного вам токена — вы просто передаете этот токен, не нужно уходить в отставку.
Токен доступа и/или токен обновления
Вы используете токен доступа и/или токен обновления, чтобы обновить свой токен доступа.services.
getAccessToken (обновитьToken)
Таким образом, в основном, чтобы получить новый токен доступа, вы просто вызываете getAccessToken с токеном обновления ввода, чтобы получить новый токен доступа для доступа к службам.
Авторизация: Предъявитель
При базовой аутентификации, OAuth и везде вы увидите этот заголовок:
Authorization: Bearer <access token>
Вы просто Всегда используете этот заголовок для доступа к своим службам.
JWT
Это новенький в городе, и все считают его таким милым! Почему? благодаря этому великому новому изобретению:
Вы не только помещаете авторизацию аутентификации в данные безопасности, вы также добавляете некоторые реальные данные! например «и мне разрешено пить бесплатный кофе! — претензия». Это одно из величайших изобретений 21 века (или нет :).
Расширение OAuth 2.0
JWT — это просто расширение OAuth 2.0, так что это как приемный ребенок.
токен доступа с утверждениями
Таким образом, вы можете указать в JWT, что вам разрешено получать бесплатный кофе, это «умопомрачительная» часть претензии.
Авторизация: Предъявитель
Да, мы снова используем скучное Authorization: Bearer <JWT>
заголовок, полезная нагрузка, подпись
У вас есть 3 части в JWT
- Заголовок (метаданные)
- Полезная нагрузка (кофе)
- Подпись (это я)
HMAC-SHA256
Это протокол, используемый для хеширования сообщения.
hash с секретным ключом для вычисления подписи
HMAC — хэш с секретным ключом для создания подписи.
Данные API данных без сохранения состояния повторно переданы от клиента
Итак, JWT — это безгражданство: вы передаете данные отсюда туда и обратно — все это в JWT
вместо традиционной сессии на сервере
Вы передаете данные в JWT, поэтому вам меньше нужно хранить данные на сервере.
использование
Для чего мы используем JWT?
Аутентификация
Мы используем его для аутентификации ;)
Безопасный обмен информацией
Мы используем его для передачи информации о безопасности!
подписан с открытыми/закрытыми ключами, убедитесь, что содержимое не было подделано
Это потому, что мы подписываем данные, чтобы знать, что они не были подделаны!
Ключи API
имя пользователя и пароль для компьютеров. Как биткойн к доллару.
Идентифицировать вызывающего абонента/приложение
Вы можете определить, кто является вызывающим приложением, поскольку вы даете каждому вызывающему абоненту собственный ключ.
API монетизации
Теперь, когда вы знаете, кто вам звонил, вы можете списать с него $$$ за использование вашего API! (он использовал ключ API для доступа к вам, он должен заплатить за это).
