Noções básicas de autenticação e autorização

A autenticação e a autorização desempenham um papel importante na maioria dos conjuntos de aplicativos. Esta página fornece uma visão geral dos conceitos e terminologia. Será útil se você for novo no assunto ou se quiser uma atualização. Se você estiver confiante em seu entendimento geral, poderá se informar sobre como a autenticação e a autorização funcionam em CXone.

Quando os usuários fazem login em qualquer suíte de aplicativos, incluindo CXone , essas duas etapas geralmente ocorrem na ordem mostrada:

  • Autenticação — O usuário é quem eles afirmam ser?
  • Autorização — O usuário autenticado deve ter o acesso que solicitou?

Todos os usuários devem ser autenticados e autorizados antes que possam acessar CXone .

Os usuários podem ser pessoas ou aplicativos. Por exemplo, chatbots e assistentes virtuais geralmente são executados por meio de uma conta de usuário. A maioria dos conjuntos de aplicativos usa os mesmos processos para usuários humanos e virtuais. Nestas páginas de ajuda on-line sobre autenticação e autorização, usamos o termo usuário para aplicar a pessoas e aplicativos. Se houver diferenças, elas são claramente explicadas.

Do ponto de vista do usuário, ele está apenas fazendo login. A autenticação e a autorização acontecem nos bastidores para que o login seja bem-sucedido. No início de um login, os usuários não são autenticados. Isso significa que o sistema não conhece sua identidade. No final do login, eles são autenticados e autorizados. Isso significa que o sistema sabe quem são e qual acesso devem ter.

Um sistema faz o seguinte para autenticar e autorizar usuários:

  1. Determina qual processo de autenticação usar se houver suporte para mais de um. Muitos sistemas suportam vários métodos. Por exemplo, os sistemas podem identificar usuários com nome de usuário e senha, por meio de logon único ou por autenticação multifator (MFA) . Geralmente, os usuários escolhem em uma lista de opções de autenticação na página de login, mas os sistemas podem exigir um processo específico quando necessário.

  2. Reúne credenciais de autenticação (por exemplo, solicitando aos usuários seu nome de usuário e senha).

  3. Verifica as credenciais usando um provedor de identidade . Um provedor de identidade é um sistema separado que mantém informações sobre usuários e sua identidade, incluindo suas credenciais.

  4. Autoriza o indivíduo ou programa autenticado. Depois que os usuários são autenticados, o sistema usa um servidor de autorização para conceder acesso ao usuário. O sistema concede acesso ao usuário com base em sua função e permissões. O sistema concede ao usuário apenas acesso aos recursos que ele tem permissão para ver ou usar.

Terminologia relacionada à autenticação

Provedor de identidade

Os provedores de identidade (IdPs) são sistemas que estabelecem a identidade de um usuário. Eles podem ser:

  • Interno — Parte do sistema em que o usuário efetua login. Por exemplo, um usuário que faz login no Facebook usa o IdP do Facebook para se autenticar no aplicativo do Facebook.
  • Externo — Separado do sistema em que o usuário efetua login. Por exemplo, um usuário faz login em um aplicativo de smartphone usando a autenticação de IdP do Facebook.

Os IdPs podem ser hospedados ou baseados em nuvem. Microsoft ADFS e Shibboleth são IdPs hospedados comuns. Microsoft Azure AD, Okta e Ping estão entre os muitos IdPs de nuvem.

Protocolos de autenticação

Os protocolos de autenticação estabelecem a comunicação entre aplicativos e IdPs ou entre diferentes IdPs. OpenID Connect e SAML 2.0 são exemplos de protocolos de autenticação. Alguns protocolos de autenticação oferecem recursos adicionais, como criptografia, mas os aplicativos podem ou não usar esses recursos. Quando um sistema usa um IdP integrado, os protocolos de autenticação não são considerados.

Fluxo de autenticação

A maioria dos IdPs externos oferece suporte a um ou ambos os fluxos a seguir para o processo de autenticação:

  • Iniciado pelo SP: a autenticação é iniciada pelo provedor de serviços ou aplicativo. O usuário insere as credenciais e o aplicativo entra em contato com um IdP externo para verificação de identidade. Este é o fluxo mais comum.
  • Iniciado pelo IdP: os usuários efetuam login no IdP primeiro e, em seguida, o IdP inicia os aplicativos depois de verificar o usuário.

Gerenciamento de identidade federado

O Federated Identity Management às vezes é chamado de FIM ou federação. É um termo abrangente para o processo de usar um único IdP externo para fornecer autenticação para um ou mais aplicativos. A federação é geralmente limitada no tempo de alguma forma. Por exemplo, um usuário pode fazer login uma vez quando começar a trabalhar. Isso os autentica em todos os aplicativos que eles usam todos os dias. No entanto, eles teriam que fazer login novamente no dia seguinte para reautenticar, mesmo que não tivessem feito logout no dia anterior.

Logon único

O logon único (SSO) é usado para fornecer acesso a vários aplicativos ou sistemas com base em um logon. Por exemplo, um usuário faz logon no Microsoft 365 e obtém acesso a todos os aplicativos da Microsoft que sua empresa autorizou para ele. Às vezes, o termo SSO é usado para federação, embora os dois conceitos não sejam exatamente os mesmos.

Autenticação multi-fator

A autenticação multifator (MFA) adiciona outro nível de segurança à autenticação básica de nome de usuário/senha. A MFA exige que o usuário insira um código, responda a uma pergunta ou use um token antes que o IdP considere sua identidade verificada.

Confiar

Na autenticação, confiança refere-se à informação ou conhecimento compartilhado por um aplicativo ou sistema e um IdP externo. Esse conhecimento estabelece uma relação entre os dois para que cada um saiba que pode contar com a comunicação precisa e verdadeira do outro. Como a confiança é estabelecida difere dependendo do protocolo de autenticação. Os exemplos a seguir são baseados emOpenID ConnectSAML 2.0 e .

OpenID Connect

Confiança no OpenID Connect é baseada no emissor. Um emissor é um valor que se parece com um URL. Ele estabelece seu provedor de identidade. Por exemplo, o Google suporta OpenID Connect e o emissor é https://accounts.google.com.

Com base no emissor, há vários itens de configuração adicionais. Por exemplo, em OpenID Connect a confiança é estabelecida por meio da assinatura de certificados públicos/privados. Ele usa um padrão da indústria chamado JWKS. Portanto, parte da configuração determina como esses certificados públicos são obtidos.

A maioria dos provedores de identidade oferece suporte à descoberta dessas informações anexando /.well-known/openid-configuration ao emissor. O documento de descoberta do Google está em https://accounts.google.com/.well-known/openid-configuration.

SAML 2.0

Dentro SAML 2.0 , a confiança é baseada em um identificador de entidade. Diferente OpenID Connect , não há uma relação forte entre o identificador de entidade e outros valores de configuração. Existem vários parâmetros de configuração usados para estabelecer confiança com SAML 2.0 :

  • Identificador de entidade — Valor estabelecido pelo aplicativo ou sistema para verificar sua identidade

  • Endpoint URL — Valor determinado pelo IdP externo no qual recebe solicitações de autenticação

  • Assertion URL — Valor determinado pelo aplicativo ou sistema para o qual o IdP externo envia respostas de autenticação

  • Certificado — Usado pelo IdP externo para assinar a resposta