Credenciais
17 min
objetivo credenciais são identidades de acesso máquina a máquina (m2m) que permitem ao back end do seu sistema integrar se programaticamente com a fluid via sdk, embedded ou api direta, sem depender de sessões de usuário cada credencial gera um client id e um client secret únicos, usados para emitir tokens de acesso temporários com validade de uma hora o fluxo segue o padrão oauth2 client credentials grant credenciais e api keys são complementares, não excludentes use api keys para registrar webhooks em sistemas externos, onde a chave precisa ser permanente para que os disparos continuem válidos use credenciais para tudo que envolve sdk, embedded e provisionamento de usuários por que usar credenciais? antes das credenciais, a única forma de autenticar chamadas externas na fluid era via api keys docid\ u9rzulsup oxxcqf5mu 8 esse modelo funciona bem para integrações passivas, mas não é adequado para cenários onde o sistema do cliente precisa agir em nome de usuários específicos, provisionar workspaces dinamicamente ou embutir o canvas da fluid dentro do próprio produto (embedded) aspecto api key credencial m2m validade permanente até revogar token expira em 1 hora caso de uso ideal webhooks, disparos passivos sdk, embedded, provisionamento escopo de usuário sem escopo de usuário emite tokens por usuário ou customer secret em trânsito presente em cada requisição não trafega após a criação tipos de credencial tipo descrição sdk para integração via fluidapi sdk o back end emite bootstrap tokens que ativam flowkits e integrações para usuários finais do seu produto embedded para renderizar o canvas da fluid dentro do seu produto o token carrega a interface já autenticada para o usuário correto api para chamadas diretas à api administrativa da fluid útil para operações programáticas de gestão de workspaces, membros e configurações como funciona o fluxo m2m o fluxo completo envolve quatro etapas em sequência todo o processo deve ocorrer no back end do seu sistema — o client secret nunca deve ser exposto no front end o fluxo completo envolve quatro etapas em sequência todo o processo deve ocorrer no back end do seu sistema — o client secret nunca deve ser exposto no front end 1 credencial → 2 token m2m (1h) → 3 bootstrap token (por usuário) → 4 sessão do usuário final 1 credencial → 2 token m2m (1h) → 3 bootstrap token (por usuário) → 4 sessão do usuário final token m2m token m2m obtido trocando client id + client secret pelo endpoint oauth2 tem validade de obtido trocando client id + client secret pelo endpoint oauth2 tem validade de 1 hora e representa a identidade do sistema do cliente, não de um usuário específico use o apenas para chamar endpoints de provisionamento bootstrap token bootstrap token emitido a partir do token m2m, informando o emitido a partir do token m2m, informando o external id do usuário ou customer representa a identidade de um usuário final dentro de um workspace é esse token que o front end recebe para inicializar o sdk ou o embedded // exemplo com o fluidapi sdk (node js) import { fluidapi } from "fluidapi"; const client = new fluidapi({ clientid "fld cred dev sdk minha credencial", clientsecret process env fluid client secret, }); const bootstraptoken = await client token bootstrap({ external id "customer 123", external name "acme corp", workspace id "ws abc123", }); res json({ token bootstraptoken access token }); gerenciando credenciais no console acesse configurações → credenciais no menu lateral a listagem exibe todas as credenciais do workspace com nome, tipo, client id parcial, status e data de último uso criar uma credencial clique em criar credencial no canto superior direito e preencha os campos campo descrição obrigatório nome identificador legível use um nome que descreva o contexto de uso, como sdk producao ou embedded conta azul sim tipo sdk, embedded ou api define o contexto do token gerado sim descrição nota interna sobre o uso desta credencial visível apenas no painel não após confirmar, a fluid exibe o client id e o client secret gerados ação obrigatória esta é a única vez que o client secret será exibido copie e armazene em um local seguro — variável de ambiente ou secret manager — antes de fechar o modal se perdido, será necessário criar uma nova credencial marque a confirmação "confirmei que copiei o client secret e posso sair desta tela" para habilitar o botão de retorno o client id segue o padrão fld cred \[ambiente] \[tipo] \[nome] , por exemplo fld cred dev sdk review produto ele pode ser consultado a qualquer momento na listagem filtrar credenciais use o campo buscar por nome para localizar credenciais específicas clique em mostrar filtros para refinar por tipo (sdk, embed, api) ou por status (ativo, revogado) editar uma credencial clique no nome da credencial para abrir a tela de detalhes é possível editar nome e descrição o tipo e o client id são imutáveis após a criação o painel lateral resumo exibe status atual, data de criação e data da última atualização client secret perdido? o campo de client secret na tela de edição exibe apenas asteriscos — o valor não pode ser recuperado revogue a credencial atual e crie uma nova para substituí la status de uma credencial ativo — a credencial está operacional client id e secret podem emitir tokens m2m revogado — a credencial foi desativada novos tokens m2m não podem ser emitidos tokens já emitidos continuam válidos até expirar (máximo 1 hora) credenciais revogadas permanecem visíveis no histórico para fins de auditoria a revogação é imediata e irreversível antes de revogar uma credencial em uso em produção, certifique se de que a aplicação já aponta para uma credencial substituta para evitar interrupções testando com o workbench testando com o workbench a fluid disponibiliza o a fluid disponibiliza o fluid workbench para testar o fluxo de autenticação m2m sem escrever código use o durante o desenvolvimento para validar credenciais antes de integrar ao back end do seu produto o workbench é organizado em uma cadeia de quatro etapas o workbench é organizado em uma cadeia de quatro etapas client credentials client credentials — informe o client id e o client secret da credencial criada m2m token m2m token — execute generate m2m token o token é salvo automaticamente (validade visível de 59 min) bootstrap token bootstrap token — informe o external id e o external name do usuário e execute generate bootstrap token session session — troque o bootstrap token por uma sessão completa via users/s/token/exchange para validar o fluxo de ponta a ponta o workbench preserva client id e secret durante a sessão ao navegar entre abas, os valores permanecem preenchidos credenciais e customers quando um bootstrap token é emitido com um external id novo pela primeira vez, a fluid cria automaticamente um customer vinculado a esse identificador esse customer representa o cnpj ou organização do usuário final dentro do workspace do seu cliente a gestão de credenciais está, portanto, diretamente ligada à gestão de customers cada token emitido para um external id específico vincula aquele usuário a um customer rastreável em gestão → customers consulte a página customers para entender o ciclo completo de provisionamento e gestão boas práticas nunca exponha o client secret no front end mantenha o exclusivamente no back end, em variáveis de ambiente ou secret managers use uma credencial por contexto separe por ambiente (desenvolvimento, homologação, produção) e por tipo de integração nomeie de forma descritiva prefira sdk producao conta azul a nomes genéricos como credencial 1 revogue o que não usa credenciais de testes ou de projetos encerrados devem ser revogadas para reduzir a superfície de ataque renove antes de revogar em produção, sempre crie e valide a credencial substituta antes de revogar a anterior monitore o campo "último uso" credenciais com data muito antiga ou marcadas como "não informado" podem indicar integrações inativas