Pular para o conteúdo
Documentação · Espaços de trabalho, emissores e tokens

Conceitos

Algumas ideias explicam quase tudo no Usher: onde as coisas ficam, quem emite os tokens, onde as pessoas iniciam sessão e quanto tempo dura cada token.

Espaços de trabalho, projetos e ambientes

  • Um espaço de trabalho é a sua equipe ou empresa no Usher Console. Os membros e o log de auditoria pertencem a ele.
  • Um projeto é um produto: o seu app web ou um portal de parceiros. Um espaço de trabalho pode ter vários.
  • Um ambiente é uma cópia em execução de um projeto, normalmente desenvolvimento e produção. É nos ambientes que ficam as pessoas, as aplicações, as chaves e as configurações.

Espaço de trabalho · Acme Ltda.

Projeto · Web

  • development · wise-otter-42
  • production · acme

Projeto · Portal de parceiros

  • development · calm-heron-17
  • production · acme-partners
Cada ambiente é o seu próprio emissor, com os próprios usuários, chaves e Lobby.

Os ambientes não compartilham nada que importe. Cada um tem o próprio schema Postgres, as próprias chaves de assinatura e os próprios segredos, selados com a sua própria chave de dados. Uma pessoa que cria uma conta em desenvolvimento não existe em produção, e um token de um nunca pode ser verificado com as chaves do outro.

Um administrador do espaço de trabalho pode excluir um projeto no fim da Visão geral do projeto, depois de digitar o nome dele. Todos os ambientes do projeto somem de uma vez: as pessoas, aplicações, chaves e configurações de cada um, e todas as sessões e tokens que emitiram. Os endereços param de responder e nunca são entregues de novo, então um app que ainda confie em um deles não pode ser enganado pelo projeto de outra pessoa.

Emissores

Cada ambiente é o seu próprio emissor OpenID Connect, em um host próprio no domínio dos locatários:

Emissor
https://<handle>.usherid.com
  • Os ambientes de produção têm um handle que você escolhe: de 3 a 32 letras minúsculas, dígitos e hifens não consecutivos, como o nome da sua empresa. Um handle já usado nunca é entregue de novo.
  • Os ambientes de desenvolvimento recebem um handle aleatório, como wise-otter-42, que ninguém vai confundir com uma marca.

O emissor é definido quando o ambiente é criado e não muda mais, porque todo token que ele assina o identifica em iss, e todo app que confia nele verifica esse valor.

O domínio dos locatários é um domínio registrável diferente do domínio do próprio Usher (usheridentity.com), então as páginas de início de sessão de um cliente nunca ficam no mesmo site que o Usher Console, e os cookies são restritos ao host: um navegador envia os cookies de um ambiente só para esse ambiente.

O Lobby

O Lobby é a página de início de sessão que cada ambiente hospeda no seu emissor. O seu app envia as pessoas para lá; o Lobby inicia a sessão delas e as manda de volta.

  • Ele sempre mostra o nome do app para onde a pessoa vai, no selo “Continuando para”.
  • Ele oferece só os métodos que o ambiente permite: chaves-senha, códigos por e-mail, links mágicos, contas sociais (Google, GitHub, Microsoft, Apple) e senhas.
  • Ele pode exigir um segundo fator: um app de autenticação (com códigos de backup) ou uma chave-senha.
  • Ele pode ser aberto a qualquer pessoa ou limitado a uma lista de convidados com endereços e domínios.

Ele tem a mesma aparência seja qual for o produto que enviou a pessoa. Isso é proposital: as pessoas aprendem como é um Lobby de verdade e percebem quando uma página não é um.

Contas Usher

A maioria dos ambientes tem os próprios usuários. As contas Usher são diferentes: uma só conta com a qual a pessoa inicia sessão em todos os apps que oferecem Continuar com o Usher. Cada pessoa gerencia a sua em account.usheridentity.com.

Tokens e validade

TokenPadrãoPode ser definido comoPara que serve
Código de autorização5 minutosFixoTrocado uma vez por tokens. De uso único.
Token de ID10 minutosDe 1 a 60 minutosInforma ao seu app quem iniciou sessão. Não serve para chamar APIs.
Token de acesso10 minutosDe 1 a 60 minutosEnviado à sua API, que o verifica.
Token de atualização30 diasDe 1 a 90 diasObtém novos tokens de acesso. Passa por rotação a cada uso. Exige offline_access.
Token de acesso de máquina15 minutosDe 1 a 60 minutosPara client_credentials: servidores sem uma pessoa por trás.
Código por e-mail, link mágico10 minutosFixoUm único início de sessão. Um código permite três tentativas.

As sessões no Lobby também têm validade: uma sessão termina depois de 7 dias sem uso (de 1 a 30) e depois de 30 dias no total (de 1 a 90). Alterar algo sensível, como um endereço de e-mail, exige um início de sessão feito nos últimos 10 minutos.

Chaves de assinatura

Os tokens são assinados com RS256 por padrão; um ambiente pode usar ES256 ou EdDSA em vez disso. As chaves públicas são publicadas no jwks_uri do ambiente, então as suas bibliotecas as buscam lá e pegam as novas quando as chaves passam por rotação.

Escopos

EscopoO que o seu app recebe
openidObrigatório. Um token de ID com o sub da pessoa.
profileO nome e a foto da pessoa.
emailO endereço de e-mail da pessoa e se ele foi verificado.
offline_accessUm token de atualização, para que a sessão continue iniciada.