Resumo

  • A revisão 04 de OAuth for First-Party Applications define um endpoint HTTPS que entrega um código, solicita outra informação por meio do cliente ou manda abrir o navegador. Retirar o redirecionamento faz do binário instalado, da prova do editor, da interface e do cumprimento do fallback partes da confiança.
  • auth_session, PKCE e DPoP podem ligar continuidade a uma instância e uma chave. Eles não provam que o app é realmente first-party, que o usuário viu o desafio correto, que apps irmãs apresentam os mesmos sinais, que o fallback ocorreu quando devia ou que a consequência externa se completou.

O código de uso único foi digitado no aplicativo do banco. O app o enviou ao servidor e recebeu um authorization code pelo canal de retaguarda. Nenhuma janela externa abriu. A fricção diminuiu; a autoridade de apresentação mudou.

OAuth 2.0 for First-Party Applications revision 04 cria o Authorization Challenge Endpoint. O cliente pode enviar login hint, desafio passkey assinado, MFA ou entrada específica. O servidor emite o código, responde insufficient_authorization para continuar ou retorna redirect_to_web para assumir a interação no navegador.

É um Internet-Draft ativo do OAuth WG, de 1º de julho de 2026, com expiração em 2 de janeiro de 2027 e intenção Standards Track. Não é RFC. Não há prova de registro IANA concluído, interoperabilidade, implantação, cobertura de attestation, redução de phishing ou resultado de negócio.

A API nativa desloca a superfície de apresentação

No fluxo tradicional, o servidor controla a página de entrada. Aqui, um cliente muito confiável conduz parte da cerimônia. Ele envia parâmetros OAuth e dados coletados; extensões são aceitas, embora parâmetros estritamente web possam não ter significado e seu tratamento fique fora do escopo.

O servidor decide se há informação suficiente. O app pode escolher prompt, componente que recebe o segredo, texto de erro e endpoint proprietário dos passos intermediários. Formatos, schemas e sequência desses passos também estão fora do rascunho; perfis são necessários para uma solução interoperável.

O recibo precisa registrar build, instância, perfil, classe de entrada sem o segredo, scopes, versão da policy, resposta e próxima instrução. Um código válido comprova emissão de um artefato, não a tela apresentada ao usuário.

First-party é uma relação, não um campo

O AS deve verificar a “first-partyness” antes de prosseguir. App e servidor precisam ser controlados pela mesma entidade e percebidos pelo usuário como pertencentes a ela. A especificação não determina como verificar isso.

Attestation de plataforma, Attestation-Based Client Authentication e Dynamic Client Registration contribuem com fatos menores. Não fundem controle corporativo, cadeia de distribuição, integridade do binário, posse da chave e reconhecimento da marca.

Um package legítimo pode estar antigo ou comprometido. Um app assinado pode mostrar prompt enganoso. Uma DPoP key pode estar numa instância copiada se enrollment não definiu a granularidade. Uma marca familiar pode ser imitada.

Publisher, distribuidor, attester, freshness, nonce, policy e instância devem ficar separados de client_id, auth_session e código. “First-party verificado” é uma conclusão com dependências.

auth_session é contexto opaco transportado pelo app

auth_session associa pedidos da mesma instância, de modo semelhante a um cookie. O cliente o guarda e apresenta, aceita rotação, conserva depois do code e remove no logout. O servidor deve proteger o conteúdo.

O valor precisa ser único; se aleatório, o rascunho recomenda 256 bits de entropia. Deve estar ligado ao dispositivo. Não há vida normativa: tempo, risco ou revogação podem invalidá-lo, e o cliente não pode presumir duração.

A trilha precisa de geração, predecessor, instância, contexto, DPoP key, estágio, rotação, logout e estado final, sem registrar o valor opaco. Sessão aceita só prova continuação do contexto, não honestidade dos prompts ou identidade contínua da pessoa.

DPoP mantém a chave, não a tela

O projeto usa DPoP para challenge, code, token, resource e auth_session. O AS pode exigir a mesma public key desde o início e verificar private-key possession em cada continuação.

Isso limita replay de sessão ou código roubado. Mas key continuity não é app provenance: não diz quem aprovou enrollment, qual package desenhou a tela, se a instância permanece íntegra, se a policy ainda confia nela ou se o usuário quis o scope.

Estados de DPoP, attestation, registration, first-party policy, prompt profile e user authorization precisam ser independentes.

redirect_to_web é transição de segurança

Risco alto, método não suportado, recovery ou exceção podem levar a redirect_to_web. O cliente inicia novo code flow em external user agent, talvez com PAR request_uri.

Sem PKCE code_challenge no pedido nativo inicial, o servidor não pode devolver esse request_uri. O caminho web deve preservar regras de native apps, OAuth Security BCP e issuer identification.

Guardar trigger, risk band, PKCE, issuer, referência, navegador, return URI, state e callback. Abrir navegador não prova destino correto; continuar nativo não prova baixo risco. Ignorar fallback ou substituir por embedded webview cruza a policy.

Vários apps multiplicam a decisão

A experiência deve ser idêntica entre apps first-party. Não é só identidade visual: várias formas legítimas de pedir segredos facilitam imitações. Cada implementação acrescenta parser, storage, accessibility, SDK e defeitos.

SDK comum reduz diferença e cria dependência comum. Versão, assinatura, rollout e retirada entram no controle. A equivalência deve cobrir mensagens, origem, segredo, screenshots, accessibility, fallback, erros, session storage e redaction.

O AS precisa mapear client e attestation policy para entidade, publisher, canal, builds, SDK, perfil e retirement. Uma app irmã fraca não herda confiança pela marca.

O código não é o efeito

Code, PKCE, DPoP, auth_session, step-up e token têm significados diferentes. Nenhum prova que o resource server permitiu ou que a operação posterior terminou. Uma transferência pode falhar ou ser revertida; uma credencial emitida pode não ser instalada. O resultado observado vem depois da cadeia OAuth.