OAuth 2 - NumeroReal
By Rogério Costa | 7 de dezembro de 2015 | Categoria Geral, Segurança Digital
A segurança em servidores ou infraestruturas distribuídas, esta focada em uma base de autenticação, normalmente utilizando-se bancos hierárquicos, devido a necessidade do tempo de resposta. E para tal foi desenvolvido um protocolo de acronimo LDAP (Lightweight Directory Access Protocol) . Mas devido a necessidade de propagação desta credencial, o OAuth vem aparecendo como uma solução viável e de baixo custo para que os servidores de um infraestrutura distribuída mantenham segurança.
OAuth, o que é ?
OAuth é um padrão aberto para autorização. OAuth fornece aplicativos cliente uma "garantir o repasse do acesso' aos recursos do servidor em nome do proprietário de um recurso. Ele especifica um processo para proprietários de recursos para autorizar o acesso de terceiros aos seus recursos de servidor sem compartilhar suas credenciais. Projetado especificamente para trabalhar com Hypertext Transfer Protocol (HTTP), OAuth essencialmente permite que tokens de acesso a serem emitidas aos clientes de terceiros por um servidor de autorização, com a aprovação do proprietário do recurso. O cliente, em seguida, usa o token de acesso para acessar os recursos protegidos hospedados pelo servidor de recursos. OAuth é comumente usada como uma maneira para que os usuários da Internet para fazer login em sites de terceiros usando suas contas Microsoft, Google, Facebook ou Twitter, sem expor a sua senha.
OAuth é um serviço que é complementar e distinto do OpenID. OAuth também é distinta da OATH, que é uma arquitetura de referência para autenticação, não um padrão de autorização. No entanto, o OAuth está diretamente relacionada com OpenID Connect (OIDC) desde OIDC é uma camada de autenticação construído em cima do OAuth 2.0.
LDAP, é um protocolo de aplicação aberto, livre de fornecedor e padrão de indústria para acessar e manter serviços de informação de diretório distribuído sobre uma rede de Protocolo da Internet (IP). Serviços de diretório desempenham um papel importante no desenvolvimento de aplicações intranet e Internet permitindo o compartilhamento de informações sobre usuários, sistemas, redes, serviços e aplicações através da rede. Como exemplos, serviços de diretório podem fornecer qualquer conjunto de registros organizado, geralmente com uma estrutura hierárquica, como um diretório de e-mail corporativo. Da mesma forma, uma lista telefônica (diretório de telefones) é uma lista de assinantes com um endereço e um número de telefone. Um diretório LDAP geralmente segue o modelo X.500, que é uma árvore de nós, cada um consistindo de um conjunto de atributos com seus respectivos valores. O LDAP foi criado como uma alternativa ao muito mais incômodo Directory Access Protocol (DAP).
O que é um Lightweight Service?
Um serviço de Lightweight, que normalmente utiliza-se um LDAP, nestes novos moldes deve possuir as seguintes características:
HTTP transport. Barato e fácil de implementar, e apoiada por todas as plataformas de nuvem.
O conteúdo da mensagem de texto, geralmente JSON. A ênfase é sobre a legibilidade e, por vezes, fornecendo suporte fácil ao navegador front-end e os desenvolvedores móveis.
Pequenos, mensagens compactos, e respostas rápidas. Embora haja uma tendência paralela forte de serviços com respostas de streaming de dados "push", aqueles que geralmente não são implementadas da mesma forma, e HTTP não é o melhor transporte nesses casos.
REST ful, ou pelo menos inspirado pelo estilo arquitetônico REST.
Algum grau de apatridia, ou 'share-nothing', ou uso muito cuidado de estado do lado do servidor, para permitir a escalabilidade horizontal.
Interoperabilidade. Os consumidores do serviço pode ser uma população dinâmica, completamente desconhecido ou incognoscível em tempo de design, usando uma variedade de plataformas e linguagens.
OAuth2 , Gerenciamento Centralizado de Identidade
Como um sistema cresce e o número de componentes que precisam de acesso a serviços de autenticação e de conta de usuário dados aumenta de forma "galopante" , ou os dados da conta do usuário está mudando com frequência ou crescendo rapidamente, as abordagens simples para a segurança começam a tornar-se um problema de manutenção. O que é necessário é uma abordagem centralizada para gerenciamento de identidade, e um serviço para o sistema todo, que pode fornecer e gerenciar esses dados de forma segura. Este é o lugar onde padrões como OAuth2 entram em jogo. Eles introduzem uma nova camada na arquitetura, e alguma complexidade extra que pode ser difícil de se familiarizar com a princípio, mas os benefícios serão valeu a pena em muitos casos.
OAuth2 é um protocolo que permite uma aplicação cliente, muitas vezes, uma aplicação web, para agir em nome de um usuário, mas com a permissão do usuário. As ações de um cliente tem permissão para executar são realizadas por um Servidor de Recursos (outro aplicativo web ou serviço web), e aprova o usuário as ações por um servidor de autorização dizendo que ele confia o cliente a fazer o que ele está pedindo. Os clientes também podem agir como eles mesmos (e não em nome de um usuário) se eles estão autorizados a fazê-lo pelo Authorization Server.
A maneira mais comum para um cliente a apresentar-se a um servidor de recursos está usando um token de portador, como abordado na especificação de núcleo OAuth2. O token é obtido a partir do Authorization Server, com a aprovação do usuário, se necessário, e armazenado pelo Cliente. Então, quando ele precisa para acessar um servidor de recursos do cliente envia um cabeçalho HTTP especial no formulário:
Authorization: Bearer <TOKEN_VALUE>
O valor do token é opaco para um cliente, mas pode ser decodificado por um Servidor de Recursos para que ele possa verificar se o cliente e usuário tem permissão para acessar o recurso solicitado.
Exemplos comuns de servidores de autorização na Internet são Facebook, Google, e Cloud Foundry todos os quais também fornecem servidores de recursos (a API Graph no caso do Facebook, as APIs do Google, no caso do Google, e o Cloud Controller no caso de cloud Foundry).
OAuth2 é, na sua essência, um protocolo de autenticação para serviços Lightweight, que são servidores de recursos na língua domínio da especificação. Um aplicativo cliente que quiser acessar um recurso protegido envia um cabeçalho de autorização, um pouco como no caso de autenticação Basic. Por exemplo, em Ruby:
auth = "Bearer #{token}" response = RestClient.get("https://myhost/resource",:authorization=>auth)
ou em linha de comando :
Tal como acontece com a autenticação básica, a mecânica é extremamente simples, e isso é uma coisa que faz OAuth2 fichas ao portador atrativo para os clientes de serviços leves.
O token é opaco para o cliente, mas o Resource Server pode decodificá-lo em alguma informação mais fina granulação sobre o Cliente e o nível de acesso que representa o token. Em seguida, usa essas informações para tomar uma decisão de acesso. Esta não é a única característica da OAuth2, mas em seu próprio faz OAuth2 muito mais poderoso do que a autenticação simples básica: O token si carrega mais informação do que um cabeçalho Basic.
Um conjunto mínimo típico de informações em um token seria o ID do cliente, o ID do recurso de destino e um conjunto de escopos aprovados. Normalmente, a Resource Server tem um ID, e ele deve verificar se ele corresponde a um no token, a fim de evitar o uso indevido token. Além disso, é inteiramente até a recursos de servidor de o que fazer com os dados de token decodificado. Se o recurso Server é capaz de coordenar com o Authorization Server, ele pode mandar para dados específicos de fina granularidade a ser codificado no token, relativo à decisão de acesso que quer fazer. Por exemplo, o Authorization Server pode incluir atribuições de função que são reconhecidos pela Resource Server. Tokens poderia, e fazem, também contêm outras informações, como um identificador único para o usuário atual (se houver).
As atribuições do grupos de stores UAA em seus dados de usuário nativas, e aqueles aparecem nos tokens de acesso como escopos. O escopo valoriza-se na SAU são período de separados, mas cabe ao Resource Server para interpretá-los de qualquer maneira que ele precisa. Por exemplo, um servidor de recursos que se autodenomina 'dashboard' pode alterar a sua decisão de acesso com base em se ele encontrar um escopo 'dashboard.user' ou 'dashboard.admin', e esses são os nomes dos grupos nas contas de usuário. Estes semântica não fazem parte de qualquer especificação padrão, mas OAuth2 deixa-los até implementações de interpretar de acordo com sua necessidade, por isso a UAA tira proveito disso.
Bom Pessoal, por hoje é só volto em breve para mostrar a usabilidade do OAuth nas infraestruturas de Web Sites.