Referência de autenticação authentication-reference
Use esta página para pesquisar campos e contratos de autenticação. Para obter a jornada de instalação, consulte Autenticar usuários finais com seu próprio provedor de identidade.
Configurações de autenticação authentication-settings
Encontrado em Configurações > Autenticação. Todos os campos são armazenados por ambiente — o seletor de Workspace seleciona o que você está editando, e salvar nunca afeta o outro.
iss esperada. Deve ser HTTPS. Também publicado como o servidor de autorização deste aplicativo. Um provedor de identidade por aplicativoRegras de validação
offline_access está listado em Escopos com suporte ou em uma açãooffline_access solicita um token de atualização do seu servidor de autorização em vez de conceder acesso a este aplicativo, portanto, não é um escopo anunciado por este aplicativo. Não é necessário listá-lo — a plataforma LLM o solicita diretamente do seu servidor de autorizaçãoAs barras finais em Emissor estão normalizadas, e a comparação iss tolera a diferença — um provedor que sempre emite uma barra à direita ainda valida.
Modos de autenticação auth-modes
Definido por ação em Configuração por ação.
noauthoauth2noauth e oauth2Um manipulador de ação Obrigatório nunca é executado sem um token válido e com escopo correto. Um manipulador da ação Opcional sempre é executado e pode solicitar a entrada com extra.challengeAuth().
Obrigatório é, portanto, o único modo que recusa chamadores não autenticados. Um aplicativo é totalmente restrito somente quando cada uma de suas ações é Obrigatório; uma única ação Nenhum ou Opcional torna o aplicativo misto, porque chamadas anônimas ainda são bem-sucedidas para pelo menos uma ação.
Os modos de autenticação só estão em vigor quando Habilitar autenticação está ativado. As alterações entrarão em vigor na próxima implantação do aplicativo.
Alternar esse switch reescreve os modos por ação:
A alternância do Workspace nunca regrava os modos — ela carrega a configuração salva do outro ambiente como está.
Habilitar autenticação em com cada ação definida como Nenhuma é uma combinação válida, mas inerte: nenhuma chamada é recusada, mas o aplicativo ainda publica seu servidor de autorização para descoberta. Desligue o botão para tornar o aplicativo totalmente público.
Os modos podem ser misturados livremente em um aplicativo. Consulte Comportamento da plataforma LLM para saber como cada plataforma as aplica.
Requisitos de token token-requirements
Seu provedor de identidade deve emitir tokens de acesso que satisfaçam a todos os itens a seguir. Um token reprovado em qualquer verificação é tratado como ausente — o chamador não é autenticado e uma ação Obrigatório desafia-o a entrar.
RS256, RS384, RS512, ES256, ES384, ES512, PS256, PS384 ou PS512. Algoritmos HMAC como HS256 são rejeitadosissaudexpscope ou scpsubgetAuthenticatedUserAuthorization: Bearer <token> cabeçalho da solicitaçãoQuaisquer declarações simples adicionais incluídas pelo seu provedor — por exemplo, tenant ou email — são passadas para o seu manipulador. Os objetos aninhados são descartados e os valores de sequência longa são truncados.
Descoberta do provedor de identidade discovery
Seu aplicativo publica seus próprios metadados de recursos protegidos do RFC 9728 para que as plataformas LLM possam localizar seu servidor de autorização. Você não cria, hospeda ou configura nada para ele.
Você deve fornecer a descoberta por seu próprio lado:
/.well-known/. Seu aplicativo o lê para localizar suas chaves de assinaturahttps://auth.example.com/oauth2/default serve seus metadados em https://auth.example.com/.well-known/oauth-authorization-server/oauth2/defaultAPI de autenticação do manipulador handler-auth-api
Exportado de @adobe/llm-apps-runtime. Cada auxiliar recebe extra, o segundo argumento que seu manipulador recebe.
getAuthenticatedUser(extra)sub do usuário conectado, ou undefined quando a chamada não é autenticadahasScope(extra, scope)true quando o token do chamador carrega scopeAs informações brutas do token verificado estão em extra.authInfo, que é undefined para uma chamada não autenticada.
authInfo.tokenauthInfo.clientIdclient_id ou azp, ou unknownauthInfo.scopesauthInfo.expiresAtexpauthInfo.resourceauthInfo.extrasub mais qualquer outra declaração simples incluída por seu provedor de identidadeextra.challengeAuth(options) está disponível somente nas ações Opcional. Retorne o resultado do manipulador para solicitar que o usuário entre, em vez de retornar o conteúdo.
errorinvalid_token, insufficient_scope ou invalid_request. O padrão é insufficient_scopeerrorDescriptionscopeerror explicitamente. Use invalid_token para um chamador sem sessão válida e insufficient_scope somente para um chamador cujo token é válido, mas não tem um escopo necessário. O valor é transmitido para a plataforma do LLM, que decide por si mesmo como escrever o prompt que mostra ao usuário. Envie o código que descreve com precisão a condição em vez da condição cujo prompt você prefere.Comportamento da plataforma LLM platform-behavior
O suporte para autenticar ações individuais varia de acordo com a plataforma. Configure da mesma forma para ambos; a diferença é o que o usuário experiencia.