OAuth 1.0 vs OAuth 2.0 - Principais diferenças e as razões para a criação de um novo protocolo de delegação de Credenciais

Sumário Introdu¸cão O protocolo OAuth 1.0 O protocolo OAuth 2.0 Problemas potenciais Conclusões
OAuth 1.0 vs OAuth 2.0 - Principais
diferen¸cas e as razões para a cria¸cão de um
novo protocolo de delega¸cão de credenciais.
João Alves
ISCTE-IUL
15 de Julho de 2011
João Alves ISCTE-IUL
OAuth 1.0 vs OAuth 2.0 - Principais diferen¸cas e as razões para a cria¸cão de um novo protocolo de delega¸cão de credenciais.

1 Introdu¸cão
Senhas
2 O protocolo OAuth 1.0
Papéis
Tokens e Credenciais
Conversa¸cão OAuth 1.0
Problemas com o OAuth 1.0
4 Problemas potenciais
5 Conclusões

Sumário
1 Introdu¸cão
Senhas
Papéis
4 Problemas potenciais
5 Conclusões

Desde que existem computadores que há utilizadores e senhas.
A gestão de senhas tem sido sempre uma questão complicada, pois
na maioria das vezes elas representam o elo mais fraco na cadeia
de seguran¸ca. Como demonstrado empiricamente no estudo
realizado por Hayashi, ”todos os participantes, excepto um
reutiliza as suas senhas para múltiplas contas/sistemas” e noutro
estudo feito por Gaw onde ”os participantes relataram ter apenas
algumas senhas únicas”.

Senhas
Schneier escreveu ”a abordagem tradicional para autentica¸cão é
uma senha”. Stallings escreveu ”A linha de frente de defesa contra
intrusos é o sistema de senhas”, Schneier destacou que
”infelizmente, o sistema utilizador/senha funciona pior do as
pessoas pensam”. Gollmann acredita que ”com as senhas, têm-se
observado um trade-off entre a complexidade das senhas e as
faculdades da memória humana em decorá-las”. Com base em
estudos Gaw demonstra que ”[...] as taxas de reutiliza¸cão de
senhas aumentaram porque as pessoas dispõem de mais contas,
mas não criam mais senhas.”.

Senhas
Se acrescentarmos a necessidade de dar o nosso próprio
utilizador/senha para uma entidade terceira executar uma açcão na
nossa informa¸cão seria realmente uma má ideia.
O protocolo OAuth vem como solu¸cão para este problema.
Este protocolo foi criado como um método standard para permitir
que os clientes acedam a recursos do servidor, em nome do
proprietário de um recurso (o utilizador). Tem a capacidade de
fazer isso sem dar ao cliente as credenciais do proprietário do
recurso.

No modelo tradicional de autentica¸cão cliente-servidor, o cliente
usa as suas credenciais para aceder aos seus recursos armazenados
pelo servidor. O OAuth introduz um terceiro papel com este
modelo: o proprietário do recurso. No modelo OAuth, o cliente
(que não é o proprietário do recurso, mas quem está a actuar em
seu nome) faz pedidos de acesso aos recursos controlados pelo
proprietário do recurso, mas armazenado pelo servidor (servidor de
recursos protegidos).

Para que o cliente possa aceder aos recursos, ele primeiro tem de
obter permissão do proprietário do recurso. Essa permissão é
expressa na forma de um Token e o correspondente segredo
partilhado (shared-secret). O objectivo do Token é tornar
desnecessária para o proprietário do recurso a partilha das suas
credenciais (utilizador/senha) com o cliente. Ao contrário das
credenciais do proprietário do recurso, os Tokens podem ser
emitidos com um âmbito restrito e vida útil limitada, e revogados
de forma independente.

Principais Caracteristicas:
Desenhado para HTTP
Deﬁnido no RFC 5849
Baseado em alguns protocolos propriet´arios (Google AuthSub,
API Flickr e Yahoo BBAuth)

Ao fornecer um Token e o correspondente segredo partilhado
(shared-secret) é poss´ıvel para o proprietário do recurso dar acesso
a um recurso protegido sem revelar as suas credenciais
(utilizador/senha) ao servi¸co final que vai aceder aos dados
(cliente). Para tudo isto é necessário que o servidor de recursos
protegidos e o cliente suportem o protocolo OAuth.
O Token adiciona uma vantagem adicional para o acesso
pretendido, por ser capaz de definir o âmbito do acesso e o per´ıodo
de tempo no qual é válido.

Papéis
Há três entidades principais envolvidas numa conversa¸cão OAuth:
Proprietário do recurso - o utilizador final;
Cliente - aquele que vai aceder aos recursos, tipicamente um
servidor;
Servidor de recursos protegidos - o servidor que alberga os
recursos do proprietário.
Estes papéis são usados em qualquer transaçcão OAuth. Por vezes,
o proprietário do recurso e o cliente são o mesmo.

O OAuth usa três tipos de credenciais:
Credenciais do Cliente
As credenciais do cliente são usadas para autenticar o cliente.
Credenciais de Token
As credenciais de Token são usadas em vez do nome do
proprietário dos recursos e da senha.
Credenciais temporárias
O processo de autoriza¸cão OAuth também usa um conjunto de
credenciais temporárias que são usadas para identificar o pedido de
autoriza¸cão.

A autentica¸c˜ao OAuth ´e o processo no qual os utilizadores
concedem acesso aos seus recursos protegidos sem partilhar as suas
credenciais com o cliente. O OAuth usa Tokens gerados pelo
Servidor de recursos protegidos em vez de credenciais do utilizador
em pedidos de recursos protegidos. O processo utiliza dois tipos de
Token: Tokens de pedido e Tokens de acesso.
Token de pedido
Utilizado pelo cliente para pedir ao utilizador para autorizar o
acesso aos recursos protegidos.
Token de Acesso
Utilizado pelo cliente para aceder aos recursos protegidos em nome
do utilizador.

Processo de Autentica¸cão
Todos os pedidos baseados em OAuth são muito parecidos. Está a
ser identificado um recurso para o qual se quer fazer um pedido, é
constru´ıda uma cadeia (string) que descreve o pedido e as suas
credenciais para fazê-lo, e então a cadeia (string) é assinada
usando um conjunto de segredos.
É como endere¸car uma carta onde o endere¸co e o carimbo não
descrevem apenas o destino, mas também o conteúdo.

Ciclo do pedido OAuth:
1 É pedido um Token de pedido e é especificado o seu retorno;
2 O utilizador é redireccionado para o ecrã de autoriza¸cão (no
Servidor de recursos protegidos);
3 Poderá neste momento receber uma chamada de retorno
numa URL que foi especificada em 1, ou o membro digita um
código PIN (autentica¸cão out-of-band);
4 Pedir Token de acesso;
5 Fazer chamadas à API do Servidor de recursos protegidos.

Figura: Fluxo de Autentica¸c˜ao OAUTH 1.0a

Conversa¸cão criptográfica complexa
A forma como o OAuth 1.0 é implementado torna a cria¸cão de
scripts complexa devido à conversa¸cão criptográfica envolvida na
negocia¸cão do Token.
suporte de aplica¸cões não-web
É necessário encaminhar o utilizador para abrir o browser para o
servi¸co desejado, autenticar com o servi¸co, e copiar o Token do
servi¸co de volta para a aplica¸cão.
Per´ıodo de vida longo dos Tokens
Os Tokens gerados por esta versão têm um per´ıodo de vida longo e
poderão ser usados por um longo per´ıodo de tempo.

Parsing complicado
Uma vez que esta versão do protocolo pode ser implementada
usando HTTP não criptografado, é necessário que a aplica¸cão use
hashs Token HMAC e cadeias de pedidos. Para o protocolo
funcionar é igualmente necessário fazer um conjunto especial de
açcões (parsing) que apresentam uma complexidade elevada.
Problemas de Escalabilidade
A escalabilidade é complexa devido à existência de um processo de
gestão do estado do protocolo nas diferentes etapas, com
credenciais temporárias e de acesso que possivelmente requerem a
emissão de credenciais de longa dura¸cão, que são menos seguras e
mais dif´ıceis de gerir (e sincronizar em grandes ambientes).

Além disso, o OAuth 1.0 requer que os pontos terminais protegidos
dos recursos tenham acesso às credenciais do cliente, a fim de
validar o pedido. Isto impossibilita a arquitectura t´ıpica da maioria
dos grandes fornecedores em que um servidor centralizado de
autoriza¸cão é usado para a emissão de credenciais, e um servidor
separado é usado para chamadas de API. O OAuth 1.0 requer o
uso dos dois conjuntos de credenciais: as credenciais do cliente e
as credenciais Token o que faz com que essa separa¸cão seja muito
complexa.

Principais caracteristicas:
Protocolo novo incompativel com o 1.0;
É o resultado de um trabalho colaborativo de um grande
número de empresas como Yahoo, Facebook, Salesforce,
Microsoft, Twitter, Deutsche Telekom, Intuit, Mozilla e
Google;
Adop¸cão rápida desta tecnologia por parte de Facebook,
Twitter e Google;
Ainda não se encontra na sua versão final.
No momento em que foi escrito este artigo, o protocolo ainda
estava em desenvolvimento sendo ainda um projecto IETF-draft.

Quatro áreas gerais onde mudou:
O SSL passou a ser necessário em todas as comunica¸cões
quando é necessário para gerar o Token;
As assinaturas não são necessárias para as chamadas à API a
partir do momento que o Token é gerado;
Apenas um Token de seguran¸ca, e a assinatura não é
necessária;
A separa¸cão de proprietário de recursos e servidor de
autoriza¸cão é clara.

Além de implementar todas as ”boas”caracter´ısticas de 1.0 são
criadas algumas novas:
Seis novos fluxos;
Tokens Bearer;
Assinaturas simplificadas;
Tokens de curta dura¸cão com autoriza¸cões de vida longa;
Separa¸cão de Papéis

Seis novos fluxos
User-Agent - para clientes que são executados dentro de um
agente de utilizador (geralmente um browser web).
Web Server - para clientes que fazem parte de uma aplica¸cão
de servidor web, acess´ıvel através de solicita¸cões HTTP.
Dispositivo - para clientes executados em dispositivos
limitados - requer acesso independente a um browser.
Utilizador e Senha - utilizado nos casos em que o utilizador
confia no cliente para lidar com as suas credenciais.
Credenciais clientes - o cliente usa suas credenciais para obter
um Token de acesso.
Afirma¸cão (assertion) - o cliente apresenta uma afirma¸cão
SAML para o servidor de autoriza¸cão.

Tokens Bearer
Op¸cão sem criptografia para autentica¸cão, que se baseia na
arquitectura existente cookie de autentica¸cão. Em vez de enviar os
pedidos assinados com segredos e HMAC Token, o Token é usado
como um segredo e enviado através de SSL.
Outros tipos de Tokens
MAC - é equivalente ao esquema de Token no OAuth 1.0
SAML - usa afirma¸cões SAML 2.0 em cada pedido como uma
forma de estabelecer a identidade do cliente.

Assinaturas Simplificadas
O Suporte à assinatura foi significativamente simplificado para
remover a necessidade de tratamento especial, codifica¸cão e
classifica¸cão dos parâmetros.
Tokens de curta dura¸cão com autoriza¸cões de vida longa
Em vez de emitir um Token de longa dura¸cão (normalmente por
um ano ou eterno), o servidor pode emitir um Token de acesso de
curta dura¸cão e uma vida longa do Token de actualiza¸cão.

Separa¸cão de papéis
O OAuth 2.0 separa o papel do servidor de autoriza¸cão responsável
pela obten¸cão da autoriza¸cão do utilizador e a emissão de Tokens
do servidor de recursos que trata das chamadas à API. Assim, e em
contraponto com o OAuth 1.0 existem claramente quatro papéis:
Proprietário do recurso - o utilizador final;
Cliente - aquele que precisa de aceder aos recursos,
tipicamente um servidor;
Servidor de recursos protegidos - o servidor que alberga os
recursos do proprietário;
Servidor de Autoriza¸cão - o servidor que emite os Tokens para
o Cliente.

Figura: OAuth 2.0 Protocol FLOW

O processo de conversa¸cão do protocolo pode ser descrito em seis
passos:
(A) O cliente solicita autoriza¸cão ao proprietário do recurso.
(B) O cliente recebe uma concessão de autoriza¸cão, que representa
a autoriza¸cão fornecida pelo proprietário do recurso.
(C) O cliente solicita um Token de acesso autenticando-se junto
do servidor com a concessão de autoriza¸cão.
(D) O servidor de autoriza¸cão autentica o cliente e valida a
concessão de autoriza¸cão, e se esta for válida emite o Token
de acesso.
(E) O cliente pede o recurso protegido ao servidor de recursos
protegidos e autentica-se com o Token de acesso.
(F) O servidor de recursos valida o Token de acesso, e se for
válido, serve o pedido.

Problemas potenciais:
Ataques de Phishing
CSRF, o Clickjacking

Conclusões
Neste momento, e atendendo a que o OAuth 2.0 ainda não é um
standard, as implementa¸cões que estiverem a ser desenvolvidas
devem ficar preparadas para serem ajustadas à medida que os
”servidores de recursos protegidos”e as APIs forem actualizando o
protocolo de acordo com a evolu¸cão do draft.
Por outro lado, a necessidade de utilizar um ou outro protocolo
está sempre dependente do que os grandes ”players” da Internet
disponibilizam e se os servi¸cos que se pretende consumir suportam
um protocolo ou outro. A t´ıtulo de exemplo o Twitter, o Facebook
e o Google já disponibilizam servi¸cos suportados somente em 2.0.

Conclusões
Caso seja necessário implementar as componentes de servidor de
recursos protegidos e servidor de autoriza¸cão (caso seja um servi¸co
na rede) faz todo o sentido usar o OAuth 2.0 dada a esperada
longividade que este irá ter face ao 1.0.
O grau de maturidade do draft – analisado o draft-ietf-oauth-v2-18
– apresenta já um aspecto bastante proximo do que será o
protocolo final publicado em RFC, ficando ainda por clarificar
alguns aspectos como o Registo dos Clientes, a defini¸cão do URI
de redireccionamento ou a defini¸cão de tipos de endpoints de
autoriza¸cão.

Obrigado. Quest˜oes?

OAuth 1.0 vs OAuth 2.0 - Principais diferenças e as razões para a criação de um novo protocolo de delegação de Credenciais

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to OAuth 1.0 vs OAuth 2.0 - Principais diferenças e as razões para a criação de um novo protocolo de delegação de Credenciais

Similar to OAuth 1.0 vs OAuth 2.0 - Principais diferenças e as razões para a criação de um novo protocolo de delegação de Credenciais (20)

More from Joao Alves

More from Joao Alves (7)

OAuth 1.0 vs OAuth 2.0 - Principais diferenças e as razões para a criação de um novo protocolo de delegação de Credenciais