При отправке запроса HTTPS, есть ли разница с точки зрения безопасности между заголовком и телом сообщения? Еще один уязвим для утечки или перехвата? Если так, то почему?
Я прочитал сравнения GET и POST и различных схем аутентификации и шифрования друг с другом, но ничего о заголовке и теле приложений Post / x-www-form-urlencoded. Я признаю, что потратил всего 20 минут на поиски и поиск, поэтому прошу прощения, если это уже было рассмотрено.
Хотя я считаю, что это является общим для всего трафика HTTPS, я спрашиваю в контексте OpenId Connect. Я использую тип предоставления кода авторизации и клиентские библиотеки Spring Security OAuth.
OIDC предусматривает, что у Клиентов и Серверов авторизации есть выбор способа отправки учетных данных при обмене одноразовым кодом на токен длительного идентификатора. Цитирование openid.net раздел openid-connect-core 9. Аутентификация клиента :
Этот раздел определяет набор методов аутентификации клиента, которые
используется клиентами для аутентификации на сервере авторизации при использовании
Конечная точка токена. При регистрации клиента RP (клиент) МОЖЕТ
зарегистрировать метод аутентификации клиента. Если метод не зарегистрирован,
по умолчанию используется метод client_secret_basic.
Эти методы аутентификации клиента:
client_secret_basic
Клиенты, получившие значение client_secret
с сервера авторизации авторизуйтесь с авторизацией
Сервер в соответствии с Разделом 2.3.1 OAuth 2.0 [RFC6749] с использованием
базовая схема аутентификации HTTP.
Обратите внимание, это заголовок Authorization: Basic <value>. Поставщик, с которым я интегрируюсь, поддерживает это через OpenId client_id и client_secret, соединенные двоеточием и Base64 в кодировке.
client_secret_post
Клиенты, которые
получили значение client_secret от сервера авторизации,
аутентифицироваться на Сервере авторизации в соответствии с Разделом
2.3.1 OAuth 2.0 [RFC6749] путем включения учетных данных клиента в тело запроса.
Мне не удалось найти что-то конкретное для OpenId Connect, которое выражало бы предпочтение любого из методов.
Я интегрируюсь с поставщиком OIDC, который разрешает любой метод, но вы должны выбрать, и все зависимые серверы ресурсов должны соответствовать единственному выбору. И заголовок, и текст сообщения отправляются в виде простого текста. (Обратите внимание, что этот провайдер не поддерживает ни метод client_secret_jwt, который является версией секретного секретного секретного кода в кодировке HMAC, ни метод private_key_jwt, который является публично-частной подписью, оба из которых явно более безопасны, чем значения в основном открытого текста, но неясно, добавляет ли это какое-либо практическое улучшение безопасности для связи с шифрованием TLS / SSL.)