Frame.io Python SDK - Guia de autenticação
Frame.io Python SDK - Guia de autenticação
Este guia explica como autenticar com a API do Frame.io usando o SDK Python Frame.io (frameio). A API Frame.io V4 usa o Adobe Identity Management Service (IMS), a plataforma de identidade OAuth 2.0 da Adobe. Esta é uma referência independente para desenvolvedores Python. Todos os exemplos de código e fluxos abaixo são apenas para o pacote frameio
Tipos de autenticação no SDK Python
O SDK Python é compatível com quatro opções de autenticação:
A credencial Native App da Adobe exige manipuladores de esquema de URI personalizado, por exemplo, adobe+<hash>://…</hash>) que interceptam redirecionamentos no nível do sistema operacional.O Python não tem uma forma padrão de registrar esses manipuladores, portanto o SDK Python não oferece uma classe NativeAppAuth.Para aplicativos Python com interação do usuário, use WebAppAuth com um servidor de callback local, como Flask ou FastAPI.Para cargas de trabalho não interativas, use ServerToServerAuth.
Usuários de conta de serviço
Ao usar autenticação Server-to-Server, seu aplicativo atua como um usuário de conta de serviço, um tipo distinto de conta que pode executar ações em nome do serviço. Eles ficam visíveis para outros usuários no Frame.io: quando uma conta de serviço executa uma ação, seu nome é exibido na IU. Você pode conceder e revogar o acesso da conta de serviço pelo Adobe Admin Console e Developer Console. Os nomes de conta de serviço são gerenciados pela IU do Frame.io. Por padrão, a primeira conexão S2S é nomeada Usuários de conta de serviço, a segunda Usuários de conta de serviço 2 e assim por diante.
Consulte Automatizar a configuração usando suporte servidor para servidor Frame.io para obter mais informações.
Início rápido
Pré-requisitos
- Credenciais do Adobe Developer Console:
- ID do cliente — obrigatório para todos os fluxos OAuth - Segredo do cliente — obrigatório para fluxos servidor a servidor e aplicativo web - URI de redirecionamento — obrigatório para fluxos de aplicativo web e SPA; deve estar registrado no Projeto do Adobe
- Instalar o SDK:
Escolha de um método
- **Nenhum usuário envolvido?**Use Server-to-Server (
ServerToServerAuth). - **Usuário envolvido e você pode armazenar um segredo?**Use Web App (
WebAppAuth). - **Usuário envolvido, mas você não pode armazenar um segredo?**Use SPA (
SPAAuth).
Token de acesso
Se você já tiver um token de acesso de outro sistema OAuth ou de uma troca anterior, por exemplo, pelo nosso API Explorer, poderá passá-lo diretamente:
Essa é a abordagem mais simples, mas o token acabará expirando e o SDK não o atualizará para você.
Tokens de desenvolvedor legados
Para contas migradas para a V4 que ainda não são administradas pelo Adobe Admin Console, você pode continuar usando Tokens de desenvolvedor legados do site de desenvolvedores do Frame.io. Você deve incluir o cabeçalho x-frameio-legacy-token-auth e defini-lo como true:
Tokens de desenvolvedor legados não expiram, mas são um mecanismo de transição. Para novas integrações e cargas de trabalho de produção, recomendamos usar um dos fluxos OAuth 2.0 abaixo. Consulte o Guia de migração para obter detalhes.
Servidor para servidor (Credenciais do cliente)
Use isso para serviços de backend e scripts que precisam de acesso ao Frame.io sem interação do usuário. Esse fluxo só está disponível para contas Frame.io V4 administradas pelo Adobe Admin Console. Seu aplicativo se autentica como um usuário de conta de serviço sem intervenção humana.
Sincronizar
Assíncrono
É isso. Auth.get_token é um callable que o SDK invoca em cada solicitação. Se o token atual ainda for válido, ele retornará imediatamente. Se estiver prestes a expirar, ele buscará um novo primeiro, de forma totalmente transparente.
Como funciona
Suas credenciais do cliente (ID + segredo do cliente) nunca expiram. Você só precisa alterná-las manualmente por higiene de segurança. S2S oferece acesso à API efetivamente permanente e ininterrupto, sem nenhuma intervenção manual.
Nos bastidores:
- Na primeira chamada da API,
get_tokensolicita um novo token de acesso do Adobe IMS usando a concessãoclient_credentials. - O token é armazenado em cache na memória. Tokens de acesso individuais expiram (normalmente em 24 horas), mas isso é tratado para você.
- Quando um token em cache está dentro do buffer de atualização (padrão: 60 segundos antes da expiração), o SDK busca um novo automaticamente usando as mesmas credenciais de cliente.
- Não há tokens de atualização envolvidos. As próprias credenciais de cliente são o segredo de longa duração e sempre podem ser usadas para emitir um novo token de acesso.
Autenticação explícita
Se quiser buscar o token antecipadamente, por exemplo, para falhar rapidamente com credenciais incorretas na inicialização:
Aplicativo web (Código de autorização)
Use isso para aplicativos do lado do servidor em que os usuários fazem logon com sua Adobe ID. Este fluxo requer um segredo do cliente, que deve ser armazenado com segurança no servidor.
Processar o callback
Quando o Adobe IMS redireciona o usuário de volta para o redirectUri, extraia os parâmetros code e state.Verifique se o estado corresponde ao que você armazenou e troque o código por tokens:
Sincronizar
Assíncrono
Isso troca o código de autorização por um token de acesso e um token de atualização, armazenando ambos internamente.
Exemplo completo do Flask
Aplicativo de página única / PKCE (Código de autorização + PKCE)
Use isso para aplicativos baseados em navegador, aplicativos para desktop ou ferramentas de CLI que não conseguem armazenar um client secret com segurança. Este fluxo usa PKCE (RFC 7636) para proteger a troca de código de autorização.
Uso assíncrono
Toda classe de autenticação tem uma contraparte assíncrona com prefixo Async. Os exemplos de código acima incluem abas Sync e Async quando aplicável.
Atualização manual de token
Para fluxos de aplicativo web e SPA, o SDK atualiza tokens automaticamente via get_token. Se você precisar de controle explícito, pode chamar refresh() diretamente:
Sincronizar
Assíncrono
Isso é útil quando você quer forçar uma atualização antes de uma operação crítica, em vez de depender do buffer de atualização automática.
Persistência de tokens
Todas as classes de autenticação oferecem suporte a export_tokens() e import_tokens() para persistir o estado do token entre reinicializações. Para fluxos Web App e SPA, isso é especialmente importante, pois os tokens de acesso e de atualização ficam na memória por padrão. Se o aplicativo reiniciar, os usuários precisarão se autenticar novamente, a menos que você persista esses tokens. Para servidor para servidor, a persistência é opcional (as credenciais de cliente sempre podem emitir um novo token), mas importar um token em cache evita uma ida e volta extra na inicialização.
Exportar e importar
Persistência automática com on_token_refreshed
Para persistir tokens automaticamente sempre que forem atualizados, use o callback on_token_refreshed:
O callback recebe a mesma forma de dict que export_tokens() e é executado após cada atualização de token bem-sucedida.Para as classes async, on_token_refreshed pode ser uma função regular ou uma função assíncrona. Ambas são compatíveis.
Revogação de tokens
Para encerrar a sessão de um usuário e invalidar seus tokens com o Adobe IMS:
Isso faz uma solicitação de revogação de melhor esforço ao Adobe IMS para o token de acesso e o token de atualização, e depois limpa todo o estado local do token. Após a revogação, o usuário precisará se autenticar novamente.
Para as classes assíncronas, use await auth.revoke().
Tratamento de erros
Todos os erros de autenticação herdam de FrameioAuthError, portanto você pode capturá-los de forma ampla ou tratar casos específicos:
Referência de erros
Tratamento de tokens de atualização expirados em produção
Para fluxos Web App e SPA, o token de atualização acabará expirando.Quando isso acontece, get_token gerará TokenExpiredError. Você deve capturar isso e redirecionar o usuário pelo fluxo de autorização novamente.
Referência de configuração
Todas as classes de auth aceitam estes parâmetros opcionais:
Referência de parâmetros
Ambientes de preparo
Aponte para uma instância de preparo do Adobe IMS substituindo ims_base_url. O SDK também exporta DEFAULT_IMS_BASE_URL (https://ims-na1.adobelogin.com) se precisar referenciar o valor de produção programaticamente.
Cliente HTTP personalizado
Para suporte a proxy ou configuração TLS personalizada:
Segurança de threads
As classes de autenticação sincronizadas são totalmente thread-safe. Quando várias threads chamam get_token simultaneamente e uma atualização é necessária, apenas uma thread executa a atualização. As outras aguardam e recebem o mesmo resultado. Nenhum bloqueio externo é necessário. As classes assíncronas fornecem a mesma garantia usando `asyncio.Lock“ seguro para corrotinas simultâneas dentro de um único loop de eventos.