Qual é a diferença entre OpenID e OAuth?

Estou realmente tentando entender a diferença entre OpenID e OAuth? Talvez sejam duas coisas totalmente separadas?

OpenID é sobre autenticação (por exemplo, provar quem você é), OAuth é sobre autorização (por exemplo, para conceder acesso à funcionalidade / dados / etc.) sem precisar lidar com a autenticação original.

OAuth poderia ser usado em sites parceiros externos para permitir o acesso a dados protegidos sem que eles precisassem autenticar novamente um usuário.

A postagem do blog " OpenID versus OAuth da perspectiva do usuário " tem uma comparação simples dos dois da perspectiva do usuário e " OAuth-OpenID: você está descascando a árvore errada se acha que são a mesma coisa " tem mais informações sobre isso.

Existem três maneiras de comparar o OAuth e o OpenID:

1. Finalidades

O OpenID foi criado para autenticação federada, ou seja, permitindo que terceiros autentiquem seus usuários para você, usando contas que eles já possuem . O termo federado é crítico aqui, porque o ponto principal do OpenID é que qualquer provedor pode ser usado (com exceção das listas brancas). Você não precisa pré-escolher ou negociar um acordo com os provedores para permitir que os usuários usem qualquer outra conta que eles possuam.

O Outh foi criado para remover a necessidade de os usuários compartilharem suas senhas com aplicativos de terceiros . Na verdade, ele começou como uma maneira de resolver um problema do OpenID: se você oferece suporte ao OpenID no seu site, não pode usar credenciais HTTP Basic (nome de usuário e senha) para fornecer uma API porque os usuários não têm uma senha no site.

O problema é que essa separação do OpenID para autenticação e do OAuth para autorização é que ambos os protocolos podem realizar muitas das mesmas coisas. Cada um deles fornece um conjunto diferente de recursos desejados por diferentes implementações, mas essencialmente são bastante intercambiáveis. Na essência, os dois protocolos são um método de verificação de asserções (o OpenID é limitado à asserção 'this is who sou sou', enquanto o OAuth fornece um 'token de acesso' que pode ser trocado por qualquer asserção suportada por meio de uma API).

2. Recursos

Ambos os protocolos fornecem uma maneira de um site redirecionar um usuário para outro lugar e voltar com uma afirmação verificável. O OpenID fornece uma asserção de identidade, enquanto o OAuth é mais genérico na forma de um token de acesso que pode ser usado para "fazer perguntas ao provedor do OAuth" . No entanto, cada um deles suporta recursos diferentes:

OpenID - o recurso mais importante do OpenID é seu processo de descoberta. O OpenID não exige codificação embutida em todos os provedores que você deseja usar antes do tempo. Usando a descoberta, o usuário pode escolher qualquer provedor de terceiros que deseje autenticar. Esse recurso de descoberta também causou a maioria dos problemas do OpenID, porque a maneira como ele é implementado é usar URIs HTTP como identificadores que a maioria dos usuários da Web simplesmente não obtém. Outros recursos que o OpenID possui é o suporte para registro ad-hoc de clientes usando uma troca DH, modo imediato para uma experiência otimizada do usuário final e uma maneira de verificar afirmações sem fazer outra ida e volta ao provedor.

OAuth - o recurso mais importante do OAuth é o token de acesso, que fornece um método duradouro de fazer solicitações adicionais. Ao contrário do OpenID, o OAuth não termina com autenticação, mas fornece um token de acesso para obter acesso a recursos adicionais fornecidos pelo mesmo serviço de terceiros. No entanto, como o OAuth não oferece suporte à descoberta, é necessário pré-selecionar e codificar os provedores que você decide usar. Um usuário que visita seu site não pode usar nenhum identificador, apenas aqueles pré-selecionados por você. Além disso, o OAuth não possui um conceito de identidade, portanto, usá-lo para fazer login significa adicionar um parâmetro personalizado (como feito pelo Twitter) ou fazer outra chamada de API para obter o usuário "logado" no momento.

3. Implementações técnicas

Os dois protocolos compartilham uma arquitetura comum no uso do redirecionamento para obter autorização do usuário. No OAuth, o usuário autoriza o acesso aos seus recursos protegidos e, no OpenID, à sua identidade. Mas isso é tudo que eles compartilham.

Cada protocolo possui uma maneira diferente de calcular uma assinatura usada para verificar a autenticidade da solicitação ou resposta e cada uma possui requisitos de registro diferentes.

O OpenID é (principalmente) para identificação / autenticação, para que stackoverflow.comeu saiba que possuo chris.boyle.name(ou onde quer que) e, portanto, sou provavelmente a mesma pessoa que possuiu chris.boyle.nameontem e ganhou alguns pontos de reputação.

O Outh é projetado para autorização para executar ações em seu nome, para que stackoverflow.com(ou onde quer que seja) possa solicitar permissão para, por exemplo, Tweet automaticamente em seu nome, sem saber sua senha do Twitter.

Muitas pessoas ainda o visitam, então aqui está um diagrama muito simples para explicar

Cortesia da Wikipedia

OAuth

Usado authorizationapenas para delegados - o que significa que você está autorizando um acesso de serviço de terceiros a usar dados pessoais, sem fornecer uma senha. Também as "sessões" do OAuth geralmente duram mais que as sessões do usuário. Significando que o OAuth foi projetado para permitir autorização

ou seja, o Flickr usa o OAuth para permitir que serviços de terceiros publiquem e editem uma imagem de pessoa em seu nome, sem que seja necessário fornecer seu nome de usuário e senha de cintilação.

OpenID

Usado para authenticateidentificar a identidade de logon único. Tudo o que o OpenID deve fazer é permitir que um provedor OpenID prove que você diz que é. No entanto, muitos sites usam autenticação de identidade para fornecer autorização (no entanto, os dois podem ser separados)

isto é, mostra-se o passaporte no aeroporto para autenticar (ou provar) quem é o nome da pessoa no bilhete que está usando.

Use o OAuth se seus usuários quiserem apenas fazer login no Facebook ou Twitter. Use o OpenID se seus usuários forem barba de pescoço que executam seus próprios provedores de OpenID porque "não querem que mais ninguém possua sua identidade".

• OpenID é um padrão aberto protocolo de autenticação e descentralizado controlado pela OpenID Foundation.
• OAuth é um padrão aberto para delegação de acesso.
• OpenID Connect (OIDC) Combina os recursos do OpenID e OAuth, isto é, autenticação e autorização.

O OpenID assume a forma de um URI exclusivo gerenciado por algum "provedor OpenID", ou seja, provedor de identidade (idP).

OAuth pode ser usado em conjunto com o XACML, em que o OAuth é usado para consentimento de propriedade e delegação de acesso, enquanto o XACML é usado para definir as políticas de autorização.

O OIDC usa JSON Web Tokens (JWT) simples, que você pode obter usando fluxos em conformidade com as especificações do OAuth 2.0 . O OAuth está diretamente relacionado ao OIDC, pois o OIDC é uma camada de autenticação criada sobre o OAuth 2.0 .

Por exemplo , se você escolheu entrar no Auth0 usando sua conta do Google, utilizou o OIDC . Depois que você se autenticar com sucesso no Google e autorizar o Auth0 a acessar suas informações, o Google enviará de volta ao Auth0 informações sobre o usuário e a autenticação realizada. Essas informações são retornadas em um JSON Web Token (JWT). Você receberá um token de acesso e, se solicitado, um token de identificação. Tipos de token : Fonte: OpenID Connect

Analogia :
Uma organização uso ID card para fins de identificação e contém fichas, ele armazena detalhes sobre Employee juntamente com autorização ie Campus / Acesso Portão / ODC. O cartão de identificação atua como um OIDC e o Chip atua como um OAuth . mais exemplos e formulário wiki

OpenID e OAuth são protocolos baseados em HTTP para autenticação e / ou autorização. Ambos têm o objetivo de permitir que os usuários executem ações sem conceder credenciais de autenticação ou permissões gerais a clientes ou terceiros. Embora sejam semelhantes e haja padrões propostos para usá-los juntos, eles são protocolos separados.

OpenID é destinado à autenticação federada. Um cliente aceita uma asserção de identidade de qualquer provedor (embora os clientes sejam livres para fornecedores de listas brancas ou negras).

OAuth é destinado à autorização delegada. Um cliente se registra com um provedor, que fornece tokens de autorização que ele aceita para executar ações em nome do usuário.

Atualmente, o OAuth é mais adequado para autorização, porque outras interações após a autenticação são incorporadas ao protocolo, mas ambos os protocolos estão evoluindo. O OpenID e suas extensões podem ser usados ​​para autorização e o OAuth pode ser usado para autenticação, que pode ser considerada uma autorização não operacional.

Acredito que faz sentido revisar esta questão, como também apontado nos comentários, a introdução do OpenID Connect pode ter trazido mais confusão.

O OpenID Connect é um protocolo de autenticação como o OpenID 1.0 / 2.0, mas na verdade é construído sobre o OAuth 2.0, para que você obtenha recursos de autorização junto com os recursos de autenticação. A diferença entre os dois é bem explicada em detalhes neste artigo (relativamente recente, mas importante): http://oauth.net/articles/authentication/

A explicação da diferença entre OpenID, OAuth, OpenID Connect:

OpenID é um protocolo para autenticação enquanto OAuth é para autorização. Autenticação é garantir que o cara com quem você está falando seja realmente quem ele afirma ser. Autorização é decidir o que esse cara deve ser autorizado a fazer.

No OpenID, a autenticação é delegada: o servidor A deseja autenticar o usuário U, mas as credenciais de U (por exemplo, nome e senha de U) são enviadas para outro servidor, B, no qual A confia (pelo menos, confia na autenticação de usuários). De fato, o servidor B garante que U seja realmente U e depois diz a A: "ok, esse é o U genuíno".

No OAuth, a autorização é delegada: a entidade A obtém da entidade B um "direito de acesso" que A pode mostrar ao servidor S para obter acesso; B pode, portanto, fornecer chaves de acesso temporárias e específicas a A sem fornecer muita energia. Você pode imaginar um servidor OAuth como o principal mestre em um grande hotel; ele entrega aos funcionários chaves que abrem as portas das salas em que deveriam entrar, mas cada chave é limitada (não dá acesso a todas as salas); além disso, as chaves se auto-destróem após algumas horas.

Até certo ponto, a autorização pode ser abusada em alguma pseudo-autenticação, com base no fato de que, se a entidade A obtiver de B uma chave de acesso por meio do OAuth e mostrá-la ao servidor S, o servidor S poderá inferir que B autenticou A antes de conceder o acesso chave. Portanto, algumas pessoas usam o OAuth onde deveriam usar o OpenID. Este esquema pode ou não ser esclarecedor; mas acho que essa pseudo-autenticação é mais confusa do que qualquer coisa. O OpenID Connect faz exatamente isso: abusa do OAuth em um protocolo de autenticação. Na analogia do hotel: se eu encontrar um funcionário suposto e essa pessoa me mostrar que ele tem uma chave que abre o meu quarto, suponho que esse seja um funcionário verdadeiro, com base no fato de que o mestre da chave não lhe daria uma chave o que abre meu quarto se ele não estava.

(fonte)

Qual a diferença entre o OpenID Connect e o OpenID 2.0?

O OpenID Connect executa muitas das mesmas tarefas que o OpenID 2.0, mas o faz de uma maneira que é amigável à API e utilizável por aplicativos móveis e nativos. O OpenID Connect define mecanismos opcionais para assinatura e criptografia robustas. Enquanto a integração do OAuth 1.0a e do OpenID 2.0 exigia uma extensão, no OpenID Connect, os recursos do OAuth 2.0 são integrados ao próprio protocolo.

(fonte)

O OpenID connect fornecerá um token de acesso mais um token de identificação. O token de identificação é um JWT e contém informações sobre o usuário autenticado. É assinado pelo provedor de identidade e pode ser lido e verificado sem acessar o provedor de identidade.

Além disso, o OpenID connect padroniza algumas coisas que oauth2 deixa à escolha. por exemplo, escopos, descoberta de terminal e registro dinâmico de clientes.

Isso facilita a gravação de código que permite ao usuário escolher entre vários provedores de identidade.

(fonte)

OAuth 2.0 do Google

As APIs OAuth 2.0 do Google podem ser usadas para autenticação e autorização. Este documento descreve nossa implementação do OAuth 2.0 para autenticação, em conformidade com a especificação do OpenID Connect e com certificação OpenID. A documentação encontrada em Usando o OAuth 2.0 para acessar APIs do Google também se aplica a este serviço. Se você deseja explorar esse protocolo interativamente, recomendamos o Google OAuth 2.0 Playground .

(fonte)

Mais uma extensão da pergunta do que uma resposta, mas pode adicionar alguma perspectiva às ótimas respostas técnicas acima. Eu sou um programador experiente em várias áreas, mas sou totalmente iniciante em programação para a web. Agora, tentando criar um aplicativo baseado na Web usando o Zend Framework.

Definitivamente implementará uma interface básica de autenticação de nome de usuário / senha específica do aplicativo, mas reconheça que, para um número crescente de usuários, o pensamento de outro nome de usuário e senha é um impedimento. Embora não seja exatamente uma rede social, sei que uma porcentagem muito grande dos usuários em potencial do aplicativo já tem contas no Facebook ou no Twitter. O aplicativo realmente não deseja ou precisa acessar informações sobre a conta do usuário nesses sites, apenas deseja oferecer a conveniência de não exigir que o usuário configure novas credenciais de conta, se não quiserem. Do ponto de vista da funcionalidade, isso pareceria um filho do autor do OpenID. Mas parece que nem o Facebook nem o Twitter são provedores de OpenID como tais, embora eles suportem a autenticação OAuth para acessar os dados de seus usuários.

Em todos os artigos que li sobre os dois e como eles diferem, só vi a observação de Karl Anderson acima: "O Outh pode ser usado para autenticação, que pode ser considerada uma autorização não operacional" que Vi qualquer confirmação explícita de que o OAuth era bom o suficiente para o que eu queria fazer.

De fato, quando fui postar essa "resposta", não sendo membro na época, observei longa e profundamente, no final desta página, as opções para me identificar. A opção de usar um login OpenID ou obter um, se eu não o tivesse, mas nada no twitter ou no facebook, parecia sugerir que o OAuth não era adequado para o trabalho. Mas então eu abri outra janela e procurei o processo geral de inscrição para o stackoverflow - e eis que há várias opções de autenticação de terceiros, incluindo facebook e twitter. No final, decidi usar meu ID do Google (que é um OpenID) exatamente pelo motivo de não querer conceder acesso ao stackoverflow à minha lista de amigos e a qualquer outra coisa que o Facebook goste de compartilhar sobre seus usuários - mas pelo menos isso '

Seria ótimo se alguém pudesse postar informações ou sugestões sobre informações sobre o suporte a esse tipo de configuração múltipla de autorização de terceiros e como você lida com usuários que revogam a autorização ou perdem o acesso ao site de terceiros. Também tenho a impressão de que meu nome de usuário aqui identifica uma conta exclusiva de stackoverflow que eu poderia acessar com autenticação básica se quisesse configurá-la e também acessar essa mesma conta através de outros autenticadores de terceiros (por exemplo, para que eu fosse considerado logado). no stackoverflow se eu estivesse logado em qualquer um dos sites do google, facebook ou twitter ...). Como este site está fazendo isso, alguém aqui provavelmente tem uma visão bastante boa sobre o assunto. :-)

Desculpe, isso foi muito longo e mais uma pergunta do que uma resposta - mas a observação de Karl fez com que parecesse o local mais apropriado para postar em meio ao volume de threads no OAuth e no OpenID. Se há um lugar melhor para isso que eu não encontrei, peço desculpas antecipadamente, tentei.

OpenID prova quem você é.

OAuth concede acesso aos recursos fornecidos pela parte autorizadora.

Atualmente, estou trabalhando no OAuth 2.0 e na especificação de conexão OpenID. Então, aqui está o meu entendimento: Antes eles eram:

1. O OpenID foi uma implementação proprietária do Google, permitindo que aplicativos de terceiros, como sites de jornais, possam fazer login usando o Google e comentar em um artigo, entre outros. Portanto, essencialmente, não há compartilhamento de senha no site do jornal. Deixe-me colocar uma definição aqui, essa abordagem na abordagem corporativa é chamada de Federação. Na Federação, você tem um servidor no qual autentica e autoriza (chamado IDP, Identity Provider) e, geralmente, detém as credenciais do Usuário. o aplicativo cliente em que você tem negócios é chamado de SP ou provedor de serviços. Se voltarmos ao mesmo exemplo de site de jornal, o site de jornal é SP aqui e o Google é IDP. Na empresa, esse problema foi resolvido anteriormente usando SAML. Naquela época, o XML costumava governar a indústria de software. Desde os serviços da web até a configuração, tudo costumava ir para XML, então temos SAML,

2. OAuth: O OAuth viu sua emergência como um padrão, analisando todos esses tipos de abordagens proprietárias e, portanto, tínhamos o OAuth 1.o como padrão, mas tratando apenas da autorização. Muitas pessoas não perceberam, mas isso começou a se agravar. Em seguida, tivemos o OAuth 2.0 em 2012. CTOs, arquitetos realmente começaram a prestar atenção à medida que o mundo se movia em direção à computação em nuvem e com dispositivos de computação em direção a dispositivos móveis e outros. OAuth meio que parecia ser a solução de um grande problema, onde os clientes de software podem fornecer o Serviço de IDP para uma empresa e ter muitos serviços de diferentes fornecedores, como força de vendas, SAP, etc. então vamos explorar o OAuth 2.o. Ah, perdeu um ponto importante que, durante esse período, o Google percebeu que o OAuth realmente não '

   uma. OAuth 2.o não diz claramente como será o registro do cliente b. ele não menciona nada sobre a interação entre o SP (servidor de recursos) e o aplicativo cliente (como o Analytics Server que fornece dados é o servidor de recursos e o aplicativo que exibe esses dados como cliente)

Já existem respostas maravilhosas dadas aqui tecnicamente, pensei em dar uma breve perspectiva de evolução

O OpenId usa o OAuth para lidar com a autenticação.

Por analogia, é como se o .NET dependesse da API do Windows. Você poderia chamar diretamente a API do Windows, mas os argumentos são tão amplos, complexos e de método tão vastos que você poderia facilmente cometer erros / bugs / problemas de segurança.

Mesmo com OpenId / OAuth. O OpenId conta com o OAuth para gerenciar a autenticação, mas definindo um token específico (Id_token), assinatura digital e fluxos específicos.

Eu gostaria de abordar um aspecto específico desta pergunta, conforme capturado neste comentário:

OAuth: antes de conceder acesso a algum recurso, a autenticação deve ser feita, certo? so OAuth = o que o OpenId + concede acesso a alguns recursos? - Hassan Makarov 21 de junho às 1:57

Sim e não. A resposta é sutil, então tenha paciência comigo.

Quando o fluxo OAuth o redireciona para um serviço de destino (o provedor OAuth, ou seja), é provável que você precise se autenticar com esse serviço antes que um token seja devolvido ao aplicativo / serviço do cliente. O token resultante permite que o aplicativo cliente faça solicitações em nome de um determinado usuário.

Observe a generalidade dessa última frase: especificamente, escrevi "em nome de um determinado usuário", não "em nome de você ". É um erro comum supor que "ter a capacidade de interagir com um recurso pertencente a um determinado usuário" implica "você e o proprietário do (s) recurso (s) de destino são os mesmos".

Não cometa esse erro.

Embora seja verdade que você se autentica com o provedor OAuth (digamos, por nome de usuário e senha, ou talvez certificados de clientes SSL, ou algum outro meio), o que o cliente recebe em troca não deve necessariamente ser tomado como prova de identidade. Um exemplo seria um fluxo no qual o acesso aos recursos de outro usuário foi delegado a você (e por proxy, o cliente OAuth). A autorização não implica autenticação.

Para lidar com a autenticação, é provável que você queira pesquisar no OpenID Connect, que é essencialmente outra camada no topo da base definida pelo OAuth 2.0. Aqui está uma citação que captura (na minha opinião) os pontos mais importantes em relação ao OpenID Connect (em https://oauth.net/articles/authentication/ ):

O OpenID Connect é um padrão aberto publicado no início de 2014 que define uma maneira interoperável de usar o OAuth 2.0 para executar a autenticação do usuário. Em essência, é uma receita amplamente publicada para calda de chocolate que foi experimentada e testada por um grande número e variedade de especialistas. Em vez de criar um protocolo diferente para cada provedor de identidade em potencial, um aplicativo pode falar um protocolo para o número de provedores que eles desejam trabalhar. Por ser um padrão aberto, o OpenID Connect pode ser implementado por qualquer pessoa sem restrições ou preocupações de propriedade intelectual.

O OpenID Connect é criado diretamente no OAuth 2.0 e, na maioria dos casos, é implantado junto com (ou acima de) uma infraestrutura do OAuth. O OpenID Connect também usa o conjunto de especificações JSON Object Signing And Encryption (JOSE) para transportar informações assinadas e criptografadas em locais diferentes. De fato, uma implantação do OAuth 2.0 com recursos JOSE já é um longo caminho para definir um sistema OpenID Connect totalmente compatível, e o delta entre os dois é relativamente pequeno. Mas esse delta faz uma grande diferença, e o OpenID Connect consegue evitar muitas das armadilhas discutidas acima, adicionando vários componentes principais à base do OAuth: [...]

O documento passa a descrever (entre outras coisas) os IDs de token e um ponto de extremidade UserInfo. O primeiro fornece um conjunto de declarações (quem você é, quando o token foi emitido etc.) e, possivelmente, uma assinatura para verificar a autenticidade do token por meio de uma chave pública publicada sem precisar solicitar o serviço upstream) e o último fornece um por exemplo, pedir o nome / sobrenome do usuário, email e informações semelhantes, tudo de maneira padronizada (em oposição às extensões ad-hoc ao OAuth que as pessoas usavam antes das coisas padronizadas do OpenID Connect).

Ambos os protocolos foram criados por diferentes razões. OAuth foi criado para autorizar terceiros a acessar recursos. O OpenID foi criado para executar a validação descentralizada da identidade. Este site declara o seguinte:

OAuth é um protocolo desenvolvido para verificar a identidade de um usuário final e conceder permissões a terceiros. Essa verificação resulta em um token. O terceiro pode usar esse token para acessar recursos em nome do usuário. Os tokens têm um escopo. O escopo é usado para verificar se um recurso é acessível a um usuário ou não

OpenID é um protocolo usado para autenticação descentralizada. Autenticação é sobre identidade; Estabelecer o usuário é de fato a pessoa que ele afirma ser. Descentralizar isso significa que este serviço desconhece a existência de quaisquer recursos ou aplicativos que precisam ser protegidos. Essa é a principal diferença entre o OAuth e o OpenID.

O OpenID Connect estende o protocolo de autorização do OAuth 2.0 para usar como protocolo de autenticação, para que você possa fazer logon único usando o OAuth. O OpenID Connect apresenta o conceito de um token de ID, que é um token de segurança que permite ao cliente verificar a identidade do usuário

OAuth 2.0 é um protocolo de segurança. NÃO é uma autenticação nem um protocolo de autorização.

Autenticação por definição, responde a duas perguntas.

1. Quem é o usuário?
2. O usuário está atualmente presente no sistema?

OAuth 2.0 possui os seguintes tipos de concessão

• client_credentials: quando um aplicativo precisa interagir com outro aplicativo e modificar os dados de vários usuários.
• permission_code: o usuário delega o servidor de Autorização para emitir um access_token que o cliente pode usar para acessar o recurso protegido
• refresh_token: quando o access_token expira, o token de atualização pode ser aproveitado para obter um novo access_token
• senha: o usuário fornece suas credenciais de logon a um cliente que chama o servidor de Autorização e recebe um access_token

Todos os quatro têm uma coisa em comum, access_token, um artefato que pode ser usado para acessar recursos protegidos.

O access_token não fornece a resposta para as 2 perguntas que um protocolo de "Autenticação" deve responder.

Um exemplo para explicar o Oauth 2.0 (créditos: OAuth 2 em ação, publicações Manning)

Vamos conversar sobre chocolate. Podemos fazer muitas confecções com chocolate, incluindo calda de chocolate, sorvete e bolo. Mas, nada disso pode ser comparado ao chocolate, porque vários outros ingredientes, como creme e pão, são necessários para fazer a confecção, mesmo que o chocolate pareça o ingrediente principal. Da mesma forma, o OAuth 2.0 é a infra-estrutura de chocolate e cookies, TLS, os Identity Providers são outros ingredientes necessários para fornecer a funcionalidade "Autenticação".

Se você deseja Autenticação, pode optar pelo OpenID Connect, que fornece um "id_token", além de um access_token, que responde às perguntas que todo protocolo de autenticação deve responder.

OAuth cria autenticação em cima da autorização: o usuário delega o acesso à sua identidade para o aplicativo, que, então, se torna consumidor da API de identidade, descobrindo quem autorizou o cliente em primeiro lugar http://oauth.net/ artigos / autenticação /