Кратко

  • Revision 04 OAuth for First-Party Applications задаёт HTTPS endpoint, который выдаёт код, просит нативный клиент собрать ещё данные или требует браузер. Отказ от redirect превращает установленный binary, сведения об издателе, интерфейс и выполнение fallback в части доверия.
  • auth_session, PKCE и DPoP могут связать последовательность с экземпляром и ключом. Они не доказывают настоящую first-partyness, показ правильного challenge, одинаковые сигналы в родственных приложениях, своевременный fallback или внешний результат.

Пользователь ввёл одноразовый код в банковском приложении, оно отправило его серверу и получило authorization code по back channel. Браузер не открылся. Исчезло переключение экрана, но не передача доверия.

OAuth 2.0 for First-Party Applications revision 04 вводит Authorization Challenge Endpoint. Клиент может передать login hint, signed passkey challenge или MFA code. Сервер выдаёт код, отвечает insufficient_authorization для продолжения либо redirect_to_web, чтобы вернуть взаимодействие в браузер.

Это активный Internet-Draft OAuth WG от 1 июля 2026 года, истекающий 2 января 2027-го и предназначенный для Standards Track. Это не RFC. Нет доказательств завершённой IANA регистрации, реализации, совместимости, deployment, покрытия attestation, снижения phishing или результата операции.

Нативный API переносит поверхность взаимодействия

В обычном code flow сервер контролирует страницу для credentials. Здесь доверенный client проводит часть церемонии и POSTит OAuth parameters с собранными данными. Web-specific extensions могут не иметь нативного смысла; их обработка не определена.

Сервер решает, достаточно ли информации, но приложение может выбирать prompt, компонент чтения секрета, объяснение ошибки и proprietary endpoint. Форматы промежуточных шагов, challenge schemas и порядок находятся вне scope; для interop нужны profiles.

Квитанция должна хранить build, installed instance, profile, класс ввода без секрета, scopes, policy version, response и next instruction. Валидный code доказывает выдачу grant artifact, но не экран, который видел человек.

First-party — отношение, а не поле

AS должен проверить “first-partyness”: приложение и сервер контролирует одна entity, и пользователь понимает их принадлежность. Метод проверки не предписан.

Platform attestation, Attestation-Based Client Authentication и Dynamic Client Registration дают отдельные факты. Они не объединяют корпоративный контроль, distribution custody, binary integrity, key possession и узнавание бренда.

Подписанный package может быть устаревшим или скомпрометированным. Настоящее приложение может нарисовать ложный prompt. DPoP key может относиться к копии, если enrollment не установил instance. Знакомую поверхность можно имитировать.

Publisher, distributor, attester, freshness, nonce, policy и instance нужно хранить отдельно от client_id, auth_session и кода. “First-party verified” — вывод с зависимостями.

auth_session — контекст, переносимый приложением

auth_session связывает запросы одного instance, подобно cookie. Клиент хранит и предъявляет opaque value, принимает rotation, сохраняет после code и удаляет при logout.

Значение должно быть unique; для random рекомендуется 256-bit entropy. Желательно device binding. Срок не задан: time, risk или revocation могут отменить его, а клиент не вправе рассчитывать на длительность.

Аудит хранит generation, predecessor, instance, context, DPoP key, stage, rotation, logout и terminal state, но не сам секретный value. Принятая session означает лишь продолжение контекста, а не честность прошлых prompts или того же человека.

DPoP связывает ключ, не экран

Проект описывает DPoP для challenge, code, token, resource и auth_session. AS может требовать один public key и проверять private-key possession при каждом продолжении.

Это снижает replay украденной session или code. Но key continuity не равна app provenance: она не говорит, кто разрешил enrollment, какой package рисует UI, цел ли instance, доверяет ли policy и хотел ли пользователь scope.

DPoP match, attestation, registration, first-party policy, prompt profile и user authorization должны быть отдельными статусами.

redirect_to_web — переход безопасности

High risk, unsupported method, recovery или exception ведут к redirect_to_web. Клиент запускает новый code flow во внешнем user agent, иногда с PAR request_uri.

Без initial PKCE code_challenge сервер не должен возвращать request_uri. Web path сохраняет native-app rules, Security BCP и issuer identification.

Записывайте trigger, risk band, PKCE, issuer, reference, browser, return URI, state и callback. Запуск браузера не доказывает правильный сервер; native continuation не доказывает низкий риск. Игнорирование fallback или embedded webview нарушает policy.

Несколько приложений умножают доверие

Проект требует одинаковый native experience. Это не только branding: несколько легитимных форм ввода приучают пользователя к большему числу подделок. Каждая реализация добавляет parser, storage, accessibility, SDK и ошибки.

Общий SDK уменьшает drift и становится общей зависимостью. Version, signature, rollout и emergency withdrawal входят в контроль. Совпадение включает prompts, origin cues, secret handling, screenshots, accessibility, fallback, errors, session storage и redaction.

AS должен сопоставить clients с entity, publisher, channel, builds, SDK, profile и retirement. Слабое sibling app не наследует доверие только по бренду.

Code не является результатом

Authorization code, PKCE, DPoP, auth_session, step-up и access token означают разное. Ничто не доказывает resource decision или downstream effect. Перевод может не пройти или быть отменён, credential — не установиться. Outcome receipt следует после OAuth.