> ## Documentation Index > Fetch the complete documentation index at: https://docs.didit.me/llms.txt > Use this file to discover all available pages before exploring further. # Autenticação: login de usuário final, passkeys e sessões > Login de usuários finais na Didit: páginas hospedadas, passkeys, códigos, social e SSO, ligado à verificação de identidade e ao monitoramento. > [!WARNING] > > A Autenticação é nova. A Didit ativa o produto para a sua aplicação. Até lá, todas as rotas de runtime dessa aplicação retornam `404`. Os pacotes do SDK de Autenticação ainda não foram publicados, então use o fluxo hospedado e o contrato HTTP destas páginas. A Autenticação permite que seus clientes façam login na **sua aplicação**. Ela é separada do login no console da Didit e da criação de uma conta de desenvolvedor na Didit. Também é separada da verificação da identidade de uma pessoa. Use a Autenticação sozinha ou combine-a com a Verificação de identidade e o Monitoramento de transações. Fazer login não aprova uma verificação nem autoriza um pagamento. O seu backend toma essas decisões com base no resultado de cada produto. ## Como funciona Cada aplicação tem a sua própria origem de login e o seu próprio emissor de tokens. Aplicações de produção e de sandbox são separadas: elas têm origens, configurações e identidades separadas. | Item | Valor | | - | - | | Origem padrão | `https://.auth.didit.me` para uma aplicação de produção, `https://.sandbox.auth.didit.me` para uma aplicação de sandbox. O console mostra a sua. Um domínio personalizado verificado pode substituí-la. | | Páginas hospedadas | `/sign-in`, `/magic`, `/invite` e `/reset` nessa origem. | | API de runtime | A mesma origem, por exemplo `POST {origin}/token/` e `GET {origin}/session/`. | | Emissor | A própria origem. O discovery fica em `{origin}/.well-known/openid-configuration`. | | Chave publicável | `pk_live_...` ou `pk_test_...`. Ela identifica a aplicação e não é um segredo. | O fluxo é OAuth 2.0 authorization code com PKCE (somente `S256`): 1. A sua aplicação abre `{origin}/sign-in` com `redirect_uri`, `state`, `code_challenge` e `code_challenge_method=S256`. 2. A página hospedada permite que a pessoa faça login ou se cadastre com os métodos que você ativou, incluindo qualquer segundo fator exigido. 3. O navegador volta para o seu `redirect_uri` com `code` e `state`. 4. A sua aplicação troca o código no endpoint `POST {origin}/token/` por um access token, um ID token e um refresh token. Consulte [tokens e JWKS](https://docs.didit.me/pt-br/authentication/tokens-and-jwks.md) para o contrato de tokens e [métodos de login](https://docs.didit.me/pt-br/authentication/sign-in-methods.md) para cada método. ## Escolha a sua plataforma > [card] [JavaScript](https://docs.didit.me/pt-br/authentication/quickstarts/javascript.md) > > Login hospedado, callback, sessão e logout. > [card] [React](https://docs.didit.me/pt-br/authentication/quickstarts/react.md) > > Estado do cliente e telas protegidas da aplicação. > [card] [Next.js](https://docs.didit.me/pt-br/authentication/quickstarts/nextjs.md) > > Sessões no servidor, rotas de callback e cookies. > [card] [iOS](https://docs.didit.me/pt-br/authentication/quickstarts/ios.md) > > Navegador do sistema e armazenamento seguro de tokens. > [card] [Android](https://docs.didit.me/pt-br/authentication/quickstarts/android.md) > > Autorização pelo navegador e callbacks do app. > [card] [React Native](https://docs.didit.me/pt-br/authentication/quickstarts/react-native.md) > > Preparação do wrapper nativo de autenticação. > [card] [Flutter](https://docs.didit.me/pt-br/authentication/quickstarts/flutter.md) > > Preparação do wrapper nativo de autenticação. ## Prepare a sua aplicação 1. Peça à Didit que ative a Autenticação para a sua aplicação. Teste primeiro em uma aplicação de sandbox. 2. Registre as suas [URLs de redirecionamento](#urls-de-redirecionamento) exatas (até 50) e as `allowed_origins` do navegador (até 50) que chamam a API de runtime. 3. Ative os [métodos de login](https://docs.didit.me/pt-br/authentication/sign-in-methods.md) que você quer oferecer. A Didit ID Wallet está sempre ativa. 4. Escolha as suas configurações de sessão e de senha (veja abaixo). 5. Teste cadastro, login, recuperação de senha, MFA, expiração de sessão e logout antes de entrar em produção. Uma passkey pertence à sua origem. Se depois você ativar um domínio personalizado, as pessoas precisarão cadastrar as suas passkeys novamente. ## URLs de redirecionamento A Didit só redireciona uma pessoa para um endereço que você registrou. Registre os seus no console, em **Authentication > Security and sessions > Redirect URLs and allowed origins**. O `redirect_uri` de uma requisição de login deve corresponder a uma URL registrada caractere por caractere: esquema, host, porta, caminho e query. Uma porta diferente, uma barra final ou uma diferença entre maiúsculas e minúsculas é um endereço diferente. | Aplicação | O que você pode registrar | | - | - | | Produção | URLs `https://` | | Sandbox | URLs `https://` e URLs `http://` em `localhost`, `127.0.0.1` ou `[::1]` | Curingas, fragmentos, credenciais na URL e esquemas personalizados são rejeitados. Quando o endereço não está registrado, a Didit nunca redireciona para ele. `{origin}/sign-in` responde `400` com uma página que diz o que registrar e onde, e `POST {origin}/authorize/` responde `400 {"error": "invalid_redirect_uri"}`. ### Desenvolvimento local Teste na sua própria máquina com a sua aplicação de sandbox: 1. Registre o seu callback com a porta, por exemplo `http://localhost:3000/auth/callback`. 2. Se o código do navegador chamar a API de runtime, por exemplo para trocar o código em `POST {origin}/token/`, adicione a origem também em **Origens permitidas**: `http://localhost:3000`, sem caminho e sem barra final. 3. Inicie o login na sua origem de sandbox, `https://.sandbox.auth.didit.me`, com a sua chave `pk_test_...`. `localhost`, `127.0.0.1` e `[::1]` são endereços separados, assim como cada porta. Registre cada um que você usar. Aplicações de produção nunca aceitam `http://`. Antes de entrar em produção, registre o seu callback `https://` de produção na sua aplicação de produção. ## Configurações da aplicação Você gerencia essas configurações no console ou com uma sessão autorizada do console que tenha `write:authentication`. | Configuração | Valores | Padrão | | - | - | - | | `session_lifetime` | `86400`, `604800`, `2592000`, `7776000` segundos | `2592000` (30 dias) | | `idle_timeout` | `1800`, `7200`, `86400`, `604800` segundos | `86400` (1 dia) | | `multiple_sessions` | `false` desconecta a pessoa das outras sessões a cada novo login | `true` | | `password_min_length` | `8`, `10`, `12`, `14` | `10` | | `revoke_on_password_change` | Encerra todas as sessões após uma redefinição de senha | `true` | | `signup_policy` | `anyone`, `invited`, `allowed_domains` (com `allowed_email_domains`, até 100) | `anyone` | | `allow_subaddresses` | Aceita um `+` na parte local do e-mail | `false` | | `post_logout_redirect_uri` | Para onde sua aplicação envia a pessoa após o logout | Vazio | | `mfa_policy` | `optional`, `everyone`, `organization_admins` | `organization_admins` | | `sign_in_ui` | `hosted` ou `own` | `hosted` | ## Mantenha uma única pessoa entre os produtos Toda identidade tem um valor `vendor_data`. Ele é o `external_id` que você informou ao [importar](https://docs.didit.me/pt-br/authentication/migration.md) a pessoa ou, caso contrário, o ID de identidade da Didit. Ele aparece no token de acesso, no token de ID e em `GET session/`. Use o mesmo valor como `vendor_data` ao criar sessões de verificação e enviar transações. Assim, os eventos de autenticação ficam vinculados à mesma pessoa no console, junto com suas verificações e transações. Consulte [eventos e webhooks](https://docs.didit.me/pt-br/authentication/events-and-webhooks.md). Obtenha o `vendor_data` no seu backend a partir de um token verificado, nunca de um campo do navegador não validado. | Combinação de produtos | O que você constrói | | - | - | | Autenticação | Login, validação de sessões e logout. | | Verificação de identidade + Autenticação | Inicie uma verificação após o login quando sua política exigir, com o `vendor_data` do token. | | Monitoramento de transações + Autenticação | Envie transações usando o `vendor_data` da pessoa conectada. Os eventos de login são incluídos na linha do tempo da mesma pessoa e avaliados pelas regras dela. | | Os três | Um `vendor_data` por pessoa. Trate a decisão de cada produto separadamente. | Use o [prompt de integração compartilhado](https://docs.didit.me/pt-br/integration/integration-prompt.md) para qualquer combinação. Leia [proteção contra bots](https://docs.didit.me/pt-br/authentication/bot-protection.md) para conhecer as políticas aplicadas no login. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.