O Couchbase Sync Gateway oferece suporte a Autenticação de cliente baseada em OpenID Connect ou OIDC.

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 que acessam o Sync Gateway por meio do Ponto de extremidade REST público.

Na primeira postagem do blog desta série, discutimos os fundamentos dos fluxos de autenticação e autorização do OIDC e do OAuth2 E na postagem do blog da semana passada, aprendemos mais detalhadamente sobre Autenticação de cliente Sync Gateway baseada em fluxo implícito OIDC.

Nesta postagem, apresentarei a você Código de autorização OIDC baseado em fluxo autenticação de cliente no contexto da replicação do Couchbase Sync Gateway.

Esta postagem pressupõe familiaridade com os fluxos OIDC e OAuth2 para autenticação e autorização. Se você não estiver familiarizado com os fluxos ou precisar de uma atualização, consulte as postagens anteriores do blog relacionadas acima.

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

O Gateway de sincronização do Couchbase deve ser configurado para autenticação OIDC por banco de dados.

Abaixo está uma configuração básica do OIDC para o Código de Autorização. Consulte a documentação oficial do Couchbase para obter informações sobre uma listagem completa de todas as opções de configuração do OIDC.

    • 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 Web. Observe que o id_cliente não corresponde ao usuário final do aplicativo, que é tecnicamente o proprietário do recurso.
    • chave_de_validação corresponde ao segredo_do_cliente e deve ser gerado como parte do processo de registro do aplicativo com o provedor de OIDC.
    • callback_url é a URL a ser redirecionada para o Sync Gateway depois que o cliente obtiver o token de identidade (token de ID).
    • 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 à reivindicação JWT a ser usada 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 valor do prefixo tem como padrão a reivindicação do emissor e pode ser configurado para usar um valor de reivindicação diferente por meio do prefixo_do_usuário opção de configuração.
    • desativar_sessãose definido como verdadeiropode ser usado para substituir a criação automática de sessão pelo Sync Gateway após a autenticação bem-sucedida.

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

Na inicialização, o Sync Gateway se conecta a o ponto de extremidade de descoberta associado ao provedor/emissor de OIDC configurado para buscar metadados relevantes do provedor. O Os metadados incluem 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, você pode substituir a URL por meio de Opção de configuração discovery_url do Sync Gateway.

Fluxo do código de autorização OIDC para autenticação de cliente

Esse fluxo é baseado no fluxo de código de autorização OIDC padrão discutido em O blog básico do OIDC (parte um da série).

Autenticação

An example of user authentication using OIDC and Couchbase Sync Gateway

  1. Quando um usuário faz login no aplicativo cliente Couchbase Lite, o cliente invoca a função Ponto de extremidade REST do _oidc no Sync Gateway para iniciar o fluxo do código de autenticação OIDC.
  2. O Sync Gateway redireciona o aplicativo cliente para o URL do provedor OIDC.
  3. O cliente inicia o fluxo do código de autorização com o provedor do OIDC para recuperar o código de autorização. Isso está de acordo com os procedimentos de fluxo padrão do OIDC descritos em O blog básico do OIDC.
  4. O cliente é redirecionado para o Sync Gateway com o código de autorização. O URL de redirecionamento corresponde a o ponto de extremidade REST de retorno de chamada do OIDC.
  5. O aplicativo cliente invoca o endpoint REST de retorno de chamada do OIDC com o código de autorização.
  6. O Sync Gateway troca o código do token de ID, do token de atualização e do token de acesso enviando uma solicitação adequada ao provedor do OIDC. A solicitação inclui o id_cliente e segredo_do_cliente que foram configurados no Sync Gateway. Isso permite que o provedor de OIDC valide que somente clientes confiáveis podem recuperar os tokens.
  7. 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çõesPortanto, 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. A sessão é criada SOMENTE SE o desativar_sessão é definido como falso.
  8. O ID da sessão e os tokens de atualização são enviados de volta ao aplicativo cliente.
  9. O aplicativo cliente inicia uma replicação ao definindo o ID da sessão como o cookie da sessão usando o SessionAuthenticator.
  10. 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%.
  11. 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. Assim, por exemplo, se um usuário perder o acesso a um canal, os documentos desse canal não serão extraídos.

Atualização de token

Uma das vantagens do fluxo do código de autorização é que, além do token de ID, um token de atualização também é retornado ao aplicativo cliente. O aplicativo cliente pode usar o token de atualização para solicitar automaticamente um novo código de autorização sem exigir que o usuário final se autentique novamente com suas credenciais de login.

An example of user token refresh using OpenID Connect authorization and Couchbase

  1. Quando o aplicativo cliente deseja atualizar o token, ele faz uma solicitação ao endpoint REST de atualização do OIDC com o token de atualização.
  2. O Sync Gateway troca o token de atualização pelo token de ID e pelo token de acesso atualizados, enviando uma solicitação adequada ao provedor de OIDC. A solicitação inclui o id_cliente e segredo_do_cliente que foram configurados no Sync Gateway. Isso permite que o provedor OIDC valide que somente clientes confiáveis podem recuperar os tokens.
  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".
    • Uma nova sessão é criada para o usuário com um tempo limite de sessão inativa de 24 horas. A sessão é criada SOMENTE SE o desativar_sessão é definido como falso.
  4. O ID da sessão e os tokens de ID são enviados de volta ao aplicativo cliente.
  5. O aplicativo cliente inicia uma replicação usando o ID da sessão como o cookie da sessão, seguindo as mesmas etapas do fluxo anterior.

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 e 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 função() APIs usando um documento de concessão de acesso que 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 anteriores, o Couchbase 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:

User-specific access grants using OIDC authorization and 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 um usuário correspondente no Sync Gateway por meio do API REST do usuário 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 de código de autorização descritos anteriormente.
  4. Independentemente do tipo de fluxo OIDC, uma vez que o token de ID é validado pelo Sync Gateway, 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 API REST do usuário 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)

O que é melhor: fluxo implícito ou fluxo de código de autorização?

Do meu ponto de vista, não há um fluxo preferido. O fluxo implícito é simples e geralmente é o preferido pela maioria dos nossos usuários. Como os aplicativos móveis têm um armazenamento seguro, a ID e os tokens de acesso podem ser armazenados com segurança no repositório de chaves local do dispositivo. Você pode saber mais nesta postagem do blog sobre Como aproveitar o fluxo implícito do OIDC para autenticação do Sync Gateway.

A vantagem do fluxo do código de autorização é que ele oferece uma segurança um pouco melhor. Isso ocorre porque os tokens são concedidos ao Sync Gateway em troca do código de autorização somente quando o provedor OIDC recebe um código de autorização válido. id_cliente e segredo_do_cliente. Isso garante que somente os clientes autenticados recebam os tokens. Além disso, os tokens de atualização permitem a atualização das sessões de autenticação sem exigir que o usuário final insira suas credenciais todas as vezes.

Mais recursos

Nesta postagem, descrevemos o suporte à autenticação OIDC no Sync Gateway. Aqui estão alguns recursos adicionais que você pode querer conferir:

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.

Agradecimentos

Gostaria de agradecer ao arquiteto do Sync Gateway Adam Fraser por sua contribuição para esta postagem do blog.
 

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