O OpenID Connect (OIDC) é um mecanismo popular de autenticação de clientes suportado pelo Couchbase Sync Gateway.

Nesse contexto, clientes podem ser clientes do Couchbase Lite que sincronizam dados com o Sync Gateway pela Internet usando o protocolo de replicação baseado em websockets ou podem ser front-end da Web ou aplicativos móveis acessar o Sync Gateway por meio do ponto de extremidade REST público.

Na semana passada, discutimos os fundamentos dos fluxos OIDC e OAuth2. Na postagem do blog desta semana, apresentarei a autenticação de cliente baseada em fluxo implícito do OIDC no contexto de Gateway de sincronização do Couchbase replicação. Esta postagem pressupõe familiaridade com OIDC e OAuth2 para autenticação e autorização. Portanto, se você não estiver familiarizado com os fluxos ou precisar de uma atualização, leia a postagem do blog da semana passada.

Configuração do OIDC do gateway de sincronização do Couchbase

 

Por banco de dados, O Couchbase Sync Gateway deve ser configurado para autenticação OIDC.

Aqui está um exemplo básico configuração para Implicit Flow. (Consulte as páginas da documentação oficial do uma listagem completa de todas as opções de configuração.)

 

    • emissor é o URL de autenticação correspondente ao provedor de identidade OIDC
    • id_cliente é gerado como parte do processo de registro do aplicativo com o provedor OIDC. O cliente aqui se refere ao Couchbase Lite aplicativo ou aplicativo da Web. Observe que id_cliente não corresponde ao usuário final do aplicativo, que é tecnicamente o "Proprietário do recurso".
    • O registro se definido como verdadeiroO usuário será criado automaticamente no Sync Gateway após a validação bem-sucedida do token de ID.
    • nome de usuário_reclamação corresponde ao Reivindicação da JWT a ser usado como o nome de usuário do Sync Gateway. Por padrão, o nome de usuário do Sync Gateway assumiria o formato emissor+sujeito onde emissor refere-se ao nome de usuário prefixo. O prefixo o valor padrão é o emissor e pode ser configurado para usar um valor de reivindicação diferente por meio da opção de configuração user_prefix.

 

Descoberta de OIDC do gateway de sincronização do Couchbase

 

Na inicialização, o Sync Gateway se conecta ao ponto de extremidade de descoberta associado ao provedor/emissor OIDC configurado para obter metadados relevantes do provedor. O metadados inclui informações relevantes necessárias para a validação do token, como chaves públicas do emissor, algoritmos de criptografia compatíveis usados para codificar as reivindicações no token de ID etc.

O ponto de extremidade de descoberta corresponde a um URL de descoberta bem conhecido associado ao emissor. Se necessário, é possível substituir isso por meio do parâmetro Opção de configuração discovery_url do Sync Gateway.

Fluxo implícito do OIDC para autenticação de cliente

 

Esse fluxo é baseado no fluxo implícito padrão do OIDC discutido no blog básico do OIDC. É mais simples do que a abordagem alternativa baseada em fluxo do Código de Autorização e geralmente é a abordagem preferida para a autenticação do cliente OIDC do Sync Gateway.

Fluxo implícito usando token de portador

 

Nesse fluxo, os clientes do Couchbase Lite incorporam o token de ID recuperado do provedor OIDC (OP) como o token do portador no cabeçalho Authorization durante a inicialização da replicação.


OpenID Connect Implicit Flow using session ID

  1. Quando um usuário faz login no aplicativo cliente Couchbase Lite, o cliente inicia o fluxo implícito do OIDC com o provedor OIDC para recuperar o token de ID. Isso está de acordo com os procedimentos de fluxo padrão do OIDC descrito no blog básico do OIDC.
  2. O aplicativo cliente inicia uma replicação usando o token de ID como o token do portador no cabeçalho de autorização HTTP.
  3. O Sync Gateway valida o token de ID localmente. Após a validação bem-sucedida do token, um UserCtx é criado.
    • Os metadados recuperados do URL de descoberta do provedor OIDC durante a inicialização são usados para validar o token no "modo off-line".
    • Se esta for a primeira vez que o usuário está se autenticando no Sync Gateway e se não existir um usuário correspondente no servidor, o Sync Gateway criará automaticamente um usuário se a opção de configuração "register" estiver definida como true.
      • Observação: O usuário que é criado não está associado a nenhuma concessão de acesso, como canais ou funções. Esse registro automático só funcionaria para usuários públicos sem concessões de acesso específicas do usuário. Discutiremos um fluxo mais adiante neste post que descreve como criar usuários com concessões de acesso específicas do usuário.
  4. Após a inicialização bem-sucedida, a replicação prossegue como de costume e as alterações de documentos no aplicativo cliente e no Sync Gateway são sincronizadas.
    • Se o usuário for excluído durante uma replicação ativa, a replicação será encerrada.
    • Se as concessões de acesso associadas ao usuário tiverem sido alteradas, os documentos que forem afetados pelas concessões de acesso atualizadas não serão replicados. Por exemplo, se um usuário perder o acesso a um canal, os documentos desse canal não serão extraídos.

 

Fluxo implícito usando o ID da sessão

 

Nesse fluxo, os clientes do Couchbase Lite incorporam o ID da sessão gerado pelo Sync Gateway após a validação bem-sucedida do token de ID como um cookie de sessão durante a inicialização da replicação.

OpenID Connect Implicit Flow using a bearer token


  1. Quando um usuário faz login no aplicativo cliente Couchbase Lite, o cliente inicia o fluxo OIDC Implicit com o provedor OIDC para recuperar o token de ID. Isso está de acordo com o padrão Procedimentos de fluxo do OIDC descritos no blog básico do OIDC.
  2. O aplicativo cliente cria uma sessão usando o ponto de extremidade REST da sessão. O token de ID é definido como o token do portador no cabeçalho de autorização HTTP.
  3. O Sync Gateway valida o token de ID localmente. Após a validação bem-sucedida do token, um UserCtx é criado.
    • Os metadados recuperados do URL de descoberta do provedor OIDC durante a inicialização são usados para validar o token no "modo off-line".
    • Se esta for a primeira vez que o usuário estiver se autenticando no Sync Gateway e se não existir um usuário correspondente no servidor, o Sync Gateway criará automaticamente um usuário se o registro A opção de configuração é definida como verdadeiro.
      • Observação: O usuário que é criado não está associado a nenhuma concessão de acesso, como canais ou funções. Esse registro automático funcionaria para usuários públicos sem concessões de acesso específicas do usuário. Discutiremos um fluxo mais adiante neste post que descreve como criar usuários com concessões de acesso específicas do usuário.
    • Uma sessão é criada para o usuário com um tempo limite de sessão inativa de 24 horas.
      • Observação: A expiração da sessão não está relacionada à expiração do token de ID. Mais informações sobre expirações de sessão na seção de perguntas frequentes abaixo.
  4. O ID da sessão é retornado ao cliente.
  5. O aplicativo cliente inicia uma replicação definindo o ID da sessão como o cookie da sessão usando o SessionAuthenticator como discutido nos documentos.
  6. O Sync Gateway verifica a validade da sessão para determinar se ela foi excluída ou expirou.
    • Se a sessão estiver ativa, ela será estendida automaticamente para 24 horas se o tempo limite da sessão ociosa for de 10%.
  7. Após a inicialização bem-sucedida, a replicação prossegue como de costume e as alterações de documentos no aplicativo cliente e no Sync Gateway são sincronizadas.
    • Se o usuário for excluído durante uma replicação ativa, a replicação será encerrada.
    • Se as concessões de acesso associadas ao usuário tiverem sido alteradas, os documentos que forem afetados pelas concessões de acesso atualizadas não serão replicados. Por exemplo, se um usuário perder o acesso a um canal, os documentos desse canal não serão extraídos.

 

Associação de concessões de acesso a usuários autenticados

 

Gateway de sincronização canais e funções são dois elementos-chave do mecanismo de controle de acesso do Sync Gateway. Eles definem o concessões de acesso associado a um usuário, determinando o conjunto de documentos aos quais o usuário tem acesso de leitura/gravação.

Há algumas opções para atribuir concessões de acesso a um usuário:

    • Atribuição dinâmica de usuários a canais ou funções pela função de sincronização com o acesso() ou APIs de role() usando um documento de concessão de acesso. Um documento de concessão de acesso especifica os canais ou funções aos quais um usuário deve ser atribuído.
    • Atribuição estática de concessões a usuários por meio do administrador API REST do usuário.

Como você viu nos fluxos de autenticação do OIDC anteriores, o Sync Gateway pode ser configurado para criar automaticamente o usuário autenticado no Sync Gateway após a autenticação bem-sucedida. No entanto, o usuário criado não está associado a nenhuma concessão de acesso. Isso funciona para um usuário público com acesso ao canal público.

Mas e se você quisesse atribuir concessões de acesso específicas ao usuário?

Normalmente, essa tarefa é realizada por meio de um servidor de aplicativos back-end que seria responsável pela criação ou atualização do usuário. O Sync Gateway é responsável apenas pela autenticação OIDC.

Aqui está um fluxo típico:

Associating access grants to authenticated users in Couchbase Sync Gateway

  1. Um processo de backend ou servidor de aplicativos é responsável pelo registro de usuários no provedor OIDC.
  2. Após o registro, o servidor de aplicativos cria o usuário correspondente no Sync Gateway por meio do _usuário REST API ou adicionando um documento de concessão de acesso adequado.
  3. Na próxima vez que o usuário fizer login no aplicativo, a autenticação OIDC continuará usando os procedimentos de fluxo implícito descritos anteriormente.
  4. Independentemente do tipo de fluxo OIDC, depois que o token de ID é validado, o Sync Gateway não cria um usuário porque ele já existe.
  5. A replicação prossegue normalmente usando o usuário autenticado.
  6. Se um usuário for atualizado no provedor OIDC, o servidor de aplicativos atualizará o usuário correspondente no Sync Gateway por meio do _usuário REST API ou atualizando o documento de concessão de acesso.
    • Se um usuário for excluído durante uma replicação ativa, a replicação será encerrada.
    • Se as concessões de acesso associadas ao usuário tiverem sido alteradas, os documentos que forem afetados pelas concessões de acesso atualizadas não serão replicados. Por exemplo, se um usuário perder o acesso a um canal, os documentos desse canal não serão extraídos.

 

Perguntas frequentes (FAQ)

 

Como a expiração do token de ID é tratada com a replicação?

A validação do token de ID é feita no momento da autenticação, quando uma replicação é iniciada. Um token que expira durante uma replicação ativa não afetará a replicação em andamento. No entanto, se o usuário associado à replicação for excluído, a replicação será encerrada. Da mesma forma, se houver alterações nas concessões de acesso associadas ao usuário, elas entrarão em vigor imediatamente na replicação em andamento.

A expiração da sessão encerraria uma replicação contínua?

Não. A validação da sessão é feita no momento da autenticação, quando uma replicação é iniciada. Se uma sessão expirar durante uma replicação ativa, isso não afetará a replicação em andamento. No entanto, se o usuário associado à replicação for excluído, a replicação será encerrada. Da mesma forma, se houver alterações nas concessões de acesso associadas ao usuário, elas entrarão em vigor imediatamente na replicação em andamento.

A exclusão das sessões antes de sua expiração encerraria a replicação?

Não. A validação da sessão é feita somente no momento da autenticação, quando uma replicação é iniciada. Portanto, se uma sessão expirar durante uma replicação ativa, isso não afetará a replicação em andamento. No entanto, se o usuário associado à replicação for excluído, a replicação será encerrada. Da mesma forma, se houver alterações nas concessões de acesso associadas ao usuário, elas entrarão em vigor imediatamente na replicação em andamento.

É possível usar declarações JWT para atribuir concessões de canal?

Isso não é possível no momento.

Quais provedores de OIDC vocês apoiam?

Apoiamos qualquer provedor que esteja em conformidade com OIDC e Token da web JSON (JWT) padrões.

Mais recursos

 

Nesta postagem, descrevemos o suporte à autenticação do OpenID Connect (OIDC) no Couchbase Sync Gateway. Em uma próxima publicação, discutiremos a implementação do fluxo de código de autorização com o Sync Gateway.

Aqui estão alguns recursos adicionais:

 

Se você tiver dúvidas ou comentários, deixe um comentário abaixo ou envie um e-mail para priya.rajagopal@couchbase.com. O Fóruns do Couchbase são outro bom lugar para entrar em contato com perguntas.

 

Fique por dentro das demais postagens desta série sobre autenticação e autorização:

 

Autor

Postado por Priya Rajagopal, Diretora Sênior, Gerenciamento de Produtos

Priya Rajagopal é diretora sênior de gerenciamento de produtos da Couchbase, responsável pelas plataformas de desenvolvedor para a nuvem e a borda. Ela desenvolve software profissionalmente há mais de 20 anos em vários cargos técnicos e de liderança de produtos, com mais de 10 anos de foco em tecnologias móveis. Como delegada de padrões de IPTV da TISPAN, ela foi uma das principais colaboradoras das especificações de padrões de IPTV. Ela tem 22 patentes nas áreas de rede e segurança de plataforma.

Todas as publicações

Deixar uma resposta