Guia de Orientacao sobre OAuth e Seguranca de APIs v3

Wh i t e P a p e r

Guia de Orientação sobre OAuth e Segurança de APIs Simplifique a implementação do OAuth na sua empresa

Guia de Orientação sobre OAuth e Segurança de APIs

Copyright © 2014 da Layer 7, uma Empresa da CA Technologies (www.layer7.com) 2

Índice

O que é o OAuth? .......................................................................................................................................... 3

Você pode apresentar um exemplo simples do OAuth? .............................................................................. 4

Esse problema já não foi resolvido antes?.................................................................................................... 6

Quais as diferenças do OAuth 2.0 para as versões anteriores?.................................................................... 6

Por que é difícil fazer o OAuth? .................................................................................................................... 9

Como a Layer 7 me ajuda a implementar o OAuth? ................................................................................... 10

Qual é a vantagem de um OAuth Toolkit? .................................................................................................. 11

Como a Layer 7 ajuda nos casos de uso de duas ou três pernas do OAuth? .............................................. 11

Sobre a Layer 7 ............................................................................................................................................ 13

Entre em contato com a Layer 7 ............................................................................................................. 13

Informações Jurídicas ............................................................................................................................. 13



O que é o OAuth? O OAuth é um padrão emergente da Web para autorizar o acesso limitado a aplicativos e dados. Ele é

projetado de modo que os usuários possam conceder acesso restrito aos recursos que possuem (tais

como imagens que residem num site como o Flickr ou SmugMug) a um cliente externo com um local de

impressão de fotos. Antes era comum pedir ao usuário para compartilhar seu nome de usuário e sua

senha com o cliente, uma solicitação enganosamente simples que mascara um risco inaceitável para a

segurança. Ao contrário disso, o OAuth promove um modelo de privilégios mínimos, permitindo que um

usuário conceda acesso limitado aos seus aplicativos e dados através da emissão de um token com

recursos limitados.

O OAuth é importante porque coloca a gestão da delegação da Web nas mãos do verdadeiro dono do

recurso. O usuário liga os pontos entre as suas contas em diferentes aplicativos da Web, sem

envolvimento direto dos administradores de segurança em cada respectivo site. Essa relação pode ser

duradoura, mas pode ser facilmente encerrada a qualquer momento pelo usuário. Um dos grandes

avanços que o OAuth traz para a comunidade da Web é a formalização do processo de delegação da

correlação de identidades com os usuários.

O OAuth está rapidamente se tornando um padrão fundamental da Web moderna e tem crescido muito

além das suas raízes na mídia social. O OAuth passou a ser muito importante para a empresa;

seguradoras, operadoras de TV a cabo e até mesmo prestadores de serviços médicos estão usando o

OAuth para gerenciar o acesso aos seus recursos. Grande parte dessa adoção é promovida pela

necessidade das empresas de contemplar clientes e dispositivos móveis cada vez mais diversos,

especificamente. Essas empresas estão implementando APIs de maneira arrojada para atender esse

novo canal de distribuição, e o OAuth é a melhor prática para a autorização de APIs.

Mas é importante reconhecer que o OAuth é apenas um componente de uma solução completa de

controle de acesso e segurança de APIs. É fácil se concentrar nos detalhes do protocolo e perder de vista

o quadro geral da Gestão de APIs, que abrange tudo, desde o gerenciamento de usuários até a auditoria,

a limitação e a detecção de ameaças. Muitas vezes, as APIs representam um canal direto com aplicativos

corporativos essenciais. Elas precisam de uma solução de segurança de grande porte para protegê‐las.

A Layer 7 está empenhada em fornecer infraestrutura permitir que os aplicativos das empresas usem o

OAuth. Oferecemos soluções drop‐in (desde o nosso Proxy de API de baixo custo até o SOA Gateway e o

Mobile Access Gateway completos) que se integram totalmente aos investimentos já realizados na

tecnologia de gestão de identidade e acesso (IAM) para criar um modelo de autorização uniforme em

toda a empresa. Todas as soluções da Layer 7 para Gateway estão disponíveis como imagens virtuais

simples de implementar. A Layer 7 também oferece a flexibilidade de se integrar com implementações

de terceiros do OAuth, que podem não ser totalmente compatíveis com os padrões atuais. Dessa forma,

você fica isolado das mudanças provenientes de uma tecnologia em rápida evolução.

Este white paper da Layer 7 Technologies descreve o que é o OAuth e mostra como você pode fazer com

que o OAuth seja simples na sua empresa.



Você pode apresentar um exemplo simples do OAuth? A mídia social foi a maior das primeiras aplicações a adotar o OAuth. O Facebook e o Twitter devem

boa parte do seu sucesso ao fato de não serem simplesmente sites independentes, mas sim plataformas

que incentivam a integração com outros aplicativos. Os pontos de integração são APIs RESTful

que normalmente usam o OAuth como meio de autenticação, autorização e vinculação de diferentes

contas pessoais.

O Twitter e o Facebook são excelentes exemplos do OAuth na prática. Como muitas pessoas,

provavelmente você tenha contas separadas em ambas essas usinas de mídia social. Seus nomes de

contas podem ser semelhantes (e em nome de uma boa segurança, espero que você use senhas

diferentes), mas elas são contas distintas administradas em locais diferentes. Então, como é possível

organizar as coisas para que seus tweets apareçam instantaneamente no mural do seu Facebook?

Em outros tempos, provavelmente você precisaria armazenar seu nome de usuário e sua senha do

Facebook no seu perfil do Twitter. Dessa forma, sempre que você publicasse um novo tweet, o

aplicativo do Twitter poderia realizar o login para você publicá‐lo simultaneamente no Facebook. Essa

abordagem passou a ser conhecida como o "antipadrão" de senhas, e, por várias razões, não é uma boa

ideia. Confiar ao Twitter a sua senha do Facebook simplesmente confere poder demais a esse aplicativo.

Se um hacker quisesse comprometer o site ou se um administrador interno fosse desonesto, eles

poderiam usar sua senha sem criptografia para publicar fotos prejudiciais, trancá‐lo fora do Facebook ou

até mesmo apagar todo o seu perfil.

Felizmente, o Twitter e o Facebook usam o OAuth para superar esse problema. O OAuth tem um

modelo de autorização delegada que permite ao Twitter publicar no seu mural, e apenas isso. Isso é

mostrado na Figura 1 abaixo.

Figura 1: O OAuth permite que o Twitter publique tweets na sua conta do Facebook sem usar a sua senha

do Facebook.



Do ponto de vista do usuário, a interação é muito simples e intuitiva. Você pode acompanhá‐la na Figura

2 abaixo. Pelo painel de configurações do Twitter, o usuário clica num botão que o transfere para o

Facebook, onde ele poderá iniciar uma sessão. Isso cria uma associação entre duas contas separadas

desse usuário, sem nenhuma participação dos administradores de segurança do Facebook ou do

Twitter. Uma vez autenticado no Facebook, o usuário passa por uma cerimônia de consentimento, na

qual poderá escolher o subconjunto de privilégios que deseja conceder ao Twitter para permitir que o

aplicativo atue em seu nome. Finalmente, o usuário volta automaticamente ao Twitter, onde pode

recomeçar a publicar tweets, que, agora, também aparecem no seu mural do Facebook. A relação que

eles criaram persiste indefinidamente ou até que eles decidem desfazê‐la explicitamente, usando

controles que se encontram na página de configurações.

Figura 2: Como um usuário autoriza o Twitter a publicar tweets no seu mural do Facebook.

Para o usuário, é um processo simples e intuitivo e, de fato, é grande parte do apelo do OAuth. Mas nos

bastidores ocorre uma interação muito mais complexa entre os sites, muitas vezes chamada de "dança

do OAuth". “Tripé do OAuth" é o nome popular da situação descrita aqui. É o exemplo de uso mais

comum da especificação OAuth 1.0a, agora publicada como RFC 5849.

Essa especificação é detalhada, mas surpreendentemente limitada. Ela define o fluxo de

redirecionamento que permite a um usuário associar suas contas, autorizar um subconjunto limitado de

operações e devolver um token opaco que o Twitter pode manter de forma segura para o acesso, em

vez de uma senha onipotente. Ela ainda detalha (pelo menos na versão 1.0) um método para vincular o

token a um conteúdo de parâmetro utilizando assinaturas digitais, permitindo, assim, verificações de

integridade do conteúdo enviado através de canais sem criptografia.



Um dos pontos fortes da especificação OAuth 1.0a é que, ao invés de tentar definir uma estrutura de

autorização generalizada, ele se propõe a oferecer uma solução para o problema comum de projeto

descrito acima. Foi uma iniciativa de base de pessoas que tinham um problema a resolver, e o momento

foi perfeito. Não é surpresa nenhuma que ela tenha sido um sucesso estrondoso, implementada em

sites como o Google, DropBox, SalesForce, FourSquare e LinkedIn.

No entanto, o OAuth, está evoluindo. A versão 2, publicada em outubro de 2012, ambiciosamente

pretende contemplar um conjunto muito mais generalizado de casos de uso. Isso, naturalmente,

aumenta a complexidade da solução e contribui para a dificuldade enfrentada pelos desenvolvedores

que tentam implementá‐la para proteger as APIs das empresas.

Esse problema já não foi resolvido antes? Não existem processos formais e totalmente definidos para endereçar o problema da autorização

delegada que o OAuth resolve. Seus projetistas pensaram nas alternativas e apresentaram apenas um

punhado de soluções (completamente fechadas). A necessidade foi, certamente, a mãe da invenção do

OAuth, mas a abertura era um objetivo essencial.

Certamente é possível que a SAML, usada na maioria das vezes para o Login Único (SSO) federado,

pudesse ser usada como um formato de token para comunicar operações delegadas entre sites, usando

o tipo de token remetente‐comprovante. No entanto, a SAML não define sozinha o fluxo de interações

para estabelecer a relação de confiança ou a vinculação de contas. Além disso, sendo um formato XML

muito complexo, a SAML não se une com as práticas atuais de desenvolvimento centradas em princípios

RESTful e em estruturas de dados JSON simples.

O OpenID tentou oferecer uma Web com login único. Num mundo perfeito, onde o OpenID seria

universal, talvez o OAuth nunca tivesse sido necessário. Mas apesar do sucesso em sites influentes,

como o Yahoo e o WordPress, o OpenID nunca foi adotado de maneira generalizada. No entanto, o

OpenID pode ter uma segunda chance de sucesso pela maneira como ele complementa o OAuth.

Quais as diferenças do OAuth 2.0 para as versões anteriores? O OAuth 1 evoluiu muito rapidamente por causa da demanda. Ele oferecia uma solução para um

problema comum e sua adoção pelos principais aplicativos sociais deu‐lhe ampla exposição. A

implementação mais comum no momento é a 1.0a, que incorpora uma pequena modificação em

relação à especificação original, para tratar de uma vulnerabilidade de segurança.

A especificação 1.0a é bem projetada e completa, mas apenas para um conjunto restrito de casos de

uso. Sem dúvida, esse é um dos seus pontos fortes. Ele faz uma coisa só, mas faz muito bem. O OAuth

1.0 goza de amplo apoio, com bibliotecas disponíveis na maioria dos idiomas. Mesmo assim, ele sofre de

um aspecto bastante "artesanal", uma característica que pode atrair os desenvolvedores individuais,

mas deixa as empresas "na geladeira".



OAuth 1.0a tem algumas outras complexidades que têm impedido sua aceitação mais ampla. Ele leva aos clientes uma complexidade (especialmente em termos do processamento da criptografia) que pode ser difícil de programar usando linguagens como o JavaScript Por exemplo, o OAuth 1.0a exige que os clientes assinem parâmetros HTTP; essa é uma boa ideia para as transmissões sem criptografia (um padrão de uso comum na Web convencional), mas nem tanto com as APIs.

O próprio processo de assinatura é confuso por causa da necessidade de canonizar os parâmetros (por exemplo, normalizar a ordenação, lidar com seqüências de escape, etc.). Essa tem sido uma grande fonte de frustração para os desenvolvedores, pois, muitas vezes, os clientes e servidores de recursos interpretam de maneira diferente a aplicação das assinaturas.

Certamente existem bibliotecas que podem ajudar nesse caso, mas um problema maior é que a exigência de assinatura limita a capacidade dos desenvolvedores de testar as transações por meio de utilitários de linha de comando simples, como o cURL. Grande parte do que torna o estilo do RESTful mais atraente do que alternativas como os Serviços de Web SOAP é que o primeiro dispensa ferramentas especiais para programação. As assinaturas do OAuth atuam contra essa vantagem.

A especificação anterior também tinha uma visão limitada dos tipos de clientes. No caso mais limpo, do

tripé, o cliente era geralmente um aplicativo da Web. No entanto, os desenvolvedores queriam cada vez

mais usar o OAuth em aplicativos executados dentro de um navegador ou em aplicativos independentes

executados em dispositivos móveis, como telefones ou tablets. Isso é possível com o OAuth 1.0, mas a

experiência do usuário é ruim, pois pode envolver uma operação estranha de copiar e colar entre o

navegador e o aplicativo.

O Auth 2.0 tenta generalizar a implementação original do OAuth para simplificar o desenvolvimento de

clientes, melhorar a experiência geral do usuário e ampliar as implementações do OAuth. Isso exigiu

mudanças consideráveis e não retrocompatíveis com versões anteriores.

A nova especificação separa explicitamente as funções de autorização e de controle de acesso. Agora o

servidor de autorização é totalmente separado do servidor de recursos. Além da segregação lógica de

papéis, isso também promove o uso de um servidor central de autorização e a distribuição de vários

servidores de recursos, parecido com uma arquitetura clássica de SSO. Na verdade, um servidor de

autorização OAuth 2.0 éo equivalente RESTful de um serviço de token de segurança (STS).

Figura 3: O OAuth 2.0 faz uma distinção clara entre o servidor de autorização e o servidor de recursos, e ainda

define os fluxos que descrevem a aquisição do token.



O OAuth 2.0 tenta contemplar três perfis de clientes: aplicativos Web convencionais; aplicativos dentro

de um agente de usuário (isto é, um navegador da Web); aplicativos originais (como um aplicativo de

telefone celular, um set‐top box ou até mesmo um console de jogos). Cada um deles pode ter diferentes

recursos em termos de interação entre os proprietários dos recursos, os servidores de autorização e os

recursos protegidos. Cada um também pode estar sujeito a diferentes requisitos de segurança. A

especificação descreve uma série de novas concessões de autorização para atender a essas

necessidades diversas. As concessões descrevem um processo pelo qual um cliente pode adquirir acesso

autorizado a um recurso.

Essas concessões são as seguintes:

• Código de Autorização Esta concessão descreve a situação típica do tripé, na qual o cliente é um

aplicativo da Web, como o Twitter. Ele usa um código de autorização intermediário para delegar a

autorização com segurança de um servidor de autorização para um cliente, através do agente de

usuário do proprietário do recurso (navegador). Ele tem a vantagem de que as credenciais do

proprietário de um recurso nunca serão compartilhadas com o cliente, nem o token de acesso será

compartilhado com o agente de usuário do proprietário do recurso, onde ele poderia ser

sequestrado.

• Implícita Esta é uma concessão um pouco mais simples, mais adequada para aplicativos executados

dentro de um agente de usuário, tais como aplicativos em JavaScript. O cliente adquire

diretamente um token de acesso do servidor de autorização. Isso elimina grande parte da

complexidade do código de autorização intermediário, mas tem a desvantagem de que o

proprietário do recurso pode obter o token de acesso.

• Credenciais de senha do proprietário do recurso Nesta concessão, o proprietário do recurso

compartilha as credenciais diretamente com o cliente, que as utiliza para obter diretamente um

token de acesso, numa única transação. As credenciais não permanecem, pois o cliente usa o token

de acesso em todas as interações subsequentes com recursos protegidos. Este é um fluxo muito

simples, mas exige que haja confiança entre o proprietário de um recurso e um cliente.

• Credenciais do cliente Neste fluxo, o cliente usa suas próprias credenciais para acessar um recurso.

Assim, ele realmente usa os direitos existentes do cliente.

Além dessas concessões, existe um mecanismo de extensibilidade para contemplar outras formas de

autorização. Por exemplo, existe uma especificação de detentor de token em SAML que descreve o uso

de tokens SAML como meio de adquirir tokens de acesso do OAuth. Isso é muito importante porque

representa uma ponte entre a infraestrutura de SSO clássica dos navegadores e as APIs modernas.

Os tokens mudaram no OAuth 2.0 para melhorar o gerenciamento de sessões. Antes, os tokens de

acesso tinham uma vida muito longa (até um ano) ou, como é o caso do Twitter, eles tinham uma vida

útil ilimitada. O OAuth 2.0 introduz o conceito de tokens de curta duração e autorizações de longa

duração. Agora os servidores de autorização emitem tokens de atualização de cliente. Esses são tokens

de vida longa que um cliente pode usar várias vezes para adquirir tokens de acesso de curto prazo. Uma

das vantagens disso é que tanto os proprietários dos recursos como os administradores de segurança

podem facilmente, se precisarem, impedir que os clientes adquiram novos tokens.



Agora, as assinaturas de tokens são opcionais. A preferência é usar tokens simples de portador (ou seja,

o token é usado diretamente para obter acesso e é considerado secreto) protegidos por SSL. Isso é

muito mais simples do que processar assinaturas, embora esta última ainda exista numa forma

simplificada para permitir transações que não sejam por SSL.

Por que é difícil fazer o OAuth? Não é difícil criar uma prova de conceito simples do OAuth, pois há bibliotecas na maioria das principais

linguagens que podem ajudar com a dificuldade de escrever manualmente o código de uma

demonstração completa do OAuth. No entanto, implementar o OAuth em escala (em que o volume de

transações, o número de APIs a proteger e o número de clientes diferentes contribuem para a escala)

continua sendo um grande desafio para qualquer grupo de desenvolvimento e operações.

O OAuth 2.0 também é um alvo em movimento. A especificação 1.0a resolveu um problema, e resolveu‐

o bem. No entanto, o aumento da abrangência e a generalização da nova especificação criaram uma

ambiguidade considerável, que torna a interoperabilidade extremamente difícil. É por isso que muitos

aplicativos de redes sociais (o público principal do movimento do OAuth) permanecem na especificação

1.0, esperando que as coisas se acalmem.

A abertura de formatos de token ilustra isso muito bem. Embora, por um lado, isso tenha simplificado

muito o processo de assinatura, que era difícil para os desenvolvedores nas especificações anteriores,

também introduziu a capacidade de encapsular diferentes tokens (como a SAML), abrindo

oportunidades para aproveitar os investimentos já realizados, mas também criando problemas

consideráveis de interoperabilidade.

O maior erro que as pessoas cometem com o OAuth hoje em dia é olhar para ele de forma isolada. O

OAuth é, de fato, uma tendência convincente, mas é apenas uma peça do quebra‐cabeça do controle de

acesso nas empresas. A autorização não pode ser ditada exclusivamente pelo cliente. A empresa que

hospeda o recurso protegido também deve ter o controle. As implementações de OAuth com ponto

único raramente reconhecem essa via de mão‐dupla, mas a confiança e o controle recíprocos são

essenciais para a empresa.

O OAuth deve ser uma parte do sistema geral de controle de acesso por políticas para as APIs das

empresas, e não apenas uma solução independente. O controle de acesso por políticas dá a ambas as

partes o controle sobre o acesso. Ele incorpora controles tais como restrições por hora do dia e listas

brancas/negras de IP. Ele identifica e neutraliza ameaças como os ataques de Injeção de SQL ou Cross‐

Site Scripting (XSS). Ele compara os parâmetros e o conteúdo das mensagens (inclusive JSON ou XML)

com valores aceitáveis. Ele se integra totalmente com os sistemas de auditoria da empresa, de forma

que os fornecedores de recursos saibam exatamente quem está acessando o que e quando. E,

finalmente, um controle de acesso completo por políticas permite o gerenciamento de SLAs, moldando

as comunicações de rede, encaminhando as transações para os servidores disponíveis e limitando o

excesso de tráfego antes que ele possa afetar a experiência dos usuários ou ameaçar os servidores.



A empresa nunca pensaria em criar sua própria infraestrutura de IAM para seu site. Os arquitetos e

desenvolvedores reconhecem que isso é muito maior do que a autenticação básica simples de HTTP. O

OAuth é semelhante, enganosamente simples, mas, em última análise, uma parte de um processo geral

de autorização muito complexo.

Como a Layer 7 me ajuda a implementar o OAuth? A Layer 7 fornece uma solução completa, pronta para usar, para as implementações de OAuth 1.0a e

OAuth 2.0. O OAuth faz parte do mecanismo completo de controle de acesso por políticas do API Proxy,

SOA Gateway e Mobile Access Gateway da Layer 7. Esse é realmente o OAuth em escala, processando

dezenas de milhares de transações por segundo numa única instância de Gateway. Esses gateways

podem ser implementados como aplicativos físicos ou imagens virtuais de baixo custo. Ambos os

formatos levam uma infraestrutura de segurança de nível militar ao OAuth da empresa, incorporando

módulos de criptografia com certificação FIPS, detecção de ameaças avançadas, gerenciamento de

tráfego de SLA e controle de acesso individualizado, num único pacote. É como ter um guarda na sua

porta, em vez de apenas um cadeado.

Os Gateways da Layer 7 podem ser instalados tanto como servidores de autorização (SA) quanto como

servidores de recursos (SR) protegidos. Ambos os elementos de arquitetura podem ser combinados

numa única instância de Gateway, ou podem ser separados, permitindo que um SA centralizado atenda

a várias instâncias distribuídas de SR, como ilustra a Figura 4 abaixo.

Figura 4: Os gateways da Layer 7 simplificam a implementação do OAuth.



Como os Gateways são distribuídos em forma física e virtual; eles permitem a maior gama possível de

implementações. Os gateways físicos estão disponíveis com módulos de segurança de hardware (HSMs)

onboard, oferecendo proteção essencial para os ambientes mais seguros. Os appliances virtuais

simplificam a implementação e podem ser executados em qualquer lugar, do computador de mesa até a

infraestrutura de servidor de maior capacidade.

Qual é a vantagem de um OAuth Toolkit? O OAuth Toolkit da Layer 7 usa modelos padronizados, criados funcionar logo no início para

implementações típicas do OAuth. Usando‐os, os clientes podem incluir recursos robustos de OAuth nas

APIs existentes em questão de minutos, não de dias.

Porém, a verdade é que a solução de tamanho único prometida por tantos fornecedores raramente

funciona bem fora de uma situação de oportunidades inexploradas muito limitadas. Por exemplo, a

maioria dos projetos reais tem sistemas de identidade existentes que precisam acessar, ou

infraestruturas de PKI com as quais eles precisam se integrar. Como um setor, somos muito bons em

integração de aplicativos e dados; a integração de segurança continua sendo um problema.

Para enfrentar melhor esses problemas de integração, a Layer 7 também fornece componentes básicos

do OAuth, desde criptografia até canonização de parâmetros até o gerenciamento de sessões. Esses são

os mesmos componentes básicos usados em nossa solução completa e pronta para uso, mas surgiram

como afirmações completamente configuráveis dentro de uma política de controle de acesso. Isso

permite que os arquitetos e desenvolvedores ajustem suas implementações do OAuth para enfrentar

praticamente qualquer desafio que eles venham a encontrar.

Personalizar a cerimônia de autorização do OAuth é outra área que aproveita muito a abertura dos

modelos da Layer 7, complementada pelo poder de ferramentas flexíveis e abertas. Estabelecer a

confiança inicial é uma parte fundamental de todo o processo do OAuth. A Layer 7 permite que você

personalize totalmente essa etapa para garantir sua integração com a infraestrutura existente de

identidades e atende às necessidades de conformidade da empresa.

Como a Layer 7 ajuda nos casos de uso de duas ou três pernas do OAuth? Os Gateways da Layer 7 podem prestar serviços de autorização de terminais e controle de acesso para

serviços protegidos. Essas duas funções podem coexistir num único Gateway, ou podem ser separadas.

A vantagem de separá‐las diz respeito à escalabilidade, redundância e distribuição geográfica dos

serviços. Ele também permite o alinhamento em torno de casos de negócios, como a divisão física de

APIs corporativas e APIs públicas. A maioria das empresas tem um grande número de APIs a proteger,

muitas vezes fornecidas a partir de vários locais diferentes. Nesses casos, faz sentido instalar Gateways

centralizados da Layer 7 como servidores de autorização (muitas vezes num cluster para redundância) e

clusters remotos de Gateways para proteger instâncias específicas de APIs.



Figura 5: Implementação típica para a situação clássica de "duas pernas" ou concessões tais como credenciais de

proprietário do recurso e credenciais do cliente. Ambos os padrões de implementação podem atender simultaneamente as versões 1.0a e 2.0 do OAuth.

Esse padrão também funciona para as situações clássicas de duas e três "pernas", e com o modelo de

concessão do OAuth 2.0, inclusive concessões de extensão, como o token de portador da SAML. Essas

implementações são ilustradas na Figura 5 da página anterior e na Figura 6 abaixo.

Figura 6: Situações típicas de implementação em três pernas e a concessão do código de autorização, bem como

os tipos implícitos de concessão. Observe que os Gateways da Layer 7 pode reconhecer simultaneamente todas as

versões do OAuth, bem como as correlações personalizadas para dar conta de problemas de interoperabilidade.



Sobre a Layer 7 A premiada tecnologia de Gateway da Layer 7 possibilita que grandes empresas conectem com

segurança seus sistemas locais de TI com departamentos geograficamente dispersos, empresas

parceiras, desenvolvedores externos, aplicativos móveis e serviços na nuvem

Distribuídos nas versões física, de máquina virtual e de software, instalados no local ou na nuvem, os

Gateways da Layer 7 estão ajudando algumas das empresas mais preocupadas com a segurança do

mundo a compartilhar dados entre as fronteiras organizacionais.

Os principais institutos de análise, como Gartner e Forrester Research, reconheceram a Layer 7 como

líder nos mercados de Governança de SOA e Gestão de APIs. Entre os cliente da Layer 7 estão mais de

250 organizações dos setores público e privado de todo o mundo. Em junho de 2013, a Layer 7 foi

adquirida pela CA Technologies.

Entre em contato com a Layer 7

A Layer 7 agradece suas perguntas, comentários e opiniões em geral.

• E‐mail:

[email protected]

• Site da web:

www.layer7.com

• Telefone:

1‐604‐681‐9377

1‐800‐681‐9377 (chamada gratuita para a América do Norte)

• Endereço:

Suite 500 – 885 W Georgia Street Vancouver BC V6C 3G1 Canadá

Informações Jurídicas Copyright © 2014 da Layer 7, uma Empresa da CA Technologies. Conteúdo confidencial. Todos os direitos

reservados.

Guia de Orientacao sobre OAuth e Seguranca de APIs v3

Documents

Transcript of Guia de Orientacao sobre OAuth e Seguranca de APIs v3