Qual é a diferença entre o OpenID e OAuth?
https://stackoverflow.com/questions/1087031
-
23-08-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianPergunta
Eu estou realmente tentando entender a diferença entre OpenID e OAuth? Talvez eles são duas coisas totalmente diferentes?
Solução
OpenID é sobre a autenticação (. Ie provando que você é), OAuth é sobre a autorização (ou seja. conceder acesso a funcionalidade / dados / etc .. sem ter que lidar com a autenticação do original).
OAuth poderia ser usado em sites de parceiros externos para permitir o acesso a dados protegidos sem que tenham de re-autenticar um usuário.
O post " OpenID contra OAuth partir da perspectiva do usuário " tem uma simples comparação dos dois a partir da perspectiva do usuário e '
2. Características Ambos os protocolos fornecem uma maneira para um site para redirecionar um usuário em outro lugar e voltar com uma afirmação verificável. OpenID fornece uma afirmação de identidade, enquanto OAuth é mais genérico, na forma de um token de acesso que pode então ser usada para "fazer as perguntas provedor de OAuth" . No entanto, cada um de apoio características diferentes: OpenID - a característica mais importante do OpenID é o seu processo de descoberta. O OpenID não requer codificação duro cada um dos fornecedores que pretende utilizar antes do tempo. Usando descoberta, o usuário pode escolher qualquer provedor de terceiros que deseja autenticar. Este recurso descoberta também tem causado a maioria dos problemas do OpenID porque a forma como ele é implementado é usando HTTP URIs como identificadores que a maioria dos usuários da Internet simplesmente não entendo. Outras características OpenID tem é o suporte para o registo de clientes ad-hoc usando uma troca DH, o modo imediato para a experiência do usuário final otimizada, e uma maneira de verificar afirmações sem fazer outra-de ida e volta para o provedor. OAuth - a característica mais importante do OAuth é o token de acesso que fornece um método de longa duração de fazer pedidos adicionais. Ao contrário de OpenID, OAuth não termina com a autenticação, mas fornece um token de acesso para ter acesso a recursos adicionais fornecidos pelo mesmo serviço de terceiros. No entanto, desde OAuth não suporta descoberta, que requer pré-selecionar e codificar os provedores de você decidir usar. Um usuário visitar o seu site não pode usar qualquer identificador, apenas os pré-selecionados por você. Além disso, OAuth não tem um conceito de identidade, para usá-lo por meio de login quer adicionar um parâmetro personalizado (como feito pelo Twitter) ou fazer outra chamada API para obter o momento "logado" usuário. 3. Implementações técnicos Os dois protocolos compartilham uma arquitetura comum no uso do redirecionamento para obter a autorização do usuário. Em OAuth o usuário autoriza o acesso aos seus recursos protegidos e em OpenID, à sua identidade. Mas isso é tudo que eles compartilham. Cada protocolo tem uma maneira diferente de calcular uma assinatura utilizada para verificar a autenticidade do pedido ou resposta, e cada um tem diferentes requisitos de registo.
OpenID é (principalmente) para identificação / autenticação, de modo que stackoverflow.com sabe que eu próprio chris.boyle.name (ou onde) e, portanto, que eu sou provavelmente a mesma pessoa que era dono chris.boyle.name ontem e ganhou alguns pontos de reputação.
OAuth é projetado para autorização para tomar medidas em seu nome, de modo que stackoverflow.com (ou onde) pode pedir permissão para, digamos, Tweet em seu nome automaticamente, sem saber sua senha do Twitter.
Muitas pessoas ainda visitar este então aqui está um diagrama muito simples de explicar
OAuth
Usado para delegado authorization única - ou seja, você está autorizando um acesso de serviço de terceiros para usar dados pessoais, sem dar uma palavra-passe. Também OAuth "sessões" geralmente vivem mais tempo do que as sessões de usuário. O que significa que OAuth é projetado para permitir a autorização
i. Flickr usa OAuth para permitir serviços de terceiros para postar e editar uma pessoas retratar em seu nome, sem que tenham de dar o seu nome de usuário e senha flicker.
OpenID
Usado para authenticate single sign-on identidade. Todos OpenID é suposto fazer é permitir que um provedor de OpenID para provar que você diz que é. No entanto, muitos sites usam autenticação de identidade para fornecer autorização (no entanto, os dois podem ser separadas)
i. Um mostra seu passaporte no aeroporto para autenticar (ou provar) a pessoa é que o nome está no bilhete que eles estão usando é deles.
Use OAuth se seus usuários pode apenas querer o login com Facebook ou Twitter. Use OpenID se os usuários estão neckbeards que funcionam seus próprios provedores de OpenID, porque eles "não querem qualquer outra pessoa possuir sua identidade".
OpenID e OAuth são cada protocolos baseados em HTTP para autenticação e / ou autorização. Ambos se destinam a permitir aos usuários executar ações sem dar credenciais de autenticação ou permissões cobertor a clientes ou a terceiros. Enquanto eles são semelhantes, e não são propostas normas para usar os dois juntos, eles são protocolos separados.
OpenID é destinado a autenticação federada. Um cliente aceita uma afirmação de identidade de qualquer provedor (embora os clientes são livres para whitelist ou provedores de lista negra).
OAuth é destinado a autorização delegada. A registros de cliente com um fornecedor, que fornece autorização fichas que aceitará para executar ações em nome do usuário.
OAuth está melhor adaptado para a autorização, porque mais interações após autenticação são incorporadas ao protocolo, mas ambos os protocolos estão evoluindo. OpenID e suas extensões poderia ser usado para autorização e OAuth pode ser usado para autenticação, que pode ser pensado como uma autorização não-op.
Creio que faz sentido voltar a esta questão como também apontou nos comentários, a introdução de OpenID Connect poderá trouxeram mais confusão.
OpenID Connect é um protocolo de autenticação como OpenID 1.0 / 2.0, mas na verdade é construído em cima do OAuth 2.0, então você vai ter recursos de autorização, juntamente com recursos de autenticação. A diferença entre os dois é muito bem explicado em detalhe neste (relativamente recente, mas importante) artigo: http://oauth.net/articles / autenticação /
A explicação da diferença entre OpenID, OAuth, OpenID Ligação:
OpenID é um protocolo para autenticação enquanto OAuth é para autorização. A autenticação é sobre certificando-se de que o cara que você está falando é realmente quem ele diz ser. A autorização é de cerca de decidir o que esse cara deve ser permitido fazer.
Em OpenID, a autenticação é delegada: Um servidor quer autenticar U usuário, mas U das credenciais (por exemplo, nome e senha de U) são enviados para outro servidor, B, que confia em um (pelo menos, confia para autenticar Comercial). Na verdade, o servidor B garante que U é realmente U, e depois diz a A: "ok, essa é a verdadeira U"
.Em OAuth, a autorização é delegada: Entidade A obtém da entidade B um "direito de acesso" que A pode mostrar ao servidor S para ser o acesso concedido; B pode, assim, entregar, chaves de acesso específicos temporária para um sem dar -los demasiado poder. Você pode imaginar um servidor OAuth como o mestre chave em um grande hotel; ele dá às teclas funcionários que abrem as portas da quartos que eles deveriam entrar, mas cada chave é limitada (-lo não dá acesso a todos os quartos); além disso, as chaves auto-destruir depois de algumas horas.
Em certa medida, a autorização pode ser abusado em algum pseudo-autenticação, na base de que se obtém a partir de entidade A B uma chave de acesso através OAuth, e mostra para servidor S, então servidor S pode inferir que B autenticado A antes de conceder a chave de acesso. Assim, alguns as pessoas usam OAuth onde eles devem estar usando OpenID. Este esquema pode ou podem não ser esclarecedor; mas acho que este pseudo-autenticação é mais confuso do que qualquer coisa. OpenID Ligação faz exatamente isso: ela abusos OAuth para um protocolo de autenticação. Na analogia hotel: se eu encontrar um empregado pretendia e essa pessoa me mostra que ele tem um chave que abre meu quarto, então eu suponho que este é um verdadeiro empregado, na base de que o mestre chave não teria lhe dado uma chave que abre o meu quarto se ele não era.
Como é OpenID Ligação diferente do OpenID 2.0?
OpenID Ligação executa muitas das mesmas tarefas que OpenID 2.0, mas faz -lo de uma forma que é-API amigável, e utilizável por nativa e móvel formulários. OpenID Ligação define mecanismos opcionais para robusto assinatura e criptografia. Considerando que a integração de 1.0a OAuth e OpenID 2.0 necessária uma extensão, em OpenID Connect, OAuth 2.0 recursos são integrados com o próprio protocolo.
OpenID Connect irá dar-lhe um token de acesso, mais um token id. A identificação token é um JWT e contém informações sobre o usuário autenticado. Ele é assinado pelo provedor de identidade e pode ser lido e verificado sem acessar o provedor de identidade.
Além disso, OpenID Padroniza conexão bastante algumas coisas que folhas OAuth2 até a escolha. por exemplo, Scopes, descoberta ponto final, e registro dinâmico dos clientes.
Isto torna mais fácil para escrever código que permite ao usuário escolher entre prestadores de múltipla identidade.
O Google OAuth 2.0
APIs do Google OAuth 2.0 pode ser utilizado tanto para a autenticação e autorização. Este documento descreve a nossa implementação do OAuth 2.0 para autenticação, o que está de acordo com o OpenID Ligue especificação e é OpenID Certified. A documentação encontrada em Usando o OAuth 2.0 para APIs acessar o Google também se aplica a este serviço. Se você quiser explorar este protocolo de forma interativa, recomendamos o Google OAuth 2.0 Playground .
Mais uma extensão para a questão de uma resposta, mas pode adicionar um pouco de perspectiva para as grandes respostas técnicas acima. Eu sou um programador experiente em uma série de áreas, mas um noob total a programação para a web. Agora tentando construir um aplicativo baseado na web usando o Zend Framework.
Definitivamente vai implementar uma interface de autenticação de usuário / senha básico específico do aplicativo, mas reconhecem que, para um número crescente de usuários o pensamento de mais um nome de usuário e senha é um impedimento. Enquanto a rede não exatamente sociais, eu sei que uma grande porcentagem de usuários potenciais da aplicação já têm contas de Facebook ou Twitter. A aplicação não realmente querem ou necessidade de acessar informações sobre a conta do usuário a partir desses sites, ele só quer oferecer a conveniência de não exigir que o usuário configurar novas credenciais de conta se eles não querem. Do ponto de vista da funcionalidade, que parece uma criança do poster para OpenID. Mas parece que nem facebook nem Twitter são prestadores de OpenID como tal, embora eles fazem a autenticação OAuth suporte para acessar os dados de seus usuários.
Em todos os artigos que eu li sobre os dois e como eles diferem, wa não até que eu vi a observação de Karl Anderson acima, que "OAuth pode ser usado para autenticação, que pode ser pensado como um não-op autorização" que eu vi qualquer confirmação explícita de que OAuth era bom o suficiente para o que eu queria fazer.
Na verdade, quando eu fui para postar esta "resposta", não sendo um membro no momento, olhei longo e duro na parte inferior desta página, nas opções para me identificar. A opção para usar um login OpenID ou a obtenção de um, se eu não tiver um, mas nada sobre o Twitter ou Facebook, parecia sugerir que OAuth não era adequado para o trabalho. Mas então eu abriu outra janela e olhou para o processo geral de inscrição para stackoverflow - e eis que há uma série de opções de autenticação 3-parte, incluindo Facebook e Twitter. No final, eu decidi usar o meu ID do Google (que é um OpenID) para exatamente a razão que eu não queria conceder acesso stackoverflow à minha lista de amigos e qualquer outra coisa facebook gosta de compartilhar sobre seus usuários - mas pelo menos é um ponto prova de que OAuth é adequado para o uso que eu tinha em mente.
Seria realmente ótimo se alguém pudesse informações POST ou ponteiros para informações sobre o suporte a este tipo de configuração autorização múltipla 3-parte, e como você lida com os usuários que a autorização revogar ou acesso perder para o seu site 3o partido. Também tenho a impressão de que meu nome de usuário aqui identifica uma conta exclusiva stackoverflow que eu pudesse acessar com autenticação básica se eu queria para configurá-lo, e também aceder a esta mesma conta através de outros autenticadores 3-parte (por exemplo, de modo que eu seria considerado logado no stackoverflow se eu estava conectado a qualquer um dos google, facebook, ou twitter ...). Uma vez que este site é fazê-lo, alguém aqui, provavelmente, tem alguns belos boa visão sobre o assunto. : -)
Desculpe isto era tão longa, e mais uma pergunta do que uma resposta - mas o comentário de Karl fez parecer que o local mais apropriado para postar no meio do volume de linhas em OAuth e OpenID. Se há um lugar melhor para isso que eu não encontrei, peço desculpas antecipadamente, eu fiz tentativa.
- OpenID é um padrão aberto e protocolo de autenticação descentralizado controlado pela Fundação OpenID.
- OAuth é um padrão aberto para delegação de acesso.
- OpenID Conectar (OIDC) Combina as características de OpenID e OAuth ou seja, faz autenticação e autorização.
OpenID tomar a forma de um único URI conseguiu por alguns de "provedor de OpenID", isto é provedor de identidade (IDP).
OAuth pode ser usado em conjunto com XACML onde OAuth é usado para consentimento propriedade e delegação de acesso enquanto XACML é usado para definir as políticas de autorização.
OIDC usa simples JSON Web Tokens (JWT), que você pode obter usando flui em conformidade com os OAuth 2.0 especificações.
Por exemplo , se você escolheu para entrar no Auth0 usar a sua conta do Google, em seguida, você usou OIDC . Uma vez que você autenticar com êxito com o Google e autorizar Auth0 para acessar suas informações, o Google irá enviar de volta para Auth0 informações sobre o usuário e a autenticação realizada. Esta informação é devolvido em um JSON Web token (JWT). Você receberá um token de acesso e, se solicitado, uma ID de token. Tipos de token : Fonte: OpenID Ligação
Analogia :
Um uso Organização cartão de identificação para fins de identificação e contém fichas, ele armazena detalhes sobre Employee juntamente com Autorização ou seja Campus / Acesso Portão / ODC. ID Card agir como um OIDC e Chip agir como um OAuth . mais exemplos e forma wiki
OpenID prova que você é.
OAuth concede acesso aos recursos fornecidos pelo partido de autorização.
Atualmente, estou trabalhando em OAuth 2.0 e OpenID especificação de conexão. Então aqui é o meu entendimento: No início eles eram:
- OpenID foi implementação proprietária da Google permitindo que aplicações de terceiros como para sites de jornais que você pode fazer login usando o google e comentar sobre um artigo e assim por diante outros casos de uso. Então, basicamente, nenhuma senha compartilhando o site do jornal. Deixe-me colocar-se uma definição aqui, esta abordagem na abordagem empresarial é chamado de Federação. Na Federação, você tem um servidor onde você autenticar e autorizar (chamado IDP, Provedor de identidade) e, geralmente, o guarda de credenciais do usuário. o aplicativo cliente onde você tem negócio é chamado SP ou Service Provider. Se voltarmos ao mesmo exemplo site do jornal, em seguida, site do jornal é SP aqui e Google é IDP. Na empresa este problema foi anteriormente resolvido usando SAML. que XML tempo usado para governar a indústria de software. Assim, a partir webservices a configuração, tudo utilizado para ir para XML por isso temos SAML, um protocolo completo Federação
-
OAuth: OAuth viu a sua emergência como um padrão olhando para todos estes tipos de abordagens proprietárias e por isso tivemos OAuth 1.O como padrão, mas abordando autorização só. Não há muitas pessoas notado, mas isso meio que começou a pegar. Então nós tivemos OAuth 2.0 em 2012. CTOs, Arquitetos realmente começaram a prestar atenção como o mundo está se movendo em direção a computação em nuvem e com dispositivos de computação móveis para esses dispositivos móveis e outros. OAuth tipo de encarado como resolver grande problema onde os clientes de software pode dar IDP serviço a uma empresa e ter muitos serviços de diferentes fornecedores como a Salesforce, SAP, etc. Assim, a integração aqui realmente se parece cenário de federação mordeu um grande problema, usando SAML é caro então vamos explorar OAuth 2.o. Ohh, perdeu um ponto importante que, durante este tempo, o Google percebeu que OAuth realmente não aborda autenticação, como é que IDP dados do usuário dar SP (que na verdade é maravilhosamente abordados em SAML) e com outras pontas soltas como:
a. OAuth 2.o não diz claramente, como o registo de clientes vai acontecer b. ele não mencionou nada sobre a interação entre SP (Resource Server) e aplicação do cliente (como o Analytics Server fornecimento de dados é de recursos de servidor e aplicação mostrando que os dados é cliente)
Já existem respostas maravilhosas dadas aqui tecnicamente, pensei em dar de dar perspectiva a evolução breve
OpenId usa OAuth para lidar com autenticação.
Por analogia, é como .NET confia no Windows API. Você poderia chamar diretamente o Windows API, mas é tão ampla, complexa e método argumentos tão vasto, você pode facilmente cometer erros / bugs / problema de segurança.
Mesmo com OpenID / OAuth. OpenId depende de OAuth para gerenciar a autenticação, mas a definição de um determinado token (Id_token), assinatura digital e fluxos específicos.
Eu gostaria de abordar um aspecto particular desta questão, como capturados neste comentário:
OAuth: antes de conceder acesso a algum recurso, a autenticação deve ser feito, certo?. assim OAuth = o OpenId faz + concede acesso a algumas funcionalidades? - Hassan Makarov 21 de junho em 01:57
Sim ... e não. A resposta é sutil, tão urso com mim.
Quando o fluxo OAuth redireciona para um serviço de destino (o provedor de OAuth, que é), ele é provável que você vai precisar para autenticar com esse serviço antes de um símbolo estará de volta entregue a o aplicativo cliente / serviço. O token resultante permite, em seguida, o aplicativo cliente para fazer solicitações em nome de um determinado usuário.
Observe a generalidade do que a última frase: especificamente, eu escrevi "em nome de um determinado usuário", não "em nome de você ". É um erro comum supor que "ter uma capacidade de interagir com um recurso de propriedade de um determinado usuário" implica "você e o proprietário do recurso de destino (s) são um na mesma".
Não faça este erro.
Embora seja verdade que você autenticar com o provedor de OAuth (digamos, por nome de usuário e senha, ou talvez certificados de cliente SSL, ou algum outro meio), o que o cliente recebe em troca deve não , necessariamente, ser tomada como prova de identidade. Um exemplo seria um fluxo em que o acesso aos recursos de outro usuário era delegado para você (e por procuração, o cliente OAuth). não autorização não implica autenticação.
Para a autenticação alça, você provavelmente vai querer olhar para o OpenID Connect, que é essencialmente uma outra camada em cima do conjunto fundação por OAuth 2.0. Aqui está uma citação que captura (em minha opinião) a maioria dos pontos salientes sobre OpenID Connect (de https: // OAuth. / artigos de rede / autenticação / ):
OpenID Connect é um padrão aberto publicada no início de 2014 que define uma forma interoperabilidade usar OAuth 2.0 para executar a autenticação do utilizador. Em essência, é uma receita amplamente divulgado para fudge de chocolate que tem sido experimentado e testado por um número amplo e variedade de especialistas. Em vez de construir um protocolo diferente para cada potencial provedor de identidade, um aplicativo pode falar um protocolo para como muitos provedores como eles querem trabalhar. Desde que é um padrão aberto, OpenID Connect pode ser implementado por qualquer pessoa, sem restrição ou de propriedade intelectual preocupações.
OpenID Connect é construído directamente no OAuth 2.0 e na maioria dos casos é implantado direita juntamente com (ou em cima de) uma infra-estrutura OAuth. OpenID Connect também usa a assinatura JSON objeto e Encryption (JOSE) conjunto de especificações para transporte de informações assinadas e criptografadas em torno de lugares diferentes. Na verdade, uma implantação OAuth 2.0 com capacidades JOSE já é um longo caminho a definir um sistema OpenID Ligação totalmente compatível, e o delta entre os dois é relativamente pequena. Mas isso delta faz uma grande diferença, e OpenID Ligação consegue evitar muitas das armadilhas discutidos acima, adicionando vários componentes-chave para a base OAuth: [...]
O documento, em seguida, passa a descrever (entre outras coisas) IDs token e um ponto de extremidade UserInfo. O primeiro fornece um conjunto de reivindicações (quem você é, quando o token foi emitido, etc, e, possivelmente, uma assinatura para verificar a autenticidade do token via uma chave pública publicada sem ter que pedir o serviço a montante ), e esta última fornece um meio de, por exemplo pedindo primeiro / último nome do usuário, e-mail, e pedaços semelhantes de informações, tudo de forma padronizada (em oposição às extensões ad-hoc para OAuth que as pessoas usaram antes OpenID Ligação padronizado coisas).
Ambos os protocolos foram criados por diferentes razões. OAuth foi criado para autorizar terceiros a acessar recursos. OpenID foi criado para executar a validação de identidade descentralizar. Este website indica o seguinte:
OAuth é um protocolo projetado para verificar a identidade de um usuário final e para conceder permissões a um terceiro. Esta verificação resulta em um token. O terceiro pode usar esse token para acessar recursos em nome do usuário. Fichas 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 descentralizado. A autenticação é sobre a identidade; Estabelecer o usuário está no fato da pessoa que ele diz ser. Descentralização que, significa que este serviço não tem conhecimento da existência de quaisquer recursos ou aplicativos que precisam ser protegidos. Essa é a diferença fundamental entre o OAuth e OpenID.
OAuth 2.0 é um protocolo de segurança. Não é nem um um protocolo de autorização de autenticação NOR.
Autenticação por definição, as respostas a duas perguntas.
- Quem é o usuário?
- O usuário atualmente presente no sistema?
OAuth 2.0 tem os seguintes tipos de subvenções
- client_credentials:. Quando alguém precisa de aplicativos para interagir com outro aplicativo e modificar os dados de vários usuários
- authorization_code: delegados de usuários do servidor de autorização para emitir um access_token que o cliente pode usar para recurso protegido acesso
- refresh_token: Quando o access_token expirar, o token de atualização pode ser aproveitado para obter um novo access_token
- senha: O usuário fornece suas credenciais de login para um cliente que chama o servidor de Autorização e recebe uma access_token
Todos os 4 têm uma coisa em comum, access_token, um artefato que pode ser usado para recurso protegido de acesso.
O access_token não fornece a resposta às 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, Manning publicações)
Vamos falar sobre chocolate. Nós podemos fazer muitas confecções fora do chocolate incluindo, fudge, sorvete e bolo. Mas, nenhum destes pode ser equiparado ao chocolate porque vários outros ingredientes como creme de leite e pão são necessários para fazer a confecção, embora sons chocolate como o ingrediente principal. Da mesma forma, o OAuth 2.0 é o chocolate, e biscoitos, TLS infrastucture, Provedores de Identidade são outros ingredientes que são necessários para fornecer a funcionalidade "Autenticação".
Se você quiser autenticação, você pode ir para o OpenID Connect, que fornece uma "id_token", para além de um access_token, que responde às perguntas que cada protocolo de autenticação deve responder.
OAuth constrói autenticação no topo da autorização: Os delegados usuário acesso a sua identidade para o aplicativo, que, então, se torna um consumidor da API identidade, encontrando, assim, quem autorizou o cliente em primeiro lugar http://oauth.net/articles/authentication/
