Fundamentos do OAuth 2.0 e do OIDC para autenticação e autorização [Parte 1 de 3]

Desenvolvedores e arquitetos simplesmente não é possível criar aplicativos modernos sem se deparar com problemas de autorização e autenticação.

OAuth 2.0 é um padrão do setor para "autorização delegada", que é a capacidade de fornecer a um aplicativo ou cliente acesso a dados ou recursos oferecidos por outro aplicativo ou serviço. O OAuth 2.0 concentra-se na autorização e não é prescritivo quanto à autenticação. Conexão OpenID (OIDC) adiciona uma camada de autenticação baseada em padrões sobre o OAuth 2.0.

Para colocar isso em contexto, O Couchbase Sync Gateway oferece suporte a várias formas de autenticação de cliente. Clientes podem ser clientes do Couchbase Lite que sincronizam os dados com o Sync Gateway pela Internet usando uma interface baseada em websocket. protocolo de replicaçãoou podem ser front-end da Web ou aplicativos móveis que acessam o Sync Gateway por meio do Ponto de extremidade REST público. Um dos mecanismos de autenticação de cliente mais populares do Couchbase Sync Gateway é o OIDC.

Nesta postagem, abordaremos os fundamentos do OAuth 2.0 e do OIDC para autenticação e autorização. Discutirei dois fluxos comuns, a saber, o Fluxo implícito e o Fluxo do código de autorização. Espera-se que uma compreensão básica dos fluxos forneça a você informações suficientes para entender como usar a autenticação baseada em OIDC no contexto da autenticação do cliente do Sync Gateway. Mais informações sobre isso em uma futura postagem no blog, portanto, fique atento!

Para entender o OIDC, primeiro precisamos entender o OAuth 2.0. Isso porque, como uma estrutura de autenticação, o OIDC foi desenvolvido com base no OAuth 2.0.

Uma cartilha do OAuth 2.0

OAuth 2.0 é um padrão do setor para autorização delegada, e há uma série de Provedores OAuth no mercado.

Por exemplo, considere o botão "Fazer login com o Facebook" que aciona vários aplicativos da Web e móveis. Ele é implementado usando o OAuth 2.0.

Aqui está um simplificado visão do que acontece nos bastidores. Descrevo a seguir o que é chamado de Fluxo do código de autorização. Há também uma alternativa, o "fluxo implícito", que é mais comum quando usado no contexto do OIDC.

Pré-requisitos

Primeiro, o aplicativo/cliente deve ser registrado no servidor de autorização. O processo de registro resulta na geração de um id_cliente e um segredo_do_cliente que deve ser configurado no aplicativo/cliente que solicita a autenticação.

• • Quando o usuário (a.k.a., "Proprietário do recurso" no discurso do OAuth 2.0) clica no botão Faça login com o Facebook em seu aplicativo favorito, o aplicativo envia um Solicitação de autorização para o URL de login do servidor de autorização. Em nosso exemplo, o servidor de autorização é o Facebook. A Solicitação de autorização inclui vários parâmetros. Para ser breve, não estou incluindo a lista completa de parâmetros que pode ser encontrada em RFC6749. No mínimo, a solicitação deve incluir os seguintes parâmetros:
    • id_cliente que identifica de forma exclusiva o aplicativo para o servidor de autorização
    • tipo de resposta que deve ser especificado como código indicando que o cliente espera um Código de Autorização
    • request_uri que especifica o URL para o qual o Authorization Server deve redirecionar o controle após a autenticação
  • O servidor de autorização (Facebook) solicita que o usuário digite seu nome de usuário e senha e (opcionalmente) responda a várias perguntas de segurança necessárias para autenticar o usuário.
  • Depois de autenticado, o usuário recebe (opcionalmente) um "formulário de consentimento de recurso" que lista o conjunto de recursos do Facebook (como o perfil público do usuário) aos quais o aplicativo deseja ter acesso.
    • O conjunto de recursos apresentados no formulário de consentimento é especificado por meio de um escopo na Solicitação de Autorização inicial para o Servidor de Autorização.
  • Depois que o usuário autoriza o acesso aos recursos solicitados, ele é redirecionado de volta ao aplicativo com um Código de autorização.
    • O URL para o qual o servidor de autorização redireciona o usuário é especificado por meio do parâmetro redirect_uri que também está incluído na Solicitação de autorização inicial.
  • Em seguida, o aplicativo/cliente troca o código de autorização com o Authorization Server por um token de acesso (ou token de atualização), passando o id_cliente e segredo_do_cliente como parte da solicitação.
  • O aplicativo pode então acessar os recursos solicitados no Facebook usando o token de acesso.

Ficou confuso? Não se preocupe, pois voltaremos a falar sobre isso no contexto do OIDC.

O que é o OpenID Connect (OIDC)?

O principal objetivo do OAuth 2.0 é autorização delegada. Em outras palavras, como vimos anteriormente, o objetivo principal do OAuth 2.0 é conceder a um aplicativo acesso aos dados de propriedade de outro aplicativo.

O OAuth 2.0 não se concentra na autenticação e, portanto, qualquer implementação de autenticação que use o OAuth 2.0 não é padrão. É aí que entra o OpenID Connect (OIDC). O OIDC acrescenta uma camada de autenticação baseada em padrões sobre o OAuth 2.0.

O servidor de autorização nos fluxos do OAuth 2.0 agora assume a função de Servidor de identidade (ou Provedor OIDC). O protocolo subjacente é quase idêntico ao OAuth 2.0, exceto pelo fato de que o Identity Server fornece um Token de identidade (Token de identidade) para o aplicativo solicitante. O token de identidade é uma forma padrão de codificar as declarações sobre a autenticação do usuário. Falaremos mais sobre tokens de identidade posteriormente.

Descreverei aqui dois fluxos OIDC populares: Fluxo Implícito e Fluxo de Código de Autorização.

Pré-requisitos

Para ambos os fluxos, o aplicativo/cliente deve ser registrado no servidor de autorização. O processo de registro resulta na geração de um id_cliente e um segredo_do_cliente que deve ser configurado no aplicativo/cliente que solicita a autenticação.

Fluxo implícito do OIDC

A OIDC Fluxo implícito é o mais simples dos dois e é recomendado para uso na autenticação de cliente do Couchbase Lite com o Sync Gateway, sobre o qual falaremos mais em minha próxima postagem no blog.

Mais uma vez, usaremos Faça login com o Facebook como um exemplo para ilustrar o fluxo.

• • Quando o usuário clica no botão Faça login com o Facebook em seu aplicativo favorito, o aplicativo envia uma solicitação de autenticação para o URL de login do servidor de autorização ou servidor de identidade. Em nosso exemplo, o servidor de autorização é o Facebook.
    • A solicitação de autenticação inclui vários parâmetros. Por questões de brevidade, não estou incluindo a lista completa de todos os parâmetros que pode ser encontrado na especificação OIDC. No mínimo, a solicitação deve incluir os seguintes parâmetros:
      • id_cliente que identifica de forma exclusiva o aplicativo para o servidor de autorização
      • tipo de resposta que deve ser especificado como id_token indicando que o cliente espera um ID Token.
      • escopo que deve contêm o openid valor de escopo, além de uma lista opcional de recursos aos quais o aplicativo está solicitando acesso
      • request_uri que especifica o URL para o qual a autorização deve redirecionar o controle após a autenticação
  • O servidor de identidade (Facebook) solicita que o usuário digite seu nome de usuário e senha e (opcionalmente) responda a várias perguntas de segurança necessárias para autenticar o usuário.
  • Depois de autenticado, o usuário recebe (opcionalmente) um "formulário de consentimento de recurso" que lista o conjunto de recursos do Facebook (como o perfil público do usuário) aos quais o aplicativo deseja ter acesso.
    • O conjunto de recursos apresentados no formulário de consentimento é especificado por meio do parâmetro escopo que foi incluído na solicitação de autenticação inicial para o servidor de autorização.
  • Depois que o usuário autoriza o acesso aos recursos solicitados, ele é redirecionado de volta ao aplicativo com uma mensagem Token de identidade e, opcionalmente, um token de acesso
    • O URL para o qual o servidor de autenticação redireciona o usuário é especificado por meio do parâmetro redirect_uri que também está incluído na solicitação de autenticação inicial.
  • Em seguida, o aplicativo valida o token de identidade de acordo com os critérios especificados no Especificações da OIDC e recupera a identidade do usuário autenticado.

Fluxo do código de autorização OIDC

A OIDC Fluxo do código de autorização é muito semelhante ao fluxo do código de autorização do OAuth 2.0 descrito anteriormente.

Mais uma vez, usaremos Faça login com o Facebook como um exemplo para ilustrar o fluxo.

• • Quando o usuário clica no botão Faça login com o Facebook em seu aplicativo favorito, o aplicativo envia uma solicitação de autenticação para o URL de login do Authorization Server ou Identity Server. Em nosso exemplo, o servidor de autorização é o Facebook.
    • A solicitação de autenticação inclui vários parâmetros. Por motivos de brevidade, não estou incluindo a lista completa de todos os parâmetros que podem ser encontrados em Especificações da OIDC. No mínimo, a solicitação deve incluir os seguintes parâmetros:
      • id_cliente que identifica de forma exclusiva o aplicativo para o servidor de autorização
      • tipo de resposta que deve ser especificado como código indicando que o cliente espera um Código de Autorização.
      • escopo que deve contêm o openid valor de escopo, além de uma lista opcional de recursos aos quais o aplicativo está solicitando acesso
      • request_uri que especifica o URL para o qual a autorização deve redirecionar o controle após a autenticação
  • O servidor de identidade (Facebook) solicita que o usuário digite seu nome de usuário e senha e (opcionalmente) responda a várias perguntas de segurança necessárias para autenticar o usuário.
  • Depois de autenticado, o usuário recebe (opcionalmente) um "formulário de consentimento de recurso" que lista o conjunto de recursos do Facebook (como o perfil público do usuário) aos quais o aplicativo deseja ter acesso.
    • O conjunto de recursos apresentados no formulário de consentimento é especificado por meio do parâmetro escopo que também é incluído na solicitação de autenticação inicial para o servidor de autorização.
  • Depois que o usuário autoriza o acesso aos recursos solicitados, ele é redirecionado de volta ao aplicativo com uma mensagem Código de autorização
    • O URL para o qual o servidor de autorização redireciona o usuário é especificado por meio do parâmetro redirect_uri que também está incluído na Solicitação de autorização inicial.
  • Em seguida, o aplicativo/cliente troca o código de autorização com o Authorization Server por um Token de identidade e um token de acesso opaco, passando o id_cliente e segredo_do_cliente como parte da solicitação.
  • Em seguida, o aplicativo valida o token de identidade de acordo com os critérios especificados no Especificações da OIDC e recupera a identidade do usuário autenticado.

Token da Web JSON (JWT)

Um elemento-chave do OIDC é o token de identidade, que é um token de segurança que codifica as declarações de autenticação sobre um usuário em um formato padrão conhecido como Token da Web JSON (JWT). O JWT é assinado digitalmente.

Uma "reivindicação" é uma afirmação sobre o usuário. Aqui está um exemplo de um JWT que tem um conjunto típico de declarações.

• • submarino é o usuário ao qual o JWT se refere
  • iss é o emissor do JWT que também assina o JWT
  • aud é para quem o token se destina
  • iat é o registro de data e hora emitido
  • exp é o registro de data e hora da expiração
  • amr refere-se ao método de autenticação usado para emitir o token

Mais recursos

jwt.io é muito útil para decodificar e verificar um JWT.

O Playground do OIDC e do OAuth da Okta é um ótimo recurso para experimentar os fluxos sem implementá-los de fato.

O que vem a seguir

Nesta postagem, descrevemos os fundamentos dos fluxos do OpenID Connect (OIDC) e do OAuth 2.0. Na postagem da próxima semana, discutiremos a autenticação baseada em OIDC no contexto da autenticação do cliente do Sync Gateway. Fique ligado!

Se tiver dúvidas ou comentários, deixe um comentário abaixo ou envie-me um e-mail 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: