Аутентификация клиента для публичного клиента

Ответ 1

TL;DR:

• Собственные клиенты не могут быть аутентифицированы с помощью client_id и client_secret. Если вам нужно аутентифицировать клиента, вам придется внедрить схему аутентификации, которая не передаст общий секрет клиенту (или вовлечь конечного пользователя в дискуссию по проверке подлинности клиента). В зависимости от модели безопасности приложения вам может не понадобиться аутентификация клиента.
• Конечная точка перенаправления обычно недостаточно для аутентификации клиента (хотя существуют исключения).
• Тип гранта "учетные данные клиента" может использовать любой механизм проверки подлинности клиента, поддерживаемый сервером авторизации, включая учетные данные, выданные при регистрации клиента.

Суть в том, что я прочитал ее, заключается в том, что вы можете доверять конфиденциальному клиенту client_id (читать: "имя пользователя" ) и client_secret (читать: "пароль" ), чтобы аутентифицировать их с помощью вашей службы. Нет шанса [1], что стороннее приложение когда-либо будет представлять себя с учетными данными этого клиента, потому что они разумно предположительно хранятся безопасно от посторонних глаз.

Однако публичный клиент не может гарантировать такую ​​гарантию - независимо от того, распространяется ли приложение на основе браузера или собственное настольное приложение, идентификатор клиента и секрет, в мир в целом. Разумно предположить, что такие приложения окажутся в руках опытных разработчиков и хакеров, которые могут копаться в клиенте и извлекать идентификатор и секрет. По этой причине в разделе 10.1 прямо указано, что:

The authorization server MUST NOT issue client passwords or other
client credentials to native application or user-agent-based
application clients for the purpose of client authentication.

Хорошо. Таким образом, публичные клиенты не могут быть аутентифицированы по паролю. Однако...

The authorization server MAY issue a client password or other
credentials for a specific installation of a native application
client on a specific device.

Это исключение работает, потому что оно связывает аутентификацию клиента с конкретным устройством, а это означает, что даже если кто-то ушел с секретом клиента, они не могли его повторно использовать. Однако неявное в этом исключении состоит в том, что "конкретная установка... на конкретном устройстве" должна быть однозначно идентифицируемой, трудно подделанной и неотъемлемой частью процесса аутентификации для этого клиента.

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

Ключом к танец аутентификации является общий секрет - то, что известно только серверу авторизации и клиенту проверки подлинности. Для публичных клиентов ничто в самом клиенте не является секретным. К счастью, есть варианты, и я говорю не только о бейдах RFID и биометрии (хотя это было бы вполне приемлемо).

Как мысленный эксперимент, рассмотрим клиент на основе браузера. Мы можем с уверенностью предположить несколько вещей об этом: он работает в браузере, он обслуживается из определенного домена, и этот домен контролируется авторами клиентов. У сервера аутентификации уже должен быть URI Client Redirection, поэтому у нас там что-то есть, но по мере того как спецификация вызывает:

A valid redirection URI is not sufficient to verify the client's
identity when asking for resource owner authorization but can be
used to prevent delivering credentials to a counterfeit client
after obtaining resource owner authorization.

Итак, URI перенаправления - это то, что мы должны проверить, но мы не можем доверять, во многом потому, что домен может быть подделан. Но самого сервера быть не может, поэтому мы могли бы попытаться спросить домен о том, что знает только сервер домена клиента. Самый простой способ сделать это - это то, что для сервера аутентификации потребуется второй ("private") URI в том же домене, что и клиент, где будет храниться секрет клиента. Когда клиентское приложение делает запрос авторизации, сервер затем "проверяет" на этот второй URI относительно имени хоста клиента и ищет общий секрет (который должен когда-либо раскрываться только на IP-адрес сервера авторизации) для аутентификации клиент.

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

Другой вариант, который мы имеем, заключается в том, чтобы не осуществлять дальнейшую проверку подлинности и рассматривать клиента как не прошедший проверку. Это, в частности, не то же самое, что и незарегистрированный клиент, но разница тонкая. Незарегистрированным клиентом является клиент, личность которого неизвестна. Неавторизованный клиент - это клиент, чья личность известна, но не доверена. Значение защиты для обоих типов клиентов одинаково: ни одна из них не должна быть доверена личным данным. Независимо от того, решает ли сервер авторизации рассматривать эти два случая одинаково, он, похоже, остается за разработчиком. Например, API может отказаться от всех подключений от незарегистрированного клиента и предоставлять доступ к общедоступному контенту только для чтения любому зарегистрированному клиенту (даже без проверки идентификатора клиента).

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

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

Надеюсь, это помогло!

[1]: компрометация сервера, когда исходный код вашего приложения попадает в злонамеренные руки, является исключением из этого, и в этом случае есть другие защитные функции. Сказав это, спецификация также специально указывает, что простая комбинация имени пользователя и пароля не является самым безопасным вариантом:

The authorization server is encouraged to consider stronger
authentication means than a client password.