> ## 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 de utilizadores: início de sessão, passkeys > Autentique utilizadores finais com a Didit: páginas alojadas, passkeys, códigos, login social e SSO, ligados à verificação de identidade. > [!WARNING] > > A Autenticação é nova. A Didit ativa o produto na sua aplicação. Até lá, todas as rotas de execução dessa aplicação devolvem `404`. Os pacotes do SDK de Autenticação ainda não estão publicados, por isso use o fluxo alojado e o contrato HTTP descritos nestas páginas. A Autenticação inicia sessão dos seus clientes **na sua aplicação**. É separada de iniciar sessão na consola da Didit ou de criar uma conta de programador 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 a Monitorização de transações. Iniciar sessão não aprova uma verificação nem autoriza um pagamento. O seu backend toma essas decisões a partir do resultado de cada produto. ## Como funciona Cada aplicação tem a sua própria origem de início de sessão e o seu próprio emissor de tokens. As aplicações de produção e de sandbox são separadas: têm origens, definições e identidades distintas. | Item | Valor | | - | - | | Origem predefinida | `https://.auth.didit.me` para uma aplicação de produção, `https://.sandbox.auth.didit.me` para uma aplicação de sandbox. A consola mostra a sua. Um domínio personalizado verificado pode substituí-la. | | Páginas alojadas | `/sign-in`, `/magic`, `/invite` e `/reset` nessa origem. | | API de execução | A mesma origem, por exemplo `POST {origin}/token/` e `GET {origin}/session/`. | | Emissor | A própria origem. A descoberta está em `{origin}/.well-known/openid-configuration`. | | Chave publicável | `pk_live_...` ou `pk_test_...`. Identifica a aplicação e não é um segredo. | O fluxo utiliza o código de autorização OAuth 2.0 com PKCE (apenas `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 alojada inicia sessão ou cria a conta da pessoa com os métodos que ativou, incluindo qualquer segundo fator obrigatório. 3. O navegador regressa ao seu `redirect_uri` com `code` e `state`. 4. A sua aplicação troca o código em `POST {origin}/token/` por um token de acesso, um token de ID e um token de atualização. Veja [tokens e JWKS](https://docs.didit.me/pt/authentication/tokens-and-jwks.md) para o contrato dos tokens e [métodos de início de sessão](https://docs.didit.me/pt/authentication/sign-in-methods.md) para cada método. ## Escolha a sua plataforma > [card] [JavaScript](https://docs.didit.me/pt/authentication/quickstarts/javascript.md) > > Início de sessão alojado, retorno, sessão e terminar sessão. > [card] [React](https://docs.didit.me/pt/authentication/quickstarts/react.md) > > Estado do cliente e vistas protegidas da aplicação. > [card] [Next.js](https://docs.didit.me/pt/authentication/quickstarts/nextjs.md) > > Sessões no servidor, rotas de retorno e cookies. > [card] [iOS](https://docs.didit.me/pt/authentication/quickstarts/ios.md) > > Navegador do sistema e armazenamento seguro de tokens. > [card] [Android](https://docs.didit.me/pt/authentication/quickstarts/android.md) > > Autorização no navegador e retornos da aplicação. > [card] [React Native](https://docs.didit.me/pt/authentication/quickstarts/react-native.md) > > Preparação do wrapper nativo de autenticação. > [card] [Flutter](https://docs.didit.me/pt/authentication/quickstarts/flutter.md) > > Preparação do wrapper nativo de autenticação. ## Prepare a sua aplicação 1. Peça à Didit para ativar a Autenticação na sua aplicação. Teste primeiro numa aplicação de sandbox. 2. Registe os seus [URLs de redirecionamento](#urls-de-redirecionamento) exatos (até 50) e os `allowed_origins` do navegador (até 50) que chamam a API de execução. 3. Ative os [métodos de início de sessão](https://docs.didit.me/pt/authentication/sign-in-methods.md) que quer oferecer. A Didit ID Wallet está sempre ativa. 4. Escolha as definições de sessão e de palavra-passe (ver abaixo). 5. Teste o registo, o início de sessão, a recuperação da palavra-passe, a MFA, a expiração da sessão e o encerramento de sessão antes de passar para produção. Uma chave de acesso pertence à sua origem. Se mais tarde ativar um domínio personalizado, as pessoas terão de registar novamente as suas chaves de acesso. ## URLs de redirecionamento A Didit só devolve uma pessoa a um endereço que tenha registado. Registe o seu na consola, em **Autenticação > Segurança e sessões > URLs de redirecionamento e origens permitidas**. O `redirect_uri` de um pedido de início de sessão tem de corresponder a um URL registado, carácter a carácter: esquema, host, porta, caminho e query. Uma porta diferente, uma barra final ou uma diferença de maiúsculas e minúsculas é outro endereço. | Aplicação | O que pode registar | | - | - | | Produção | URLs `https://` | | Sandbox | URLs `https://`, e URLs `http://` em `localhost`, `127.0.0.1` ou `[::1]` | Carateres universais, fragmentos, credenciais no URL e esquemas personalizados são rejeitados. Quando o endereço não está registado, a Didit nunca redireciona para ele. `{origin}/sign-in` responde com `400` e uma página que indica o que registar e onde, e `POST {origin}/authorize/` responde com `400 {"error": "invalid_redirect_uri"}`. ### Desenvolvimento local Teste na sua máquina com a sua aplicação de sandbox: 1. Registe o seu URL de retorno com a porta, por exemplo `http://localhost:3000/auth/callback`. 2. Se o código do navegador chamar a API de execução, por exemplo para trocar o código em `POST {origin}/token/`, adicione também a origem a **Origens permitidas**: `http://localhost:3000`, sem caminho e sem barra final. 3. Comece o fluxo de início de sessão 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 distintos, e cada porta também. Registe cada um que usar. As aplicações de produção nunca aceitam `http://`. Antes de passar para produção, registe o seu URL de retorno `https://` de produção na sua aplicação de produção. ## Definições da aplicação Gere estas definições na consola ou com uma sessão autorizada na consola que tenha `write:authentication`. | Definição | Valores | Predefinido | | - | - | - | | `session_lifetime` | `86400`, `604800`, `2592000`, `7776000` segundos | `2592000` (30 dias) | | `idle_timeout` | `1800`, `7200`, `86400`, `604800` segundos | `86400` (1 dia) | | `multiple_sessions` | `false` termina as outras sessões da pessoa a cada novo início de sessão | `true` | | `password_min_length` | `8`, `10`, `12`, `14` | `10` | | `revoke_on_password_change` | Termina todas as sessões após uma redefinição da palavra-passe | `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 a sua aplicação envia a pessoa após o fim de sessão | Vazio | | `mfa_policy` | `optional`, `everyone`, `organization_admins` | `organization_admins` | | `sign_in_ui` | `hosted` ou `own` | `hosted` | ## Manter uma pessoa em todos os produtos Cada identidade tem um valor `vendor_data`. É o `external_id` que forneceu ao [importar](https://docs.didit.me/pt/authentication/migration.md) a pessoa ou, caso contrário, o ID de identidade da Didit. 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 submeter transações. Assim, os eventos de autenticação ficam associados à mesma pessoa na consola, junto das respetivas verificações e transações. Consulte [eventos e webhooks](https://docs.didit.me/pt/authentication/events-and-webhooks.md). Obtenha o `vendor_data` no seu backend a partir de um token verificado, nunca a partir de um campo do navegador não validado. | Combinação de produtos | O que constrói | | - | - | | Autenticação | Iniciar sessão, validar sessões e terminar sessão. | | Verificação de identidade + Autenticação | Iniciar uma verificação após o início de sessão, quando a sua política o exigir, com o `vendor_data` do token. | | Monitorização de transações + Autenticação | Submeter transações com o `vendor_data` da pessoa com sessão iniciada. Os eventos de início de sessão chegam ao histórico e às regras da mesma pessoa. | | Os três | Um `vendor_data` por pessoa. Trate a decisão de cada produto separadamente. | Use o [prompt de integração partilhado](https://docs.didit.me/pt/integration/integration-prompt.md) para qualquer combinação. Leia [proteção contra bots](https://docs.didit.me/pt/authentication/bot-protection.md) para conhecer as políticas que são executadas no início de sessão. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.