Estudo de Caso de uma Estrutura de Autenticação Única utilizando o protocolo OAuth

UNIVERSIDADE TECNOLÓGICA FEDERAL DO PARANÁ
PROGRAMA DE PÓS-GRADUAÇÃO EM TECNOLOGIA ESPECIALIZAÇÃO EM
DESENVOLVIMENTO DE SISTEMAS BASEADOS EM OBJETOS PARA AMBIENTE
INTERNET

FERNANDO GERALDO MANTOAN

ESTUDO DE CASO DE UMA ESTRUTURA DE AUTENTICAÇÃO ÚNICA UTILIZANDO
O PROTOCOLO OAUTH

MONOGRAFIA DE ESPECIALIZAÇÃO

MEDIANEIRA
2011

FERNANDO GERALDO MANTOAN

ESTUDO DE CASO DE UMA ESTRUTURA DE AUTENTICAÇÃO ÚNICA UTILIZANDO
O PROTOCOLO OAUTH

Trabalho de Conclusão de Curso apresentado à
Universidade Tecnológica Federal do Paraná –
Câmpus Medianeira como requisito parcial à
obtenção do grau de Especialista em Projeto e
Desenvolvimento de Sistemas Baseados em
Objetos para Ambiente Internet.

Orientador: Prof. Esp. Diego de Carvalho

MEDIANEIRA
2011

Ministério da Educação
Universidade Tecnológica Federal do Paraná
Diretoria de Pesquisa e Pós-Graduação
Especialização em Projeto e Desenvolvimento de Sistemas baseados em
Objetos para Ambiente Internet

TERMO DE APROVAÇÃO

Estudo de Caso de uma Estrutura de Autenticação Única utilizando o protocolo
OAuth

Por
Fernando Geraldo Mantoan

Esta monografia foi apresentada às 11:00h do dia 08 de dezembro de 2011
como requisito parcial para a obtenção do título de ESPECIALISTA, no curso de
Especialização em Projeto e Desenvolvimento de Sistemas baseados em Objetos
para Ambiente Internet, da Universidade Tecnológica Federal do Paraná, Câmpus
Medianeira. O acadêmico foi arguido pela Banca Examinadora composta pelos
professores abaixo assinados. Após deliberação, a Banca Examinadora considerou
o trabalho aprovado.

Prof. Esp. Diego de Carvalho Prof. Me. Alan Gavioli
Orientador Convidado
UTFPR – Câmpus Pato Branco UTFPR – Câmpus Medianeira

Prof. Dr. Hermes Irineu Del Monego Prof. Me. Fernando Schütz
Convidado Coordenador do Curso de Especialização
UTFPR – Câmpus Medianeira UTFPR – Câmpus Medianeira

UTFPR – DIRPPG
Av. Brasil, 4232 – Pq Independência
85884000 – Medianeira – PR
www.utfpr.edu.br/medianeira
+55(45) 3240-8074
A FOLHA DE APROVAÇÃO ASSINADA ENCONTRA-SE NA DIRETORIA DE PÓS-GRADUAÇÃO DA UTFPR
CÂMPUS MEDIANEIRA

AGRADECIMENTOS

Primeiramente a Deus, por sempre me iluminar e ser o meu apoio nas horas mais
difíceis.
À minha namorada Aline Regina Marzurkiewicz e aos meus pais, pelo incentivo,
pelo apoio, pelo amor e carinho, pela compreensão, por sempre me cobrarem e pela força
que sempre me deram.
Ao meu orientador, professor Diego de Carvalho, por toda assistência, pelo apoio,
pelas idéias, pela paciência, e por sempre me ajudar, mesmo não estando presente
fisicamente.
Agradeço aos meus amigos e colegas, pelos momentos de discussão, estudo e
diversão.

“A coisa mais bonita que podemos experimentar é o
mistério. Ele é a fonte de toda a verdadeira arte e
ciência.”
Albert Einstein

RESUMO

MANTOAN, Fernando Geraldo. Estudo de caso de uma estrutura de autenticação única
utilizando o protocolo OAuth. 56 f. Monografia (Especialização em Projeto e
Desenvolvimento de Sistemas Baseados em Objetos para Ambiente Internet) – Programa
de Pós-graduação em Tecnologia, Universidade Tecnológica Federal do Paraná.
Medianeira, 2011.

O presente trabalho tem como principal objetivo apresentar um estudo de caso de uma
estrutura de autenticação única utilizando o protocolo OAuth. Com este protocolo o
modelo tradicional de autenticação cliente-servidor ganha um terceiro papel que é o de
proprietário do recurso, um usuário com credenciais válidas no provedor OAuth
responsável por permitir ou negar acesso de consumidores aos seus dados pessoais.
Também é feito um estudo sobre conceitos de segurança, apresentação das tecnologias
utilizadas no estudo de caso, e toda a parte de implementação, composta por um
provedor OAuth e duas aplicações consumidoras, utilizada para verificar as
funcionalidades do OAuth.

Palavras-chave: Segurança, Spring Framework, Java, Play Framework, PHP, Zend
Framework.

ABSTRACT

MANTOAN, Fernando Geraldo. Case study of a structure of single sign on with the OAuth
protocol. 56 f. Monografia (Especialização em Projeto e Desenvolvimento de Sistemas
Baseados em Objetos para Ambiente Internet) – Programa de Pós-graduação em
Tecnologia, Universidade Tecnológica Federal do Paraná. Medianeira, 2011.

This assignment has the main goal of presenting a case study of an structure of single
sign on with the OAuth protocol. With OAuth the traditional client-server authentication
model gains a third role, which is the role of the resource owner, an user with valid
credentials in the OAuth provider responsible of allowing or revoking consumers access to
its personal data. It also makes a study about the main security concepts, an overview of
the technologies used in the case study, and all the information about the implementation,
which is composed by a provider application and two consumer applications, used to
check the OAuth functionalitys.

Keywords: Security, Spring Framework, Java, Play Framework, PHP, Zend Framework.

LISTA DE FIGURAS

FIGURA 1: TELA DE AUTORIZAÇÃO DO TWITTER.........................................................34
FIGURA 2: TELA DE AUTORIZAÇÃO DO YAHOO!............................................................35
FIGURA 3: ARQUITETURA DEFINIDA...............................................................................44
FIGURA 4: TELA DE AUTENTICAÇÃO...............................................................................49
FIGURA 5: TELA DE AUTORIZAÇÃO.................................................................................52
FIGURA 6: TELA DE ACESSO REVOGADO......................................................................52
FIGURA 7: TELA INICIAL DA APLICAÇÃO DE CONTATOS..............................................55
FIGURA 8: TELA PARA ADICIONAR UM CONTATO..........................................................55
FIGURA 9: TELA INICIAL DA APLICAÇÃO DE FINANÇAS................................................59
FIGURA 10: TELA PARA ADICIONAR UM LANÇAMENTO................................................59

LISTA DE SIGLAS

API Application Programming Interface
AOP Aspect Oriented Programming
CAS Central Authentication Service
CSS Cascading Style Sheets
HTML HyperText Markup Language
HTTP HyperText Transfer Protocol
HTTPS HyperText Transfer Protocol Secure
IoC Inversion of Control
J2EE Java 2 Platform Enterprise Edition
J2ME Java 2 Platform Micro Edition
J2SE Java 2 Platform Standard Edition
JPA Java Persistence API
JVM Java Virtual Machine
MVC Model View Controller
OAUTH Open Authentication
ORM Object Relational Mapper
PHP Hypertext Preprocessor
REST Representational State Transfer
RMI Remote Method Invocation
SQL Structured Query Language
SSL Secure Sockets Layer
URI Unified Resource Identifier
URL Uniform Resource Locator
W3C World Wide Web Consortium
WWW World Wide Web
XML Extensible Markup Language

SUMÁRIO

1 INTRODUÇÃO..................................................................................................................12
1.1 JUSTIFICATIVA..............................................................................................................12
1.2 OBJETIVOS...................................................................................................................13
1.2.1 Objetivo Geral.............................................................................................................13
1.2.2 Objetivos Específicos..................................................................................................13
2 FUNDAMENTAÇÃO TEÓRICA........................................................................................14
2.1 SEGURANÇA................................................................................................................14
2.2 AUTENTICAÇÃO...........................................................................................................15
2.3 AUTORIZAÇÃO.............................................................................................................15
2.4 CLOUD COMPUTING...................................................................................................16
2.5 HTTP..............................................................................................................................16
2.5.1 URIs............................................................................................................................17
2.5.2 URLs...........................................................................................................................17
2.5.3 Transações..................................................................................................................18
2.5.4 Métodos......................................................................................................................18
2.5.5 Códigos de Estado......................................................................................................19
2.5.6 Mensagens..................................................................................................................19
2.6 OPENID.........................................................................................................................20
2.6.1 Fluxo de Autenticação.................................................................................................21
2.7 CAS................................................................................................................................21
2.7.1 Fluxo de Autenticação.................................................................................................22
2.8 OAUTH...........................................................................................................................23
2.8.1 Terminologia................................................................................................................23
2.8.2 Benefícios...................................................................................................................24
2.8.3 Funcionamento...........................................................................................................25
2.8.4 Credenciais Temporárias............................................................................................26
2.8.5 Autorização do proprietário do recurso.......................................................................27
2.8.6 Credenciais de Token.................................................................................................29
2.8.7 Requisições Autenticadas...........................................................................................30
2.8.8 Experiência do Usuário...............................................................................................33
3 PROCEDIMENTOS METODOLÓGICOS.........................................................................36
3.1 PROCEDIMENTOS DE PESQUISA..............................................................................36
3.1.1 Tipo de Pesquisa........................................................................................................36
3.2 ESTRUTURA FÍSICA.....................................................................................................36
3.3 TECNOLOGIAS.............................................................................................................37
3.3.1 Java.............................................................................................................................37
3.3.2 Spring MVC e Spring Security....................................................................................38
3.3.3 Hibernate.....................................................................................................................38
3.3.4 PHP.............................................................................................................................39
3.3.5 Zend Framework.........................................................................................................39
3.3.6 Play Framework..........................................................................................................40
3.3.7 HTML 5 e CSS3..........................................................................................................40
3.3.8 MySQL........................................................................................................................41
3.4 JUSTIFICATIVAS TECNOLÓGICAS.............................................................................41
4 IMPLEMENTAÇÃO...........................................................................................................43
4.1 SERVIDOR DE AUTENTICAÇÃO.................................................................................43
4.1.1 Configuração do Spring Security e OAuth..................................................................44
4.1.2 Autenticação de Usuários...........................................................................................47
4.1.3 Confirmação do Proprietário do Recurso...................................................................49

4.2 APLICAÇÃO 1: AGENDA DE CONTATOS....................................................................52
4.3 APLICAÇÃO 2: CONTROLE DE FINANÇAS................................................................56
5 CONSIDERAÇÕES FINAIS.............................................................................................60
5.1 TRABALHOS FUTUROS...............................................................................................60
REFERÊNCIAS...................................................................................................................62

12

1 INTRODUÇÃO

Aplicações no geral possuem a necessidade comum de restringir o acesso
aos seus recursos utilizando meios de segurança como, por exemplo, autenticação
de usuários. Comumente, cada aplicação fornece uma fonte de dados para
armazenar informações de usuários do software e, utilizando estas fontes de dados,
fornece restrição baseada em credenciais de acesso (usuário e senha por exemplo).
No modelo tradicional de autenticação cliente-servidor, o cliente usa suas
credenciais para acessar os recursos hospedados pelo servidor. Com o advento do
uso de web services distribuídos e de cloud computing, aplicações de terceiros
precisam acessar estes recursos hospedados pelo servidor. (OAUTH, 2010)
O protocolo OAuth introduz um terceiro papel no modelo tradicional de
autenticação cliente-servidor: o resource owner (proprietário do recurso). No modelo
OAuth, o cliente (que não é o proprietário do recurso, mas está atuando como um)
requisita acesso a recursos controlados pelo proprietário, mas hospedados no
servidor. Além disso, o OAuth permite que o servidor verifique não apenas a
autorização do proprietário do recurso, mas também a identidade do cliente que está
fazendo a requisição. (OAUTH, 2010)
A proposta deste trabalho é fazer um estudo sobre o protocolo OAuth,
destacando os princípios pelos quais ele foi elaborado, seu funcionamento,
utilização no mercado e aspectos principais. Será implementada uma estrutura
básica de autenticação única, com a definição de uma arquitetura para a parte de
autenticação utilizando o protocolo OAuth, e duas mini-aplicações, que utilizam a
estrutura de autenticação desenvolvida, permitindo ou negando acesso aos recursos
disponibilizados, de acordo com cada uma das aplicações.

1.1 JUSTIFICATIVA

Com o advento do uso de web services distribuídos e de cloud computing,
aplicações de terceiro precisam acessar estes recursos hospedados pelo servidor,
fugindo do modelo tradicional de autenticação entre cliente e servidor. (OAUTH,
2010)

13

O protocolo OAuth fornece um método para que clientes acessem recursos
do servidor em nome de um proprietário do recurso. Com ele também é possível
fornecer um processo para usuários finais autorizarem acesso de terceiros aos
recursos de seus servidores sem compartilhar suas credenciais (como o conjunto
usuário/senha), usando redirecionamento de seus agentes de usuários. (OAUTH,
2010)

1.2 OBJETIVOS

1.2.1 Objetivo Geral

Propor uma estrutura para fornecer autenticação única com o protocolo
OAuth na plataforma Java, e implementar duas mini-aplicações que utilizem esta
estrutura de autenticação, sendo elas de plataformas de programação diferentes.

1.2.2 Objetivos Específicos

• Explicar os conceitos de segurança;
• Explanar o protocolo OAuth, seguindo sua especificação e apresentar sua
utilização no mercado;
• Apresentar as tecnologias utilizadas no desenvolvimento das aplicações;
• Implementar uma aplicação que forneça autenticação única utilizando o
protocolo OAuth;
• Realizar um estudo de caso, elaborando duas aplicações que se
autenticam utilizando a estrutura OAuth implementada.

14

2 FUNDAMENTAÇÃO TEÓRICA

Neste capítulo é apresentada toda a fundamentação teórica levantada
durante a análise bibliográfica dos principais conceitos necessários para o estudo
deste trabalho. Serão abordados os principais aspectos sobre segurança,
autorização, autenticação, cloud computing, o protocolo HTTP, alguns protocolos de
autenticação similares ao OAuth (OpenID e CAS) e os principais conceitos
fornecidos pela especificação do protocolo OAuth.

2.1 SEGURANÇA

Segurança é sem dúvida um dos componentes arquiteturais mais críticos de
qualquer aplicação baseada na web escrita no século vinte e um. Em uma era onde
malwares, crimonosos, e funcionários mal intencionados estão sempre presentes e
ativamente testando falhas de software, o uso inteligente e abrangente de segurança
é um elemento chave para novos projetos a serem desenvolvidos. (MULARIEN,
2010)
O objetivo da segurança consiste em garantir um conjunto de três atributos:
confidencialidade, integridade e disponibilidade. A confidencialidade é a ausência
de divulgação não autorizada de conteúdo. A integridade é a ausência de
alterações não autorizadas ao sistema ou à informação. A disponibilidade é a
prontidão do serviço fornecido ou da informação. Além das três, é comumente
adicionada a autenticidade, que é a medida em que a informação ou o serviço
fornecido são genuínos. (CORREIA; SOUSA, 2010)
Um dos principais conceitos na segurança de software é o de
vulnerabilidades, que é um defeito relevante no sistema que pode ser explorado por
um atacante com o objetivo de subverter sua política de segurança. Existem três
tipos de vulnerabilidades, podendo ser uma vulnerabilidade de projeto, que é
introduzida durante o projeto do sistema; vulnerabilidade de codificação que é
introduzida durante a codificação e resulta em bugs de segurança; e a
vulnerabilidade operacional, causada pelo ambiente onde o sistema é executado
ou por sua configuração. (CORREIA; SOUSA, 2010)

15

2.2 AUTENTICAÇÃO

Autenticação é um dos dois conceitos chave que deve ser implementado ao
se desenvolver aplicações seguras. A autenticação lida com a identificação
específica de um usuário do sistema, e com o mapeamento deste usuário para uma
entidade identificável (e, portanto, protegida). Tipicamente, um software está dividido
em dois domínios de alto nível como anônimo e autenticado. (MULARIEN, 2010)
As funcionalidades da aplicação para o domínio anônimo são independentes
de uma identificação de usuário, como por exemplo, uma listagem de produtos em
um site de comércio eletrônico. As seções que permitem acesso anônimo não
requerem a autenticação do usuário para sua utilização, não exibem informações
confidenciais como nomes e cartões de créditos, e não fornecem meios para
manipulação geral do sistema ou de seus dados. (MULARIEN, 2010)

2.3 AUTORIZAÇÃO

Autorização é o segundo dos dois principais conceitos de segurança cruciais
na implementação e compreensão de segurança de aplicações. Autorização lida
com a disponibilidade adequada de funcionalidades e dados para usuários que
estão autorizados para acessá-los. Construído em torno do modelo de autorização
para a aplicação está a atividade de particionar as funcionalidades e os dados da
aplicação de tal forma que a disponibilidade destes itens possam ser controlados por
uma combinação de privilégios, funcionalidades e dados, e usuários. (MULARIEN,
2010)
O processo de autorização tipicamente envolve dois aspectos separados
que se combinam para descrever a acessibilidade do sistema seguro. O primeiro é o
mapeamento de um usuário autenticado para um ou mais papéis, por exemplo o
papel de administrador do sistema ou o papel de visitante. O segundo aspecto é a
atribuição das checagens de autoridade para os recursos protegidos do sistema, o
que tipicamente é feito durante o desenvolvimento do sistema, através de
declaração explícita no código ou por meios de configuração. Um recurso protegido
pode ser uma funcionalidade do sistema, como, por exemplo, gerenciamento de
produtos. (MULARIEN, 2010)

16

2.4 CLOUD COMPUTING

Cloud Computing (computação na nuvem) é um fenômeno recente que
impacta na forma com que infra-estruturas são arquitetadas, compradas e
implantadas. No modelo de computação na nuvem, computação e infra-estruturas
de armazenamento estão disponíveis para uso como um utilitário e não apenas
dentro de uma infra-estrutura própria. O modelo de utilitário estende-se a partir de
apenas um hardware de computador de plataforma de serviços para aplicativos
completos como um serviço externo. (SANKAR; BOUCHARD, 2009)
Computação na nuvem é uma otimização tática assim como um artefato
arquitetural estratégico. É uma otimização tática, porque ao se ter aplicações ad-hoc
que precisam funcionar em um curto período de tempo (como uma enquete ou
alguma pesquisa) é possível executá-la em uma infra-estrutura de nuvem, como, por
exemplo, o Amazon Elastic Compute Cloud. Mas também é estratégica porque
agora os acionistas de empresa (e envolvidos em TI) podem trabalhar além das
limitações de largura de banda finita de computação e otimizar os sistemas ativos a
uma era de poder de processamento infinito, que é flexível. (SANKAR; BOUCHARD,
2009)
Uma nuvem é um conjunto de soluções escaláveis, com infra-estrutura
abstrata que hospeda aplicações de uso final, cobrado pelo consumo. Em suma,
uma nuvem é um conjunto grande de infra-estrutura de servidores, rede e
armazenamento, hospedado em algum lugar para ser alugado ou usado conforme a
necessidade. Ele pode ser interno a uma empresa (chamado de nuvem “privada”) ou
hospedado na internet como uma nuvem “pública”. A decisão de se utilizar a nuvem
privada ou pública para um aplicativo é determinada por políticas, conformidade e
regulamentos relevantes para uma organização, bem como as condições de
visibilidade e controle de uma empresa comparado com os recursos fornecidos por
um provedor de nuvem público. (SANKAR; BOUCHARD, 2009)

2.5 HTTP

Todos os navegadores de internet, servidores, e aplicações web
relacionadas se comunicam entre si através do Hypertext Transfer Protocol (HTTP),

17

que é uma linguagem comum da Internet mundial moderna. (GOURLEY; TOTTY,
2002)
O conteúdo da web reside em servidores web, que falam o protocolo HTTP,
dessa forma sendo comumente chamados de servidores HTTP. Estes servidores
fornecem os dados quando são requisitados pelos clientes HTTP, que enviam
pedidos HTTP para servidores e recebem os dados pedidos em respostas HTTP. O
conjunto de clientes e servidores HTTP fazem os componentes básicos da World
Wide Web (WWW). (GOURLEY; TOTTY, 2002)
O protocolo HTTP possui diversos blocos necessários para seu correto
funcionamento, cada um com uma finalidade distinta para compor este protocolo
que, segundo Gourley e Totty (2002) é o mais utilizado pela internet atual. Dentre
estes blocos encontram-se nomes de recursos (URIs), identificadores de recursos
(URLs), transações, métodos, códigos de estado e mensagens.

2.5.1 URIs

Cada recurso de um servidor web tem um nome, assim clientes podem
apontar quais recursos eles estão interessados em acessar. O nome do recurso de
servidor é chamado de Unified Resource Identifier (URI), em português Identificador
Único de Recurso. URIs são como os endereços postais da Internet, identificando
exclusivamente e localizando informação de recursos em todo o mundo. Um
exemplo de URI de uma imagem em um servidor web é apresentado no Quadro 1.
(GOURLEY; TOTTY, 2002)

http://www.site.com/imagens/imagem.gif
Quadro 1: Exemplo de URI

2.5.2 URLs

O Uniform Resource Locator (URL) é a forma mais comum de um
identificador de recurso. URLs descrevem a localização específica de um recurso
em um servidor particular. Elas descrevem exatamente como obter um recurso de
uma localização precisa e fixa. (GOURLEY; TOTTY, 2002)
De acordo com Gourley e Totty (2002) muitas URLs seguem um formato

18

padronizado de três partes principais:
• A primeira parte da URL é chamada de esquema, e ela descreve o
protocolo utilizado para acessar o recurso, comumente o protocolo é o
HTTP (http://);
• A segunda parte fornece o endereço do servidor de Internet (por exemplo,
www.site.com);
• O resto da URL nomeia um recurso de um servidor web (por exemplo,
/imagens/imagem.gif).
Atualmente, quase toda URI é uma URL. (GOURLEY; TOTTY, 2002)

2.5.3 Transações

Uma transação HTTP consiste em um comando de pedido (enviado do
cliente ao servidor), e um resultado de resposta (enviado de volta ao cliente). Esta
comunicação acontece com blocos formatados de dados chamados de mensagens
HTTP. (GOURLEY; TOTTY, 2002)

2.5.4 Métodos

O protocolo HTTP suporta diferentes comandos de pedido, chamados de
métodos HTTP. Cada mensagem de pedido HTTP possui um método, que diz ao
servidor qual ação deve ser executada (obter uma página, executar um programa,
excluir um arquivo, etc). O Quadro 2 lista os cinco métodos HTTP comuns.
(GOURLEY; TOTTY, 2002)
Método Descrição
GET Envia um recurso nomeado do servidor ao cliente.
PUT Armazena dados de um cliente em um recurso nomeado do servidor.
DELETE Exclui o recurso nomeado de um servidor.
POST Envia dados do cliente a uma aplicação servidora de gateway.
HEAD Envia apenas os cabeçalhos HTTP da resposta para o recurso nomeado.
Quadro 2: Métodos HTTP
Fonte: Gourley e Totty (2002)

19

2.5.5 Códigos de Estado

Cada mensagem de resposta HTTP retorna com um código de estado. O
código de estado é um número de três dígitos que diz ao cliente se o pedido foi
executado com sucesso, ou se outras ações são necessárias. O HTTP também
envia uma explicação textual com cada código numérico, que é inclusa apenas para
fins descritivos; e o código numérico é utilizado para todo o processamento. Alguns
códigos de estado comuns são apresentados no Quadro 3. (GOURLEY; TOTTY,
2002)
Código de Estado Descrição
200 OK. Documento retornado com sucesso.
302 Redirect. Redireciona o usuário para outro lugar para obter o recurso.
404 Not Found. Não foi possível encontrar este recurso.
Quadro 3: Códigos de Estado
Fonte: Gourley e Totty (2002)

2.5.6 Mensagens

Mensagens HTTP são simples sequências de caracteres orientadas por
linha. Devido ao fato de serem texto simples, não binários, eles são fáceis para
seres humanos lerem e escreverem. Mensagens HTTP enviadas de clientes web
aos servidores são denominados mensagens de pedido. Mensagens de servidores a
clientes são chamados de mensagens de resposta. Não existem outros tipos de
mensagens HTTP e o formato de ambas as mensagens é similar. (GOURLEY;
TOTTY, 2002)
Segundo Gourley e Totty (2002) as mensagens HTTP consistem de três
partes:
Linha de início: A primeira linha da mensagem é a linha de início, indicando
o que fazer para um pedido e o que aconteceu para um recurso;
Campos de cabeçalho: Nenhum ou muitos campos de cabeçalho seguem a
linha de início. Cada campo de cabeçalho consiste de um nome e um valor,
separados pelo caractere dois pontos (:) para facilitar a leitura. Os cabeçalhos
terminam com uma linha em branco;
Corpo: Após a linha branca existe um corpo de mensagem opcional

20

contendo qualquer tipo de dado. Corpos de pedido carregam dados para o servidor
web; corpos de resposta carregam dados para o cliente. Diferentemente da linha de
início e dos cabeçalhos, que são textuais e estruturados, o corpo pode conter dados
binários arbitrários (por exemplo, imagens, vídeos etc.), assim como podem conter
texto simples.

2.6 OPENID

OpenID fornece sites e serviços com um protocolo descentralizado de
autenticação de usuários através de uma ampla variedade de provedores. Isso
significa que um site integrando OpenID pode permitir que seus usuários se
autentiquem utilizando, por exemplo, suas contas do Yahoo!, Google ou AOL. O site
em questão pode não apenas evitar a criação de seu próprio sistema de
autenticação, mas também pode tirar vantagem das contas que seus usuários já
possuem, aumentando assim o registro de usuários e as taxas de autenticação.
(LEBLANC, 2011)
Além da autenticação simples, o OpenID também oferece diversas
extensões através do qual um provedor de OpenID pode permitir que as aplicações
obtenham informações do perfil de um usuário ou integrar camadas adicionais de
segurança para o procedimento de autenticação. (LEBLANC, 2011)
O fator mais interessante do OpenID é o de que ele oferece um padrão que
é totalmente descentralizado dos provedores e dos consumidores. Este aspecto é o
que dá a um site consumidor simples a possibilidade de autenticação a partir de
contas do Yahoo! e Google, enquanto outro site pode querer que seus usuários se
autentiquem através do Blogger ou Wordpress. Cabe ao consumidor OpenID (um
site ou serviço) escolher quais métodos de autenticação ele gostaria de oferecer aos
seus usuários. (LEBLANC, 2011)
Cada provedor de OpenID possui um endereço de OpenID associado com
seu sistema de autenticação para habilitar o método de descoberta requirido para o
processo de autenticação. Existem diversos provedores de OpenID, entre os
principais estão o Google, Yahoo!, Flickr, Wordpress, AOL, Blogger, MySpace,
MyOpenID entre outros. (LEBLANC, 2011)

21

2.6.1 Fluxo de Autenticação

Segundo Leblanc (2011) o OpenID define um fluxo padronizado pelo qual
um usuário pode se autenticar em um site de terceiro de retransmissão de um
provedor de OpenID como Yahoo! ou Google. Existem três participantes no fluxo de
autenticação do OpenID:
• O usuário: Usuário final que está tentando se autenticar em um site ou
serviço utilizando um dos provedores de OpenID;
• Partido confiável: Site consumidor de OpenID, que implementa um
processo de autenticação de um provedor de OpenID, para permitir aos
usuários a autenticação com suas contas;
• O provedor de OpenID: Site ou serviço que possui o banco de dados de
membros que o partido confiável se autenticará e através do qual o
usuário irá fornecer seus dados de acesso.
O processo de autenticação do OpenID necessita de quatro passos
diferentes, iniciando quando o usuário escolhe um provedor para se autenticar e
terminando com o resultado de sucesso/falha do provedor quando o usuário tenta se
autenticar. No primeiro passo é solicitada a autenticação do usuário, passando uma
URI identificadora de OpenID. No segundo passo é feita a descoberta do endpoint
do OpenID. No terceiro passo é solicitado ao usuário que o mesmo se autentique
com sua conta. E finalmente, no quarto passo, é fornecido um estado de
sucesso/falha baseado na autenticação. (LEBLANC, 2011)

2.7 CAS

Central Authentication Service (CAS) é um portal de autenticação única de
código aberto, que fornece controle de acesso centralizado, e autenticação para
recursos baseados na web dentro de uma organização. Mularien (2010) destaca que
os principais benefícios do CAS são:
• O acesso individual ou em grupo a recursos (aplicações) pode ser
configurado em um único local;
• Suporte a uma ampla variedade de locais de autenticação (para centralizar
a gestão de usuários), fornecendo um ponto único de autenticação e

22

controle para um amplo ambiente multi-máquina;
• O suporte amplo de autenticação é fornecido por aplicações Java
baseadas ou não baseadas na web através de bibliotecas de clientes
CAS;
• Um único ponto de referência para credenciais de usuário (através de
CAS), para que aplicações clientes CAS não necessitam saber nada sobre
as credenciais do usuário, ou como verificar elas.

2.7.1 Fluxo de Autenticação

Segundo Mularien (2010), o fluxo básico de autenticação do CAS é
executado através das seguintes ações:
• Primeiramente o usuário tenta acessar um recurso protegido de uma
aplicação;
• O usuário é redirecionado para o portal CAS através do mecanismo de
segurança da aplicação, para fornecer suas credenciais;
• O portal CAS é responsável pela autenticação do usuário. Se o usuário for
autenticado com sucesso no CAS, ele é redirecionado para o recurso
protegido com um ticket CAS único definido na requisição;
• O mecanismo de segurança da aplicação chama novamente o servidor
CAS para validar se o ticket é aceitável (é válido, não está expirado, etc).
O servidor CAS responde com uma afirmação indicando que a confiança
foi estabelecida. Caso o ticket seja aceitável, a confiança foi estabelecida
e o usuário pode proceder através de checagem de autorização comum.
Com este fluxo é possível visualizar que existe uma grande interação entre o
servidor CAS e a aplicação segurada, com a necessidade de bastante troca de
dados antes que a confiança do usuário possa ser estabelecida. O resultado desta
complexidade é um protocolo de autenticação única que é difícil para falsificar
através de técnicas comuns (assumindo que outras precauções de segurança foram
tomadas, como o uso de Secure Sockets Layer e monitoração de rede).
(MULARIEN, 2010)

23

2.8 OAUTH

Open Authentication (OAuth), é um padrão aberto para autorização de
aplicações para acessar dados em nome de um usuário. Através do OAuth, é
possível proteger informações pessoais de um usuário. O protocolo OAuth é
utilizado por diversas grandes empresas famosas da Internet, como, por exemplo,
Yahoo!, Google, FourSquare e Twitter. (LEBLANC, 2011)
O protocolo OAuth foi criado originalmente por uma comunidade pequena de
desenvolvedores web de diversos websites, que queriam resolver o problema
comum de permitir a delegação de acesso a recursos protegidos. O protocolo OAuth
resultante foi estabilizado na versão 1.0 em Outubro de 2007, e revisado em Junho
de 2009 (Revisão A), conforme publicado online. (OAUTH, 2010)
O protocolo OAuth fornece um método para que clientes acessem recursos
do servidor em nome de um resource owner (dono de recursos). Também é possível
fornecer um processo para usuários finais autorizarem acesso de terceiros aos
recursos de seus servidores sem compartilhar suas credenciais (como, por exemplo,
usuário/senha), usando redirecionamento de seus agentes de usuários. (OAUTH,
2010)
Para que o cliente acesse recursos do servidor, ele primeiramente precisa
obter permissão do dono de recursos. Essa permissão é expressada na forma de
um token e de uma chave secreta correspondente. O objetivo do token é fazer com
que não haja necessidade do dono de recursos compartilhar suas credenciais com o
sistema. Diferentemente das credenciais do dono de recursos, tokens podem ser
emitidas com um escopo restrito e um tempo de vida limitado, e podem ser
revogados independentemente. (OAUTH, 2010)

2.8.1 Terminologia

O protocolo OAuth apresenta diversos conceitos com um significado
particular para seu contexto, conforme apresentado abaixo:
Cliente: Um cliente HTTP capaz de fazer requisições OAuth autenticadas.
(OAUTH, 2010)
Servidor: Um servidor HTTP capaz de aceitar requisições OAuth

24

autenticadas. (OAUTH, 2010)
Recurso protegido: Um recurso de acesso restrito que pode ser obtido de
um servidor utilizando uma requisição OAuth autenticada. (OAUTH, 2010)
Proprietário do recurso: Uma entidade capaz de acessar e controlar
recursos protegidos utilizando credenciais para se autenticar no servidor. (OAUTH,
2010)
Credenciais: Credenciais são um par composto de um identificador único e
um segredo correspondente compartilhado. O OAuth define três classes de
credenciais: cliente, temporário e token, usados, respectivamente, para identificar e
autenticar o cliente que está fazendo a requisição, a requisição de autorização, e a
concessão do acesso. (OAUTH, 2010)
Token: Um identificador único emitido pelo servidor e usado pelo cliente
para associar requisições autenticadas com o proprietário do recurso cuja
autorização é solicitada ou tenha sido obtida pelo cliente. Tokens possuem uma
chave secreta compartilhada correspondente que é utilizada pelo cliente para
estabelecer a sua posse do token, e sua autoridade para representar o proprietário
do recurso. (OAUTH, 2010)

2.8.2 Benefícios

Segundo Leblanc (2011, p. 319) o protocolo OAuth oferece algumas
melhorias sobre os modelos tradicionais de autenticação, incluindo:
• Ao invés de ter que enviar o nome de usuário e senha ao servidor com
cada requisição de autenticação, é possível trabalhar com tokens de
acesso abstratos que não compartilham nenhuma das senhas do usuário;
• Como tokens são emitidos a partir de um servidor, eles podem ser
revogados a qualquer momento, colocando mais controle nas mãos do
usuário. Diversos provedores também implementam um mecanismo de
expiração de tokens, que requerem que uma aplicação periodicamente
renove o token de acesso para continuar executando requisições de dados
dos usuários;
• Usuários podem ver os tokens que eles possuem ativos (isto é, quais

25

aplicações podem acessar seus dados) no site do provedor, significando
que eles podem manualmente revogar o acesso de uma aplicação. Já que
a aplicação não possui as credenciais de autenticação do usuário, ela não
pode fazer mais requisições de dados uma vez que o usuário revogue a
autorização da aplicação.

2.8.3 Funcionamento

O OAuth utiliza tokens para representar a autorização garantida ao cliente
pelo proprietário de recurso. Tipicamente, credenciais de token são emitidos pelo
servidor na requisição do proprietário de recurso, após a autenticação da identidade
do proprietário de recurso (comumente utilizando um nome de usuário e senha).
(OAUTH, 2010)
Segundo OAuth (2010, p. 8) existem diversas maneiras de um servidor
prover as credenciais de token. Uma delas é utilizando a redirecionamentos HTTP
no agente de usuário do proprietário de recurso. Este redirecionamento inclui três
etapas:
1. O cliente obtém um conjunto de credenciais temporárias do servidor (na
forma de um identificador e uma chave secreta compartilhada). As
credenciais temporárias são utilizadas para identificar o pedido de
acesso em todo o processo de autorização;
2. O proprietário de recurso autoriza o pedido de acesso do cliente no
servidor (identificado pelas credenciais temporárias);
3. O cliente utiliza as credenciais temporárias para requisitar um conjunto
de credenciais de token do servidor, que lhe permitirá acessar recursos
protegidos do proprietário de recurso.
O servidor deve revogar as credenciais temporárias após elas serem
utilizadas para obter as credenciais de token. É recomendado que as credenciais
temporárias tenham um tempo de vida limitado. Servidores devem permitir que os
proprietários de recursos possam revogar as credenciais de token após elas serem
emitidas aos clientes. (OAUTH, 2010)
De acordo com OAuth (2010, p. 8), para permitir que o cliente execute as
três etapas, o servidor deve anunciar os endereços dos seguintes endpoints:

26

Pedido de Credencial Temporária: O endpoint utilizado pelo cliente para
obter um conjunto de credenciais temporárias.
Autorização do Proprietário do Recurso: Endpoint onde o proprietário do
recurso é redirecionado para garantir a autorização.
Pedido de Token: O endpoint utilizado pelo cliente para requisitar um
conjunto de credenciais de token utilizando as credenciais temporárias.

2.8.4 Credenciais Temporárias

O cliente obtém um conjunto de credenciais temporárias do servidor fazendo
pedido HTTP “POST” autenticado para o endpoint de Pedido de Credencial
Temporário. O cliente constrói uma URI de pedido adicionando o parâmetro
obrigatório “oauth_callback”, que define um endereço para o qual o servidor
redirecionará o proprietário de recurso após o processo de autorização do
proprietário do recurso estar completo. (OAUTH, 2010)
Ao fazer o pedido, o cliente se autentica utilizando apenas suas credenciais.
O cliente pode omitir o parâmetro vazio de protocolo “oauth_token” da requisição e
deve utilizar a string vazia como o valor secreto do token. (OAUTH, 2010)
Uma vez que o pedido resulta na transmissão de texto simples, o servidor
deve exigir o uso de um mecanismo de camada de transporte como o Secure
Sockets Layer (SSL) (ou um canal seguro com proteções equivalentes). (OAUTH,
2010)
O servidor deve verificar o pedido e se for válido, responder ao cliente com
um conjunto de credenciais temporárias (na forma de um identificador e um segredo
compartilhado). As credenciais temporárias são incluídas no corpo da resposta
HTTP utilizando o tipo de conteúdo “application/x-www-form-urlencoded” com um
código de estado 200, que significa sucesso na requisição. (OAUTH, 2010)
Segundo OAuth (2010) a resposta contém os seguintes parâmetros
obrigatórios:
• oauth_token: O identificador de credenciais temporárias;
• oauth_token_secret: O segredo compartilhado de credenciais
temporárias;

27

• oauth_callback_confirmed: Deve estar presente e definido como “true”.
Este parâmetro é utilizado para diferenciar de versões antigas do
protocolo.
Note que mesmo que o parâmetro inclua o termo “token”, essas credenciais
não são as credenciais de token, mas são utilizadas nas próximas duas etapas de
uma maneira similar às credenciais de token. O Quadro 4 contém um exemplo de
resposta HTTP de credenciais temporárias. (OAUTH, 2010)

HTTP/1.1 200 OK
Content-Type: application/x-www-form-urlencoded
oauth_token=hdk48Djdsa&oauth_token_secret=xyz4992k83j47x0b&oauth_callback_
confirmed=true
Quadro 4: Exemplo de Resposta HTTP de Credenciais Temporárias
Fonte: OAuth (2010)

2.8.5 Autorização do proprietário do recurso

Antes do cliente solicitar o conjunto de credenciais de token do
servidor, ele deve enviar o usuário ao servidor para autorizar a requisição. O cliente
constrói uma URI de pedido para o endpoint de Autorização do proprietário do
recurso, adicionando o parâmetro obrigatório “oauth_token”, que contém o
identificador de credenciais temporárias, obtido na etapa anterior no parâmetro
“oauth_token” da resposta. (OAUTH, 2010)
O cliente direciona o proprietário de recursos para a URI construída
utilizando uma resposta HTTP de redirecionamento, ou outros meios disponíveis
utilizando o agente de usuário do proprietário de recursos. A requisição deve utilizar
o método HTTP “GET”. (OAUTH, 2010)
Por exemplo, o cliente redireciona o agente de usuário do proprietário do
recurso para efetuar o seguinte pedido HyperText Transfer Protocol Secure (HTTPS)
apresentado no Quadro 5.

GET /authorize_access?oauth_token=hdk48Djdsa HTTP/1.1
Host: server.example.com
Quadro 5: Exemplo de pedido de autorização
Fonte: OAuth (2010)

Independente da maneira na qual o servidor processa o pedido de

28

autorização, incluindo ou não um canal seguro, o servidor sempre deverá verificar
primeiramente a identidade do proprietário do recurso.
Ao pedir para o proprietário de recurso para autorizar o pedido de acesso, o
servidor deve apresentar ao proprietário de recurso informações sobre o cliente que
está solicitando o acesso baseado na associação das credenciais de acesso
temporárias com a identidade do cliente. Ao exibir qualquer uma dessas
informações, o servidor deve indicar se as informações foram verificadas.
Após receber uma decisão de autorização do proprietário do recurso, o
servidor redireciona o usuário para o endereço de retorno, caso algum tenha sido
informado no parâmetro “oauth_callback” ou por outros meios.
Para garantir que o proprietário de recurso que está concedendo o acesso é
o mesmo proprietário de recurso que está retornando de volta ao cliente para
completar o processo, o servidor deve gerar um código de verificação: um valor não
adivinhável é passado para o cliente através do proprietário de recurso e obrigatório
para concluir o processo. O servidor constrói uma URI de solicitação adicionando os
seguintes parâmetros obrigatórios para o endereço de retorno:
oauth_token: O identificador de credenciais temporárias recebido do cliente;
oauth_verifier: O código de verificação.
O endereço de retorno já possui um componente de consulta, o servidor
deve acrescentar os parâmetros do OAuth no final da consulta existente. Por
exemplo, o servidor redireciona o agente de usuário do proprietário do recurso para
efetuar a seguinte requisição HTTP:

GET /cb?x=1&oauth_token=hdk48Djdsa&oauth_verifier=473f82d3 HTTP/1.1
Host: client.example.net
Quadro 6: Redirecionamento para o endereço de retorno com parâmetros do Oauth
Fonte: OAuth (2010)

Se o cliente não forneceu um endereço de retorno, o servidor deve exibir o
valor do código de configuração, e instruir o proprietário de recurso para informar
manualmente o cliente que a autorização está completa. Se o servidor conhece um
cliente que está rodando em um dispositivo limitado, ele deve garantir que o valor de
verificação é acessível para o registro manual.

29

2.8.6 Credenciais de Token

O cliente obtém um conjunto de credenciais de token do servidor fazendo
um pedido HTTP “POST” autenticado para o endpoint de Pedido de token. O cliente
constrói uma URI de pedido adicionando o seguinte parâmetro obrigatório:
oauth_verifier: Código de verificação recebido do servidor no passo
anterior.
Ao efetuar o pedido, o cliente faz a autenticação utilizando suas credenciais
(identificadores do cliente) assim como as credenciais temporárias. As credenciais
temporárias são utilizadas como um substituto para as credenciais de token no
pedido autenticado e transmitidas utilizando o parâmetro “oauth_token”.
Uma vez que o pedido resulta na transmissão das credenciais em texto puro
na resposta HTTP, o servidor deve requerer o uso de um mecanismo de camada de
transporte como o SSL (ou um canal seguro com proteções equivalentes). Um
exemplo de um pedido de credenciais de token utilizando um pedido HTTPS é

POST /request_token HTTP/1.1
Host: server.example.com
Authorization: OAuth realm="Example",
oauth_consumer_key="jd83jd92dhsh93js",
oauth_token="hdk48Djdsa",
oauth_signature_method="PLAINTEXT",
oauth_verifier="473f82d3",
oauth_signature="ja893SD9%26xyz4992k83j47x0b"
Quadro 7: Pedido de Credenciais de Token
Fonte: OAuth (2010)

O servidor deve verificar a validade do pedido, garantir que o proprietário do
recurso autorizou o fornecimento de credenciais de token ao cliente, e garantir que
as credenciais temporárias não foram expiradas ou usadas anteriormente. O
servidor deve verificar também o código de verificação recebido do cliente. Se o
pedido é válido e autorizado, as credenciais de token são incluídas no corpo da
resposta HTTP utilizando o tipo de conteúdo "application/x-www-form-urlencoded"
com um código de estado 200 (OK).
A resposta contém os seguintes parâmetros obrigatórios, e um exemplo de
resposta contendo credenciais de token é apresentado no Quadro 8:

30

oauth_token: O identificador do token.
oauth_token_secret: O segredo compartilhado do token.

HTTP/1.1 200 OK
oauth_token=j49ddk933skd9dks&oauth_token_secret=ll399dj47dskfjdk
Quadro 8: Resposta do servidor com as credenciais de token
Fonte: OAuth (2010)

O servidor deve reter o escopo, duração e outros atributos aprovados pelo
proprietário de recurso, e reforçar essas restrições ao receber uma requisição de um
cliente com as credenciais de token emitidas.
Uma vez que o cliente receba e armazene as credenciais de token, ele pode
proceder para acessar recursos protegidos em nome do proprietário de recurso
fazendo requisições autenticadas utilizando as credenciais de cliente em conjunto
com as credenciais de token recebidas.

2.8.7 Requisições Autenticadas

Alguns métodos especiais do protocolo HTTP permitem que clientes façam
requisições autenticadas, permitindo que eles ganhem acesso a recursos protegidos
utilizando suas credenciais (tipicamente o par usuário/senha), que permitem que o
servidor verifique a autenticidade dos mesmos. Utilizar estes métodos para
delegação exige que o cliente assuma o papel do proprietário do recurso. (OAUTH,
2010)
O OAuth fornece um método projetado para incluir dois conjuntos de
credenciais com cada requisição, um para identificar o cliente e outro para identificar
o proprietário do recurso. Antes do cliente ter permissão para fazer uma requisição
autenticada em nome do proprietário do recurso, ele deve obter um token autorizado
pelo proprietário do recurso, seguindo o método explicado nas seções anteriores.
(OAUTH, 2010)
As credenciais do cliente tomam a forma de um identificador único e um
segredo compartilhado único ou um par de chaves RSA. Antes de fazer requisições
autenticadas, o cliente estabelece esse conjunto de credenciais com o servidor. O
processo e os requisitos para prover essas credenciais variam de acordo com o

31

implementador do protocolo. (OAUTH, 2010)
De acordo com a especificação de OAuth (2010), uma requisição
autenticada inclui diversos parâmetros do protocolo. Cada nome de parâmetro inicia
com o prefixo “oauth_”, e os nomes e valores dos parâmetros são sensíveis à caixa.
Clientes fazem requisições autenticadas calculando os valores de um conjunto de
parâmetros de protocolo e adicionando-os à requisição HTTP da seguinte forma:
1. O cliente define o valor de cada um dos seguintes parâmetros de
protocolo:
• oauth_consumer_key: A porção de identificação das credenciais do
cliente (equivalente ao nome de usuário). O nome do parâmetro reflete
um termo depreciado (Chave do Consumidor) utilizado nas revisões
da especificação, e mantido para manter compatibilidade.
• oauth_token: O valor de token utilizado para associar o pedido com o
proprietário do recurso. Se o pedido não está associado a um
proprietário do recurso (nenhum token disponível), os clientes devem
omitir o parâmetro.
• oauth_signature_method: O nome do método de assinatura utilizado
pelo cliente para assinar o pedido.
• oauth_timestamp: Valor de estampa de tempo.
• oauth_nonce: Valor nonce.
• oauth_version: Valor opcional, caso esteja presente deverá ser
definido como “1.0”. Fornece a versão do processo de autenticação a
ser utilizado.
2. Os parâmetros de protocolo são adicionados ao pedido utilizando algum
método de transmissão. Cada parâmetro não deve aparecer mais de uma
vez no pedido .
3. O cliente calcula e define o valor do parâmetro “oauth_signature” e
adiciona o parâmetro ao pedido utilizando o mesmo método do passo
anterior .
4. O cliente envia o pedido HTTP autenticado para o servidor.
Para efetuar o pedido HTTP autenticado do Quadro 9, conforme OAuth
(2010), o cliente deverá definir os parâmetros do protocolo do Quadro 10, utilizando

32

suas credenciais de cliente, credenciais de token, a estampa de tempo atual, um
valor nonce gerado automaticamento e indica que o método de assinatura será o
“HMAC-SHA1”.

POST /request?b5=%3D%253D&a3=a&c%40=&a2=r%20b HTTP/1.1
Host: example.com
c2&a3=2+q
Quadro 9: Pedido HTTP
Fonte: OAuth (2010)

oauth_consumer_key: 9djdj82h48djs9d2
oauth_token: kkk9d7dh3k39sjv7
oauth_signature_method: HMAC-SHA1
oauth_timestamp: 137131201
oauth_nonce: 7d8f3e4a
Quadro 10: Parâmetros de Protocolo
Fonte: OAuth (2010)

O cliente adiciona parâmetros do protocolo para o pedido utilizando o campo
de cabeçalho HTTP do OAuth “Authorization”, conforme ilustrado no Quadro 11.
(OAUTH, 2010)

oauth_consumer_key="9djdj82h48djs9d2",
oauth_token="kkk9d7dh3k39sjv7",
oauth_signature_method="HMAC-SHA1",
oauth_timestamp="137131201",
oauth_nonce="7d8f3e4a"
Quadro 11: Pedido HTTP com o Parâmetro de Autorização
Figura: OAuth (2010)

Por último o cliente calcula o valor do parâmetro “oauth_signature”,
adiciona-o ao pedido e envia o pedido HTTP ilustrado no Quadro 12 ao servidor.
(OAUTH, 2010)

33

POST /request?b5=%3D%253D&a3=a&c%40=&a2=r%20b HTTP/1.1
Host: example.com
oauth_consumer_key="9djdj82h48djs9d2",
oauth_token="kkk9d7dh3k39sjv7",
oauth_signature_method="HMAC-SHA1",
oauth_timestamp="137131201",
oauth_nonce="7d8f3e4a",
oauth_signature="bYT5CMsGcbgUdFHObYMEfcx6bsw%3D"

c2&a3=2+q
Quadro 12: Pedido HTTP autorizado completo
Fonte: OAuth (2010)

2.8.8 Experiência do Usuário

Quando o OAuth é utilizado em uma aplicação, a experiência para o usuário
final que interage com a aplicação é muito menos intrusiva e complicada do que o
processo necessário para o desenvolvimento da mesma. (LEBLANC, 2011)
Implementações da tela de permissão, onde usuários permitem que uma
aplicação façam ações em seu nome, podem variar muito dependendo da
plataforma onde ela é implementada, mas o princípio básico é o mesmo. A
plataforma exibe uma página contendo uma informação básica sobre a aplicação e
fornece meios para que o usuário possa permitir ou negar que a aplicação utilize
seus dados pessoais. (LEBLANC, 2011)
Leblanc (2011, p. 327) destaca as telas de autorização de algumas
plataformas que utilizam o OAuth, na Figura 1 é apresentada a tela de autorização
do Twitter e na Figura 2 é apresentada a tela do Yahoo!.

34

Figura 1: Tela de Autorização do Twitter
Fonte: Leblanc (2011)

No caso da implementação do Yahoo!, o usuário primeiramente deve
informar seu usuário e senha e, posteriormente, ele será redirecionado para a tela
de permissão. Nesta tela também são exibidas as aplicações necessárias para o
fornecimento de dados da aplicação que está requisitando autorização. (LEBLANC,
2011)

35

Figura 2: Tela de Autorização do Yahoo!
Fonte: Leblanc (2011)

36

3 PROCEDIMENTOS METODOLÓGICOS

Para a realização do estudo de caso proposto neste trabalho foram adotados
métodos que envolvem desde a parte de pesquisa até os estudos tecnológicos e a
utilização de uma estrutura física para o correto funcionamento das implementações.
O objetivo deste capítulo é descrever detalhadamente cada um dos procedimentos
adotados, assim como as principais justificativas das escolhas tecnológicas deste
estudo.

3.1 PROCEDIMENTOS DE PESQUISA

Tratando-se dos procedimentos de pesquisa será utilizado, inicialmente, a
pesquisa bibliográfica, por ser “[...] desenvolvida com base em material já elaborado
constituído principalmente de livros e artigos científicos.” (GIL, 2002). Posterior à
etapa da pesquisa bibliográfica, será adotada a pesquisa experimental porque,
segundo Gil (2002), consiste em determinar um objeto de estudo, selecionar as
variáveis que seriam capazes de influenciá-lo, definir as formas de controle e de
observação dos efeitos que a variável produz no objeto.

3.1.1 Tipo de Pesquisa

Quanto a natureza da pesquisa ela pode ser classificada como aplicada pois
“[...] é feita a partir de objetivos que visam sua utilização prática. Valem-se essas
pesquisas das contribuições das teorias e leis já existentes.” (PARRA FILHO et al,
2001).
Quanto aos objetivos, esta pesquisa classifica-se como exploratória pois “[...]
têm como objetivo proporcionar maior familiaridade com o problema, com vistas a
torná-lo mais explícito ou a constituir hipóteses.” (GIL, 2002).

3.2 ESTRUTURA FÍSICA

A estrutura física utilizada para o desenvolvimento e testes das aplicações é
composta de um notebook doméstico com sistema operacional GNU/Linux Ubuntu

37

11.10, os navegadores de internet Opera 11 e Chromium, e a rede utilizada é a Fast
Ethernet 100.
A configuração de hardware do notebook utilizado para o desenvolvimento e
testes é a seguinte:
• CPU Pentium Dual Core T2130 1.86GHz;
• 2 GB de memória DDR2 667MHz;
• HD de 160 GB SATA.

3.3 TECNOLOGIAS

Para a implementação das aplicações que são objetos de estudo deste
trabalho foram utilizadas diversas tecnologias que, juntas, fornecem o correto
funcionamento do protocolo OAuth e das funcionalidades desenvolvidas em cada
aplicação.

3.3.1 Java

De acordo com a Sun Microsystems (atualmente Oracle) o Java é um
ambiente de programação simples, robusto, orientado a objetos, independente de
plataforma, dinâmico e de propósito geral. Esta definição permitiu ao Java crescer e
se expandir para diversos nichos. Atualmente ele é utilizado em plataformas
empresariais e em pequenos dispositivos. Para que o Java suporte esta gama de
ambientes diversas interfaces de programação de aplicações (APIs) e versões foram
desenvolvidas. (SPELL, 2005)
Segundo Spell (2005) a arquitetura Java completa é composta por quatro
componentes:
• A linguagem de programação Java;
• O formato de arquivo de classe Java;
• As APIs Java compostas por Java 2 Platform – Standard Edition (J2SE),
Java 2 Platform – Enterprise Edition (J2EE) e Java 2 Platform – Micro
Edition (J2ME);
• E a máquina virtual do Java (JVM).

38

3.3.2 Spring MVC e Spring Security

O Spring Framework é uma solução leve utilizada para desenvolver
aplicações corporativas. Ele é modular, permitindo a utilização apenas das partes
necessárias, sem a necessidade de utilizar o pacote completo. O Spring Framework
suporta gerenciamento transacional declarativo, acesso remoto à lógica com RMI e
web services, e diversas opções de persistência de dados. Além disso ele oferece
um framework MVC completo, e habilita a utilização de linguagem orientada a
aspectos (AOP) transparentemente no software. O componente de Inversion of
Control (IoC) provê um meio de injetar dependências de uma classe utilizando meios
formais de compor componentes diferentes em uma aplicação totalmente funcional
pronta para utilização. (SPRING, 2010)
Spring MVC é um componente do framework projetado para auxiliar e
facilitar o desenvolvimento de aplicações web, oferecendo uma ferramenta para
desenvolver aplicações flexíveis e com baixo acoplamento, assim como o próprio
Spring Framework é. Ele fornece funcionalidades de gerenciar o estado, fluxo de
trabalho, validação. (WALLS, 2011)
Spring Security é outro componente do framework que oferece diversos
recursos que permitem que práticas de segurança comuns possam ser declaradas
ou configuradas de uma forma direta e declarativa. Com o Spring Security é possível
mapear usuários a classes da aplicação, definir níveis de autorização a papéis de
usuário, definir papéis de usuários às classes, aplicar regras de autenticação por
todos os recursos da aplicação, assim como regras de autorização e prevenir tipos
comuns de ataque com o intuito de manipular ou roubar a sessão dos usuários.
(MULARIEN, 2010)
O componente Spring Security OAuth fornece uma implementação do
protocolo OAuth ao Spring Security. Ele suporta a especificação 1.0 e a 2.0, que
ainda está em fase de desenvolvimento. Ele suporta componentes para consumir e
fornecer serviços de autenticação que suportam OAuth. (SRINGOAUTH, 2010)

3.3.3 Hibernate

O Hibernate é uma solução de Mapeamento Objeto-Relacional (ORM) para

39

ambientes Java. O termo Mapeamento Objeto-Relacional refere-se à técnica de
mapear dados de um modelo de representação em objetos para um modelo de
representação relacional (e vice e versa). Além do Hibernate lidar com este
mapeamento ele também provê recursos para consulta e obtenção de dados. O
Hibernate ajuda no encapsulamento de código SQL específico dos bancos de dados,
abstraindo os mesmos do desenvolvedor, e fornece integração com diversos
sistemas gerenciadores de banco de dados. (HIBERNATE, 2010)

3.3.4 PHP

PHP é uma linguagem de script amplamente utilizada, especialmente
adequada para o desenvolvimento web e pode ser incorporada ao HTML. O que
diferencia o PHP de linguagens como o Javascript é que ele é executado no
servidor, gerando o código HTML final que será enviado ao cliente. O cliente
receberá o resultado da execução do script, mas não saberá o código que gerou
este resultado. O PHP pode ser utilizado para, entre outras coisas, coletar dados de
formulários, gerar conteúdo de páginas dinamicamente, enviar e receber cookies e
manipular banco de dados. (PHP, 2011)

3.3.5 Zend Framework

Zend Framework é um framework de código aberto utilizado no
desenvolvimento de aplicações e serviços web utilizando a linguagem PHP na
versão 5. O framework é desenvolvido utilizando um código totalmente orientado a
objetos. A estrutura de componentes fornecida pelo Zend Framework foi projetada
de forma a diminuir a dependência entre eles, permitindo a utilização de
componentes individuais. O framework também fornece uma implementação robusta
e de alta performance do padrão MVC, além da abstração com o banco de dados,
componentes para formulários com validação e filtros, componentes de autenticação
e autorização, incluindo suporte ao protocolo OAuth. (ZEND, 2010)

40

3.3.6 Play Framework

O Play Framework é uma alternativa limpa para o conjunto inchado do Java
Enterprise. Seu principal foco é a produtividade do desenvolvedor e sua meta é
arquiteturas REST. O Play é um ótimo auxiliar para o desenvolvimento ágil de
software. Seu principal objetivo é facilitar o desenvolvimento de aplicações web e, ao
mesmo tempo, se manter alinhado ao Java. Ele foi escrito puramente em Java, e
mantém bibliotecas e ferramentas comuns deste ecossistema. O framework compila
os fontes Java diretamente e recarrega-os na JVM sem a necessidade de reiniciar o
servidor. Ele provê um mecanismo eficiente de templates com a linguagem Groovy,
que possui uma sintaxe muito consistente ao Java, além de fornecer JPA como a API
de mapeamento objeto-relacional, utilizada na persistência de dados. (PLAY, 2010)

3.3.7 HTML 5 e CSS3

HyperText Markup Language 5 (HTML5) e Cascading Style Sheets 3 (CSS3)
são dois padrões novos propostos pela World Wide Web Consortium (W3C). Essas
tecnologias são a evolução das tecnologias utilizadas no dia a dia de envolvidos com
a internet, e existem para ajudar na construção de aplicações web modernas e
inovadoras. Diversas novas funcionalidades ajudam na melhora da sintaxe da
linguagem, assim como adicionam um suporte maior a animações interoperáveis
(independentes de plugins de terceiros), trazem novas funcionalidades para
utilização de sockets, armazenamento offline, melhorias de formulários e muito mais.
(HOGAN, 2010)
O CSS3 adiciona novos seletores para melhorar a estilização de
componentes, como, por exemplo, até a identificação de colunas pares e ímpares de
uma tabela. A nova versão do CSS também traz efeitos visuais sofisticados, como
sombras, gradientes, cantos arredondados e etc. Ambas as novas tecnologias ainda
são trabalhos em andamento, porém cada vez mais as ferramentas de acesso à
internet (como navegadores) estão adotando e suportando essas tecnologias.
(HOGAN, 2010)

41

3.3.8 MySQL

O software MySQL provê um servidor de banco de dados Structured Query
Language (SQL) robusto, multi-usuário, rápido e eficaz. Ele é indicado para sistemas
em produção de alta carga assim como para incorporação em massa de sistemas já
implantados. O servidor MySQL possui uma licença comercial, fornecida pela Oracle
e uma versão de código-aberto. (MYSQL)

3.4 JUSTIFICATIVAS TECNOLÓGICAS

O protocolo OAuth foi escolhido principalmente por sua facilidade de
implementação, tanto na parte servidor quanto para os consumidores. Quando
comparado ao OpenID e CAS, a implementação de um servidor de recursos se
mostra menos complexa. Outro motivo é que grandes empresas utilizam o OAuth
em casos de sucesso, como o Facebook ou Twitter. E, finalmente, o protocolo OAuth
utiliza padrões abertos como HTTP junto com todos os seus recursos e permite
grande flexibilidade com relação a mecanismos de criptografia, e exigências de
obrigatoriedade de parâmetros, ficando a cargo do desenvolvedor decidir o que é
mais adequado para o seu caso.
A tecnologia Java foi escolhida para ser utilizada na aplicação servidor de
OAuth principalmente por ser uma das mais utilizadas no ambiente corporativo, que
é o ambiente ideal para a implantação do OAuth, principalmente por, na maioria dos
casos, um ambiente corporativo ser dividido em diversas aplicações independentes
entre si, mas que utilizam uma base de autenticação de usuários. Junto com o Java,
foram utilizados os frameworks Spring, Spring Security com Spring Security OAuth e
JPA com Hibernate.
O Spring e Spring Security com o módulo OAuth foram utilizados para prover
meios de autenticação, segurança das funcionalidades, recursos web para cadastro
de usuários, injeção de dependências, mapeamento de URL e gerencia de beans. O
Hibernate foi o escolhido por suportar a especificação Java Persistence API (JPA),
suportar diversos bancos de dados e fornecer recursos para consultas e
mapeamento objeto-relacional.
O PHP foi utilizado, em conjunto com o Zend Framework, para desenvolver

42

a aplicação de controle de finanças, e ambos foram escolhidos pela baixa curva de
aprendizado, por sua robustez e produtividade. O Zend Framework é desenvolvido
pela Zend, principal mantenedora da linguagem PHP, e é muito bem projetado, com
uma estrutura de componentes similar ao Spring.
O Play! Framework foi escolhido devido à sua simplicidade, alta
produtividade, sintaxe limpa de templates (graças ao Groovy), integração nativa com
JPA, mapeamento de requisições, e por sua fácil integração com o OAuth.
HTML5 e CSS3 foram as linguagens escolhidas para a parte de visualização
das aplicações. Foram utilizados seletores avançados do CSS3, validação nativa do
HTML5, novas tags, cantos arredondados, sombras e gradientes.
O banco de dados MySQL foi escolhido por sua fácil integração com cada
uma das tecnologias utilizadas nas aplicações.

43

4 IMPLEMENTAÇÃO

Este capítulo descreve as três aplicações desenvolvidas para demonstrar o
funcionamento do protocolo OAuth. Cada aplicação foi construída em um escopo
separado visando demonstrar a capacidade de integração das tecnologias com o
protocolo OAuth e os recursos básicos necessários para um provedor de
autenticação. Foram elaboradas as seguintes aplicações, explanadas mais
detalhadamente a seguir:
• Servidor de Autenticação OAuth: Fornece as capacidades de autenticação
utilizando o protocolo OAuth;
• Agenda de contatos: Uma aplicação de agenda de contatos simples que
se autentica com o servidor de autenticação OAuth;
• Controle de Finanças: Uma aplicação para controle de finanças, utiliza o
servidor de autenticação OAuth para permitir sua utilização.

4.1 SERVIDOR DE AUTENTICAÇÃO

O servidor de autenticação foi desenvolvido com o propósito de fornecer o
endpoint de autenticação para consumidores OAuth. Sua estrutura foi definida
utilizando o framework Spring MVC, com o padrão arquitetural Model-View-
Controller (MVC), além de definir serviços, entidades e repositórios conforme
apresentado na Figura 3.

44

Figura 3: Arquitetura Definida
Fonte: Autoria Própria

4.1.1 Configuração do Spring Security e OAuth

Para fornecer os recursos de segurança e proteção de acessos foi utilizado
o framework Spring Security, em conjunto com o componente Spring Security OAuth.
Para configurá-los é necessário definir um arquivo XML com todos os parâmetros de
configuração necessários para a aplicação. O Quadro 13 apresenta o arquivo de
configuração utilizado na aplicação.

45

<security:http pattern="/resources/**" security="none" />
<security:http pattern="/user/login*" security="none" />
<security:http auto-config="true" access-denied-page="/user/login" use-
expressions="true">
<security:intercept-url pattern="/oauth/**"
access="isAuthenticated()" />
<security:intercept-url pattern="/request_token_authorized.jsp"
<security:intercept-url pattern="/dashboard"
<security:intercept-url pattern="/index.jsp"
<security:intercept-url pattern="/user/profile"
<security:intercept-url pattern="/user/info/**"
<security:intercept-url pattern="/**" access="hasRole('ROLE_ADMIN')" />
<security:form-login default-target-url="/" authentication-failure-
url="/user/login?login_error=1" login-page="/user/login" login-processing-
url="/login.do" />
<security:logout logout-success-url="/user/login" logout-
url="/logout.do" />
</security:http>
<security:authentication-manager>
<security:authentication-provider user-service-ref="userService">
<security:password-encoder ref="passwordEncoder" hash="md5" />
</security:authentication-provider>
</security:authentication-manager>
<oauth:provider consumer-details-service-ref="consumerDetails" token-
services-ref="tokenServices" request-token-url="/oauth/request_token"
authenticate-token-url="/oauth/authorize" authentication-failed-
url="/oauth/confirm_access" access-granted-
url="/request_token_authorized.jsp" access-token-url="/oauth/access_token"
require10a="false" />
<oauth:consumer-details-service id="consumerDetails">
<oauth:consumer name="Contas.tcc" secret="oauth-tcc-secret-01"
key="contas-consumer-key" resourceName="Seu Perfil"
resourceDescription="Dados do seu perfil de usuário" />
<oauth:consumer name="Agenda.tcc" secret="oauth-tcc-secret-02"
key="agenda-consumer-key" resourceName="Dados Pessoais"
resourceDescription="Seus dados pessoais" />
</oauth:consumer-details-service>
<oauth:token-services id="tokenServices" />
<bean id="passwordEncoder"
class="org.springframework.security.authentication.encoding.Md5PasswordEnc
oder" />
Quadro 13: Arquivo de Configuração do Spring Security

Os principais pontos a se destacar neste arquivo de configuração são os
parâmetros com o prefixo “security:”. Primeiramente são definidos dois endpoints
que não terão segurança: a pasta de imagens, arquivos de folhas de estilos e
javascript nomeada “resources”, e o endereço utilizado para acessar o formulário de
autenticação “/user/login”.

46

A próxima etapa é adicionar restrições para que os endereços internos do
sistema só possam ser acessados por usuários autenticados. Os endereços que
contém as palavras “oauth”, “request_token_authorized.jsp”, “dashboard”,
“index.jsp”, “user/profile”, “user/info” serão protegidos pelo framework de
segurança, exigindo que um usuário esteja autenticado para acessar algum destes
endereços. Também é definido o endereço para o formulário de autenticação.
Após definir a configuração de recursos protegidos, é necessário configurar
o serviço que fornece os meios de autenticação do usuário. Neste caso foi definido
um serviço customizado, contendo o código apresentado no Quadro 14, assim como
um bean para criptografia de senha.
As próximas linhas definem a configuração do provedor de OAuth da
aplicação. É necessário definir o serviço que fornece dados dos consumidores
suportados pela aplicação. Somente os consumidores definidos na tag “consumer-
details-service” poderão consumir o serviço de autenticação, requisitando a
autorização de acesso pelo proprietário do recurso autenticado. Para este trabalho
foram definidos dois consumidores: uma aplicação de finanças e outra de agenda de
contatos.
O parâmetro “token-services-ref”, define o serviço que fornecerá as
funcionalidades para:
• Gerar credenciais temporárias;
• Gerar tokens de acesso;
• Verificar a validade dos tokens;
• Vincular consumidores, proprietários de recursos e tokens.
Para a aplicação desenvolvida, foi utilizada a classe
“InMemoryProviderTokenServices”, que é um serviço de tokens nativo da
biblioteca Spring Security OAuth, que armazena em memória os tokens gerados e
utiliza mecanismos de tempo para validar um token utilizado para uma tentativa de
autorização ou para uma requisição autenticada.
Os demais parâmetros definidos na tag “provider” definem os endpoints
para, respectivamente, a requisição de tokens temporários, a autenticação
autorizada por um proprietário do recurso, a página de autorização de um
consumidor pelo proprietário do recurso, a página de confirmação de que o acesso

47

foi concebido (caso não seja definido o parâmetro “oauth_callback”) e o endereço
para obter as credenciais de token.

4.1.2 Autenticação de Usuários

O arquivo de configuração do Spring Security, define um serviço de
autenticação de usuários, que nada mais é do que um bean que implementa a
interface UserDetailsService e o método loadByUsername. O Quadro 14 mostra
um trecho do serviço implementado, que busca na base de dados por um nome de
usuário passado como parâmetro do método.

@Service("userService")
public class UserServiceImpl implements UserService
{
@Autowired
private UserRepository userRepository;

@Override
public UserDetails loadUserByUsername(String username)
{
return userRepository.findByUsername(username);
}
}
Quadro 14: Serviço de Usuário

O banco de dados da aplicação é composto apenas por uma tabela de
usuários e para manipular esta tabela foi implementado um repositório, que utiliza o
EntityManager fornecido pelo Hibernate para efetuar uma consulta baseando-se no
nome de usuário passado como parâmetro. O código deste repositório é

48

@Repository
public class UserRepository extends AbstractRepository<User> {
public User findByUsername(String username) {
try {
TypedQuery<User> query = this.entityManager.createQuery("select u
from User u where u.username = :username", User.class);
query.setParameter("username", username);
return query.getSingleResult();
} catch (NoResultException e) {
return null;
}
}
}
Quadro 15: Repositório de usuários

No Quadro 16 é apresentado o código do formulário de autenticação,
utilizando HTML5. Foram utilizados os novos atributos da tecnologia que permitem
que o próprio navegador de internet faça a validação dos campos, sem a
necessidade de programar Javascript para essa funcionalidade. Também foram
utilizadas as tags novas que dão mais semântica ao código implementado.

<div class="login-wrapper">
<header>
<h1>MyPortal - Login</h1>
<c:if test="${not empty param.login_error}"><div class="error">
Ocorreu um erro. Verifique seu usuário/senha.</div></c:if>
</header>
<section id="content">
<form method="post" action="<c:url value="/login.do"/>" class="form-
login">
<p>
<label for="username">Nome de Usuário:</label>
<input type="text" id="username" name="j_username"
required="required" />
</p>
<p>
<label for="password">Senha:</label>
<input type="password" id="password" name="j_password"
required="required" />
</p>
<p><input class="button blue" type="submit" value="Autenticar"
/></p>
</form>
</section>
</div>
Quadro 16: Tela com o Formulário de Login

O resultado deste código é apresentado na Figura 4. Esta tela de
autenticação é apresentada ao usuário ao se acessar alguma das aplicações

49

desenvolvidas e permite que o usuário forneça suas credenciais de acesso,
prosseguindo com o fluxo de autorização.

Figura 4: Tela de autenticação

4.1.3 Confirmação do Proprietário do Recurso

Para que o consumidor possa utilizar os dados do proprietário do recurso o
OAuth exige que, após efetuar a autenticação, o provedor apresente uma tela
solicitando ao proprietário do recurso se ele autoriza ou não o acesso do consumidor
aos seus dados. Para esta funcionalidade foi desenvolvido um controlador, que
responde à URL configurada no arquivo de configuração do Spring Security,
responsável por direcionar o usuário para a tela de confirmação de acesso da
aplicação, validar as credenciais e tokens temporários, e, também, revogar um
acesso a um token temporário. O Quadro 17, apresenta o código implementado para
este controlador.

50

@Controller
public class AccessConfirmationController
{
@Autowired
private OAuthProviderTokenServices tokenServices;
@Autowired
private ConsumerDetailsService consumerDetailsService;

@RequestMapping("/oauth/confirm_access")
public ModelAndView accessConfirmation(HttpServletRequest request,
HttpServletResponse response) throws Exception
{
String token = request.getParameter("oauth_token");
if (token == null) {
throw new IllegalArgumentException("Deve ser informado um token de
requisição");
}
OAuthProviderToken providerToken = tokenServices.getToken(token);
ConsumerDetails consumer =
consumerDetailsService.loadConsumerByConsumerKey(providerToken.getConsumer
Key());
String callback = request.getParameter("oauth_callback");
TreeMap<String, Object> model = new TreeMap<String, Object>();
model.put("oauth_token", token);
if (callback != null) {
model.put("oauth_callback", callback);
}
model.put("consumer", consumer);
return new ModelAndView("access_confirmation/confirm", model);
}
@RequestMapping("/oauth/revoke/{tokenValue}")
public ModelAndView accessRevoked(@PathVariable String tokenValue)
{

((OAuthProviderTokenImpl)this.tokenServices.getToken(tokenValue)).setTimes
tamp(0);
return new ModelAndView("access_confirmation/revoked");
}
}
Quadro 17: Controlador de Confirmação de Acesso

A primeira etapa é verificar se os parâmetros de token foram informados na
requisição, após isso o token é obtido do serviço definido no arquivo de
configuração, e logo após, os dados do consumidor são obtidos. Caso em alguma
dessas etapas algum dado não seja informado, será lançada uma exceção e o
código HTTP de erro será o “401” UNAUTHORIZED. Caso o parâmetro
“oauth_callback” esteja definido, ele será definido também na tela de autorização,
para que o Spring OAuth redirecione o usuário caso o mesmo permita o acesso do
consumidor.
O método de revogação de acesso, faz com que o token temporário expire

51

e, redireciona o usuário para informar que o consumidor foi revogado com sucesso.
O Quadro 18 apresenta o código da tela de autorização do proprietário do
recurso. Ele aponta o endereço para o endpoint definido de confirmação da
autorização do acesso. Caso exista o parâmetro “oauth_callback” o mesmo é
adicionado a um campo escondido do formulário, e internamente, o Spring Security
OAuth define este endereço como o ponto de redirecionamento após concluir o
processo de autorização.

<layout:page title="MyPortal - Autorizar Aplicação">
<jsp:body>
<h2>Confirmar Acesso</h2>
<p>Você confirma a autorização da
aplicação "<c:out value="${consumer.consumerName}"
/>" para acessar os seguintes recursos:</p>
<ul>
<li><c:out value="${consumer.resourceName}" /> — <c:out
value="${consumer.resourceDescription}" /></li>
</ul>
<form action="<c:url value="/oauth/authorize"/>" method="post">
<input name="requestToken" value="<c:out value="${oauth_token}"/>"
type="hidden" />
<c:if test="${!empty oauth_callback}">
<input name="callbackURL" value="<c:out value="$
{oauth_callback}"/>" type="hidden"/>
</c:if>
<p>
<input class="button blue" name="authorize" value="Autorizar"
type="submit" /> 
<a href="<c:url value="/oauth/revoke/${oauth_token}"/>"
class="button red">Revogar</a>
</p>
</form>
</jsp:body>
</layout:page>
Quadro 18: Formulário de Autorização de um Consumidor

A tela de autorização do proprietário do recurso é apresentada na Figura 5,
ela exibe as informações sobre a aplicação que está requirindo autorização do
proprietário do recurso autenticado, e as opções de autorizar ou revogar o acesso da
aplicação em questão.

52

Figura 5: Tela de autorização

Caso o proprietário do recurso revogue o acesso do consumidor ele será
mantido na aplicação servidor de OAuth, e será exibida a tela apresentada na Figura
6, que indica que o consumidor foi revogado com sucesso. Se o proprietário do
recurso autorizar o acesso do consumidor ele será redirecionado para as telas
principais do consumidor em questão. Essas telas são apresentadas na e .

Figura 6: Tela de acesso revogado

4.2 APLICAÇÃO 1: AGENDA DE CONTATOS

A primeira aplicação desenvolvida tem como foco principal fornecer uma
agenda simples de contatos. Ela foi desenvolvida utilizando o Play! Framework, junto
com seu módulo OAuth, e permite que o usuário, após a autenticação e autorização
do consumidor, mantenha uma lista de contatos com nome, endereço, telefone, e-
mail e data de nascimento de cada contato.
Os controladores possuem um método para verificar se existe um usuário

53

definido em sessão e, caso não exista, redireciona o usuário para que o mesmo faça
autenticação como proprietário do recurso e autorize o consumidor a obter os dados
do perfil do usuário. O código do Quadro 19 apresenta o método do controlador que
faz essa verificação, simplesmente validando um parâmetro da sessão.

@Before
static void checkAuthentication() throws Exception {
if (session.get("user") == null) AuthenticationController.auth();
}
Quadro 19: Método de verificação de usuário logado

Caso seja necessário efetuar a autenticação do proprietário do recurso com
o OAuth, o controlador de autenticação será executado, ficando responsável por
redirecionar o agente de usuário para o servidor Oauth, onde serão apresentadas ao
usuário as telas apresentadas nas Figuras 5 e 6, e obter o retorno do servidor.
O Quadro 20 apresenta o código utilizado para criar o cliente OAuth
utilizando o módulo disponível para o Play Framework onde os seguintes parâmetros
de configuração são definidos:
• Endereço para obter o token temporário;
• Endereço para obter o token de acesso;
• Endereço para obter a autorização do proprietário do recurso;
• Chave identificadora do consumidor;
• Segredo compartilhado do consumidor.
Após a criação do cliente OAuth, é criado um objeto que armazenará os
dados de credenciais de token. E, após isso, o método authenticate, redireciona o
usuário para o servidor OAuth, e define o endereço de retorno, a partir do parâmetro
“oauth_callback” da requisição, que apontará para o método callback, apresentado
no Quadro 21.

54

public static void auth() throws Exception {
if (session.get("user") != null)
ContatoController.index();

client = new OAuthClient("http://localhost:9090/tcc-oauth-
server/oauth/request_token", "http://localhost:9090/tcc-oauth-
server/oauth/access_token", "http://localhost:9090/tcc-oauth-
server/oauth/confirm_access", "agenda-consumer-key", "oauth-tcc-secret-
02");
credentials = new MyCredentials();
client.authenticate(credentials, "http://localhost:9000/auth/callback");
}
Quadro 20: Método de autenticação com o servidor OAuth

O método de retorno, irá obter o parâmetro “oauth_verifier”, que contém o
código de verificação indicando que o token para o consumidor em questão foi
definido e autorizado. Após obter o código verificador, o cliente OAuth obtém as
credenciais de token para, a partir deste ponto em diante, fazer requisições
autenticadas em nome do proprietário do recurso. A requisição efetuada obtém as
informações do perfil do proprietário do recurso, para definir em sessão o código
identificador do mesmo, o nome real e o nome de usuário utilizado por ele. Em
seguida são utilizados os componentes do Play! Framework para mapear a resposta
JSON retornada pelo servidor a um objeto do tipo User, são armazenados os dados
do usuário em sessão e o controlador principal é invocado.

public static void callback() throws Exception {
String verifier = params.get("oauth_verifier");
credentials = MyCredentials.find("byToken",
params.get("oauth_token")).first();
client.retrieveAccessToken(credentials, verifier);
HttpResponse response = client.sign(credentials,
WS.url("http://localhost:9090/tcc-oauth-server/user/info"),
"POST").post();
JsonElement json = new JsonParser().parse(response.getString());
User user = new Gson().fromJson(json.getAsJsonObject().get("user"),
User.class);
session.put("user_id", user.id);
session.put("user", user.username);
session.put("user_realname", user.realname);
ContatoController.index();
}
Quadro 21: Método de retorno do processo de autorização OAuth

Após concluir o fluxo de autorização e armazenar uma instância de User em
sessão é apresentada a tela principal do sistema ao usuário, ilustrada na Figura 7.

55

Figura 7: Tela inicial da aplicação de contatos

Nesta tela o usuário poderá ver com que credenciais se autenticou, e são
listados todos os contatos cadastrados pelo usuário autenticado. Ao acessar o botão
“Adicionar Novo” é apresentado o formulário de cadastro de um contato, conforme
apresentado na Figura 8.

Figura 8: Tela para Adicionar um Contato

56

4.3 APLICAÇÃO 2: CONTROLE DE FINANÇAS

A aplicação de controle de finanças tem como objetivo fornecer ao usuário o
cadastro de lançamentos de crédito e de débito e, baseando-se na soma dos
créditos e débitos, apresentar o saldo do mesmo, destacando se é positivo ou
negativo. Este aplicativo foi desenvolvido utilizando PHP 5.3 junto com o Zend
Framework e seus componentes Zend_Auth, Zend_Oauth_Consumer, Zend_Db e
Zend_Mvc. Assim como a aplicação de agenda de contatos, o controle de finanças
exige a autenticação e autorização do proprietário do recurso e, após isso, guarda
em sessão os dados de seu perfil. O banco de dados utilizado define apenas a
tabela de contas.
Seguindo o mesmo modelo da aplicação de contatos, o controle de finanças
faz a verificação se existe um usuário autenticado e, caso não exista, redireciona o
usuário para um controlador de autenticação que implementa um consumidor OAuth.
O Quadro 22 apresenta o plugin, configurado na pilha de plugins de controladores
do Zend Framework, que faz a verificação se o componente Zend_Auth possui uma
identidade definida e, caso não possua, muda a requisição para o controlador de
autenticação.

class FernandoMantoan_Auth_OAuth_Plugin extends
Zend_Controller_Plugin_Abstract
{
public function preDispatch(Zend_Controller_Request_Abstract $request)
{
$auth = Zend_Auth::getInstance();
if (!$auth->hasIdentity()) {
if ($request->getControllerName() != 'auth') {
$request->setControllerName('auth');
$request->setActionName('login');
$request->setModuleName('default');
}
} else if ($request->getControllerName() == 'auth' && $request-
>getActionName() == 'login') {
$redirector =
Zend_Controller_Action_HelperBroker::getStaticHelper('redirector');
$redirector->gotoSimple('index', 'bills');
}
}
}
Quadro 22: Plugin de verificação de usuário autenticado

Os parâmetros para a configuração do componente

Estudo de Caso de uma Estrutura de Autenticação Única utilizando o protocolo OAuth

Estudo de Caso de uma Estrutura de Autenticação Única utilizando o protocolo OAuth

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

En vedette

En vedette (7)

Similaire à Estudo de Caso de uma Estrutura de Autenticação Única utilizando o protocolo OAuth

Similaire à Estudo de Caso de uma Estrutura de Autenticação Única utilizando o protocolo OAuth (20)

Estudo de Caso de uma Estrutura de Autenticação Única utilizando o protocolo OAuth