OpenID와 OAuth의 차이점은 무엇입니까?

OpenID와 OAuth의 차이점은 무엇입니까?

---

OpenID와 OAuth의 차이점을 정말로 이해하려고 노력하고 있습니까? 어쩌면 그들은 완전히 별개의 두 가지일까요?

---

OpenID 는 인증 (즉, 귀하가 누구인지 증명)에 관한 것이고 OAuth 는 인증 (즉, 원래 인증을 처리하지 않고도 기능 / 데이터 등에 대한 액세스 권한을 부여하는 것)에 관한 것입니다.

OAuth는 외부 파트너 사이트에서 사용자를 재 인증하지 않고도 보호 된 데이터에 대한 액세스를 허용하는 데 사용할 수 있습니다.

블로그 게시물 " 사용자 관점에서 본 OpenID 대 OAuth "에는 사용자 관점 에서 두 가지를 간단하게 비교하고 " OAuth-OpenID : 동일한 것으로 생각하면 잘못된 트리를 짖고 있습니다 "에 더 많은 정보가 있습니다. 그것에 대해.

---

OAuth와 OpenID를 비교하는 세 가지 방법이 있습니다.

1. 목적

OpenID는 연합 인증을 위해 만들어졌습니다. 즉, 타사가 이미 가지고있는 계정을 사용하여 사용자를 인증 할 수 있도록합니다 . 여기에서 연합이라는 용어는 중요합니다. OpenID의 요점은 모든 공급자를 사용할 수 있다는 것입니다 (화이트리스트 제외). 사용자가 보유한 다른 계정을 사용할 수 있도록 제공 업체와 거래를 미리 선택하거나 협상 할 필요가 없습니다.

OAuth는 사용자가 타사 애플리케이션과 비밀번호를 공유 할 필요가 없도록 만들어졌습니다 . 실제로 OpenID 문제를 해결하는 방법으로 시작되었습니다. 사이트에서 OpenID를 지원하는 경우 사용자가 사이트에 암호가 없기 때문에 HTTP 기본 자격 증명 (사용자 이름 및 암호)을 사용하여 API를 제공 할 수 없습니다.

문제는 인증을위한 OpenID와 인증을위한 OAuth의 분리로 인해 두 프로토콜이 동일한 작업을 많이 수행 할 수 있다는 것입니다. 그들은 각각 다른 구현에서 원하는 다른 기능 집합을 제공하지만 본질적으로 상호 교환이 가능합니다. 핵심에서 두 프로토콜은 모두 어설 션 확인 방법입니다 (OpenID는 '내가 누구입니다'어설 션으로 제한되는 반면 OAuth는 API를 통해 지원되는 어설 션으로 교환 할 수있는 '액세스 토큰'을 제공합니다).

2. 특징

두 프로토콜 모두 사이트가 사용자를 다른 곳으로 리디렉션하고 확인 가능한 어설 션으로 돌아 오는 방법을 제공합니다. OpenID는 ID 어설 션을 제공하는 반면 OAuth는 "OAuth 공급자 질문에 질문"하는 데 사용할 수있는 액세스 토큰의 형태로 더 일반적입니다 . 그러나 각각 다른 기능을 지원합니다.

OpenID - OpenID 의 가장 중요한 기능은 검색 프로세스입니다. OpenID는 미리 사용하려는 각 공급자를 하드 코딩 할 필요가 없습니다. 검색을 사용하여 사용자는 인증 할 타사 공급자를 선택할 수 있습니다. 이 검색 기능은 또한 대부분의 웹 사용자가 얻지 못하는 식별자로 HTTP URI를 사용하여 구현되는 방식이기 때문에 대부분의 OpenID 문제를 일으켰습니다. OpenID의 다른 기능은 DH 교환을 사용한 임시 클라이언트 등록 지원, 최적화 된 최종 사용자 경험을위한 즉시 모드, 공급자에 대한 추가 왕복없이 어설 션을 확인하는 방법입니다.

OAuth - OAuth 의 가장 중요한 기능은 추가 요청을 생성하는 오래 지속되는 방법을 제공하는 액세스 토큰입니다. OpenID와 달리 OAuth는 인증으로 끝나지 않고 동일한 타사 서비스에서 제공하는 추가 리소스에 액세스 할 수있는 액세스 토큰을 제공합니다. 그러나 OAuth는 검색을 지원하지 않기 때문에 사용하기로 결정한 공급자를 미리 선택하고 하드 코딩해야합니다. 귀하의 사이트를 방문하는 사용자는 식별자를 사용할 수 없으며 귀하가 미리 선택한 식별자 만 사용할 수 있습니다. 또한 OAuth에는 ID 개념이 없으므로 로그인에 사용한다는 것은 사용자 정의 매개 변수를 추가하거나 (Twitter에서 수행 한대로) 현재 "로그인 된"사용자를 얻기 위해 다른 API 호출을 수행하는 것을 의미합니다.

3. 기술 구현

두 프로토콜은 사용자 인증을 얻기 위해 리디렉션을 사용하는 공통 아키텍처를 공유합니다. OAuth에서 사용자는 보호 된 리소스 및 OpenID에서 자신의 ID에 대한 액세스 권한을 부여합니다. 그러나 그것이 그들이 공유하는 전부입니다.

각 프로토콜에는 요청 또는 응답의 신뢰성을 확인하는 데 사용되는 서명을 계산하는 다른 방법이 있으며 각 프로토콜에는 서로 다른 등록 요구 사항이 있습니다.

---

OpenID는 (주로) 식별 / 인증을위한 것이므로 stackoverflow.com내가 chris.boyle.name(또는 어디서든) 소유 하고 있다는 것을 알기 때문에 chris.boyle.name어제 소유 하고 일부 평판 포인트를 얻은 동일한 사람 일 것입니다 .

OAuth는 사용자를 대신하여 작업을 수행 할 수있는 권한을 부여하기 위해 설계되었으므로 stackoverflow.com트위터 비밀번호를 몰라도 자동으로 사용자를 대신하여 트윗 할 권한을 요청할 수 있습니다.

---

많은 사람들이 여전히 이것을 방문하므로 여기에 설명하는 매우 간단한 다이어그램이 있습니다.

의례 Wikipedia

---

OAuth

위 임용으로 authorization만 사용됩니다. 즉, 암호를 제공하지 않고 개인 데이터를 사용할 수 있도록 제 3 자 서비스 액세스 권한을 부여합니다. 또한 OAuth "세션"은 일반적으로 사용자 세션보다 오래 지속됩니다. OAuth가 인증을 허용하도록 설계되었음을 의미합니다.

즉, Flickr는 OAuth를 사용하여 타사 서비스가 깜박임 사용자 이름과 암호를 제공하지 않고도 개인 사진을 게시하고 편집 할 수 있도록합니다.

OpenID

에 사용되는 authenticate단일 로그온 정체성. 모든 OpenID가해야 할 일은 OpenID 제공 업체가 귀하가 본인임을 증명하도록 허용하는 것입니다. 그러나 많은 사이트에서 인증을 제공하기 위해 ID 인증을 사용합니다 (하지만 둘은 분리 될 수 있음).

즉, 하나는 공항에서 여권을 보여 주어 그들이 사용하는 티켓에있는 사람의 이름이 본인임을 증명 (또는 증명)합니다.

---

사용자가 Facebook 또는 Twitter로 로그인하려는 경우 OAuth를 사용하십시오. 사용자가 "다른 사람이 자신의 신원을 소유하는 것을 원하지 않기 때문에"자체 OpenID 공급자를 운영하는 목 수염 인 경우 OpenID를 사용하십시오.

---

OpenID 및 OAuth는 인증 및 / 또는 권한 부여를위한 각각의 HTTP 기반 프로토콜입니다. 둘 다 사용자가 클라이언트 나 제 3 자에게 인증 자격 증명이나 포괄적 인 권한을 제공하지 않고도 작업을 수행 할 수 있도록하기위한 것입니다. 유사하고 두 가지를 함께 사용하기 위해 제안 된 표준이 있지만 별도의 프로토콜입니다.

OpenID는 연합 인증을위한 것입니다. 클라이언트는 모든 공급자의 ID 어설 션을 수락합니다 (클라이언트는 공급자를 화이트리스트 또는 블랙리스트에 자유롭게 추가 할 수 있음).

OAuth는 위임 된 권한 부여를위한 것입니다. 클라이언트는 사용자를 대신하여 작업을 수행하기 위해 수락 할 인증 토큰을 제공하는 공급자에 등록합니다.

OAuth는 현재 인증에 더 적합합니다. 인증 후 추가 상호 작용이 프로토콜에 내장되어 있지만 두 프로토콜이 모두 진화하고 있기 때문입니다. OpenID와 그 확장은 권한 부여에 사용될 수 있고 OAuth는 인증에 사용될 수 있는데, 이는 no-op 권한으로 생각할 수 있습니다.

---

의견에서 지적한대로이 질문을 다시 검토하는 것이 합리적이라고 생각합니다. OpenID Connect의 도입으로 인해 더 많은 혼란이 발생했을 수 있습니다.

OpenID Connect는 OpenID 1.0 / 2.0과 같은 인증 프로토콜이지만 실제로는 OAuth 2.0을 기반으로 구축되었으므로 인증 기능과 함께 인증 기능을 사용할 수 있습니다. 둘 사이의 차이점은 (상대적으로 최근이지만 중요한) 기사에서 자세히 설명합니다. http://oauth.net/articles/authentication/

---

OpenID, OAuth, OpenID Connect의 차이점에 대한 설명 :

OpenID는 인증 용 프로토콜이고 OAuth는 인증 용입니다. 인증은 당신이 말하는 사람이 실제로 그가 주장하는 사람인지 확인하는 것입니다. 승인은 그 사람이 할 수있는 일을 결정하는 것입니다.

OpenID에서는 인증이 위임됩니다. 서버 A는 사용자 U를 인증하려고하지만 U의 자격 증명 (예 : U의 이름 및 암호)은 A가 신뢰하는 (적어도 사용자 인증을 신뢰하는) 다른 서버 B로 전송됩니다. 실제로 서버 B는 U가 실제로 U인지 확인한 다음 A에게 "좋아요, 진짜 U입니다"라고 말합니다.

OAuth에서는 권한이 위임됩니다. 엔티티 A는 엔티티 B로부터 "액세스 권한"을 얻습니다.이 권한은 A가 액세스 권한을 서버 S에 보여줄 수 있습니다. 따라서 B는 너무 많은 전력을 제공하지 않고도 임시 특정 액세스 키를 A에게 전달할 수 있습니다. 큰 호텔에서 OAuth 서버를 키 마스터로 상상할 수 있습니다. 그는 직원들에게 그들이 들어가야 할 방의 문을 여는 열쇠를 주지만, 각 열쇠는 제한되어 있습니다 (모든 방에 대한 접근 권한을 부여하지는 않습니다). 또한 키는 몇 시간 후에 자폭합니다.

엔티티 A가 OAuth를 통해 B로부터 액세스 키를 가져 와서 서버 S에 보여 주면 서버 S가 액세스 권한을 부여하기 전에 B가 A를 인증했다고 추론 할 수 있다는 점에 근거하여 어느 정도까지는 권한이 의사 인증에 악용 될 수 있습니다. 키. 그래서 어떤 사람들은 OpenID를 사용해야하는 곳에 OAuth를 사용합니다. 이 스키마는 깨달을 수도 있고 아닐 수도 있습니다. 그러나 나는이 의사 인증이 무엇보다 더 혼란 스럽다고 생각합니다. OpenID Connect는 바로 OAuth를 인증 프로토콜로 남용합니다. 호텔 비유에서 : 내가 추정 된 직원을 만났는데 그 사람이 내 방을 여는 열쇠가 있다는 것을 보여 주면, 열쇠 주인이 그에게 열쇠를주지 않았을 것이라는 점을 근거로이 직원이 진정한 직원이라고 생각합니다. 그가 아니라면 내 방을 열어줍니다.

(출처)

OpenID Connect는 OpenID 2.0과 어떻게 다릅니 까?

OpenID Connect는 OpenID 2.0과 동일한 작업을 많이 수행하지만 API 친화적이고 기본 및 모바일 애플리케이션에서 사용할 수있는 방식으로 수행합니다. OpenID Connect는 강력한 서명 및 암호화를위한 선택적 메커니즘을 정의합니다. OAuth 1.0a와 OpenID 2.0의 통합에는 확장이 필요했지만 OpenID Connect에서는 OAuth 2.0 기능이 프로토콜 자체와 통합되었습니다.

(출처)

OpenID connect는 액세스 토큰과 ID 토큰을 제공합니다. ID 토큰은 JWT이며 인증 된 사용자에 대한 정보를 포함합니다. ID 공급자가 서명하고 ID 공급자에 액세스하지 않고도 읽고 확인할 수 있습니다.

또한 OpenID connect는 oauth2가 선택해야하는 몇 가지 사항을 표준화합니다. 예를 들어 범위, 엔드 포인트 검색 및 클라이언트의 동적 등록이 있습니다.

This makes it easier to write code that lets the user choose between multiple identity providers.

(source)

Google's OAuth 2.0

Google's OAuth 2.0 APIs can be used for both authentication and authorization. This document describes our OAuth 2.0 implementation for authentication, which conforms to the OpenID Connect specification, and is OpenID Certified. The documentation found in Using OAuth 2.0 to Access Google APIs also applies to this service. If you want to explore this protocol interactively, we recommend the Google OAuth 2.0 Playground.

(source)

---

More an extension to the question than an answer, but it may add some perspective to the great technical answers above. I'm an experienced programmer in a number of areas, but a total noob to programming for the web. Now trying to build a web-based application using Zend Framework.

Definitely will implement an application-specific basic username/password authentication interface, but recognize that for a growing number of users the thought of yet another username and password is a deterrent. While not exactly social networking, I know that a very large percentage of the application's potential users already have facebook or twitter accounts. The application doesn't really want or need to access information about the user's account from those sites, it just wants to offer the convenience of not requiring the user to set up new account credentials if they don't want to. From a functionality point of view, that would seem a poster child for OpenID. But it seems that neither facebook nor twitter are OpenID providers as such, though they do support OAuth authentication to access their user's data.

In all the articles I've read about the two and how they differ, it wan't until I saw Karl Anderson's observation above, that "OAuth can be used for authentication, which can be thought of as a no-op authorization" that I saw any explicit confirmation that OAuth was good enough for what I wanted to do.

In fact, when I went to post this "answer", not being a member at the time, I looked long and hard at the bottom of this page at the options for identifying myself. The option for using an OpenID login or obtaining one if I didn't have one, but nothing about twitter or facebook, seemed to suggest that OAuth wasn't adequate for the job. But then I opened another window and looked for the general signup process for stackoverflow - and lo and behold there's a slew of 3rd-party authentication options including facebook and twitter. In the end I decided to use my google id (which is an OpenID) for exactly the reason that I didn't want to grant stackoverflow access to my friends list and anything else facebook likes to share about its users - but at least it's a proof point that OAuth is adequate for the use I had in mind.

It would really be great if someone could either post info or pointers to info about supporting this kind of multiple 3rd-part authorization setup, and how you deal with users that revoke authorization or lose access to their 3rd party site. I also get the impression that my username here identifies a unique stackoverflow account that I could access with basic authentication if I wanted to set it up, and also access this same account through other 3rd-party authenticators (e.g. so that I would be considered logged in to stackoverflow if I was logged in to any of google, facebook, or twitter...). Since this site is doing it, somebody here probably has some pretty good insight on the subject. :-)

Sorry this was so long, and more a question than an answer - but Karl's remark made it seem like the most appropriate place to post amidst the volume of threads on OAuth and OpenID. If there's a better place for this that I didn't find, I apologize in advance, I did try.

---

• OpenID is an open standard and decentralized authentication protocol controlled by the OpenID Foundation.
• OAuth is an open standard for access delegation.
• OpenID Connect (OIDC) Combines the features of OpenID and OAuth i.e. does both Authentication and Authorization.

OpenID take the form of a unique URI managed by some "OpenID provider" i.e identity provider (idP).

OAuth can be used in conjunction with XACML where OAuth is used for ownership consent and access delegation whereas XACML is used to define the authorization policies.

OIDC uses simple JSON Web Tokens (JWT), which you can obtain using flows conforming to the OAuth 2.0 specifications. OAuth is directly related to OIDC since OIDC is an authentication layer built on top of OAuth 2.0.

For example, if you chose to sign in to Auth0 using your Google account then you used OIDC. Once you successfully authenticate with Google and authorize Auth0 to access your information, Google will send back to Auth0 information about the user and the authentication performed. This information is returned in a JSON Web Token (JWT). You'll receive an Access Token and, if requested, an ID Token. Types of Token : Source: OpenID Connect

Analogy:
An Organisation use ID card for identification purpose and it contains chips, it stores details about Employee along with Authorization i.e. Campus/Gate/ODC access. ID Card act as a OIDC and Chip act as a OAuth. more examples and form wiki

---

OpenID proves who you are.

OAuth grants access to the features provided by the authorizing party.

---

I am currently working on OAuth 2.0 and OpenID connect spec. So here is my understanding: Earlier they were:

1. OpenID was proprietary implementation of Google allowing third party applications like for newspaper websites you can login using google and comment on an article and so on other usecases. So essentially, no password sharing to newspaper website. Let me put up a definition here, this approach in enterprise approach is called Federation. In Federation, You have a server where you authenticate and authorize (called IDP, Identity Provider) and generally the keeper of User credentials. the client application where you have business is called SP or Service Provider. If we go back to same newspaper website example then newspaper website is SP here and Google is IDP. In enterprise this problem was earlier solved using SAML. that time XML used to rule the software industry. So from webservices to configuration, everything used to go to XML so we have SAML, a complete Federation protocol

2. OAuth: OAuth saw it's emergence as an standard looking at all these kind of proprietary approaches and so we had OAuth 1.o as standard but addressing only authorization. Not many people noticed but it kind of started picking up. Then we had OAuth 2.0 in 2012. CTOs, Architects really started paying attention as world is moving towards Cloud computing and with computing devices moving towards mobile and other such devices. OAuth kind of looked upon as solving major problem where software customers might give IDP Service to one company and have many services from different vendors like salesforce, SAP, etc. So integration here really looks like federation scenario bit one big problem, using SAML is costly so let's explore OAuth 2.o. Ohh, missed one important point that during this time, Google sensed that OAuth actually doesn't address Authentication, how will IDP give user data to SP (which is actually wonderfully addressed in SAML) and with other loose ends like:

   a. OAuth 2.o doesn't clearly say, how client registration will happen b. it doesn't mention anything about the interaction between SP (Resource Server) and client application (like Analytics Server providing data is Resource Server and application displaying that data is Client)

There are already wonderful answers given here technically, I thought of giving of giving brief evolution perspective

---

OpenId uses OAuth to deal with authentication.

By analogy, it's like .NET relies on Windows API. You could directly call Windows API but it's so wide, complex and method arguments so vast, you could easily make mistakes/bugs/security issue.

Same with OpenId/OAuth. OpenId relies on OAuth to manage Authentication but defining a specific Token (Id_token), digital signature and particular flows.

---

I'd like to address a particular aspect of this question, as captured in this comment:

OAuth: before granting access to some feature, authentication must be done, right ?. so OAuth = what OpenId does + grants access to some features ? – Hassan Makarov Jun 21 at 1:57

Yes... and no. The answer is subtle, so bear with me.

When the OAuth flow redirects you to a target service (the OAuth provider, that is), it is likely that you'll need to authenticate with that service before a token will be handed back to the client application/service. The resulting token then allows the client app to make requests on behalf of a given user.

Note the generality of that last sentence: specifically, I wrote "on behalf of a given user", not "on behalf of you". It's a common error to assume that "having a capability to interact with a resource owned by a given user" implies "you and the owner of the target resource(s) are one in the same".

Don't make this mistake.

While it's true that you authenticate with the OAuth provider (say, by user name and password, or maybe SSL client certs, or some other means), what the client gets in return should not necessarily be taken as proof of identity. An example would be a flow in which access to another user's resources was delegated to you (and by proxy, the OAuth client). Authorization does not imply authentication.

To handle authentication, you'll likely want to look into OpenID Connect, which is essentially another layer on top of the foundation set by OAuth 2.0. Here's a quote that captures (in my opinion) the most salient points regarding OpenID Connect (from https://oauth.net/articles/authentication/):

OpenID Connect is an open standard published in early 2014 that defines an interoperable way to use OAuth 2.0 to perform user authentication. In essence, it is a widely published recipe for chocolate fudge that has been tried and tested by a wide number and variety of experts. Instead of building a different protocol to each potential identity provider, an application can speak one protocol to as many providers as they want to work with. Since it's an open standard, OpenID Connect can be implemented by anyone without restriction or intellectual property concerns.

OpenID Connect is built directly on OAuth 2.0 and in most cases is deployed right along with (or on top of) an OAuth infrastructure. OpenID Connect also uses the JSON Object Signing And Encryption (JOSE) suite of specifications for carrying signed and encrypted information around in different places. In fact, an OAuth 2.0 deployment with JOSE capabilities is already a long way to defining a fully compliant OpenID Connect system, and the delta between the two is relatively small. But that delta makes a big difference, and OpenID Connect manages to avoid many of the pitfalls discussed above by adding several key components to the OAuth base: [...]

The document then goes on to describe (among other things) token IDs and a UserInfo endpoint. The former provides a set of claims (who you are, when the token was issued, etc, and possibly a signature to verify the authenticity of the token via a published public key without having to ask the upstream service), and the latter provides a means of e.g. asking for the user's first/last name, email, and similar bits of info, all in a standardized way (as opposed to the ad-hoc extensions to OAuth that people used before OpenID Connect standardized things).

---

Both protocols were created for different reasons. OAuth was created to authorize third parties to access resources. OpenID was created to perform decentralize identity validation. This website states the following:

OAuth is a protocol designed to verify the identity of an end-user and to grant permissions to a third party. This verification results in a token. The third party can use this token to access resources on the user’s behalf. Tokens have a scope. The scope is used to verify whether a resource is accessible to a user, or not

OpenID is a protocol used for decentralised authentication. Authentication is about identity; Establishing the user is in fact the person who he claims to be. Decentralising that, means this service is unaware of the existence of any resources or applications that need to be protected. That’s the key difference between OAuth and OpenID.

---

OAuth 2.0 is a Security protocol. It is NEITHER an Authentication NOR an Authorization protocol.

Authentication by definition the answers two questions.

1. Who is the user?
2. Is the user currently present on the system?

OAuth 2.0 has the following grant types

• client_credentials: When one app needs to interact with another app and modify the data of multiple users.
• authorization_code: User delegates the Authorization server to issue an access_token that the client can use to access protected resource
• refresh_token: When the access_token expires, the refresh token can be leveraged to get a fresh access_token
• password: User provides their login credentials to a client that calls the Authorization server and receives an access_token

All 4 have one thing in common, access_token, an artifact that can be used to access protected resource.

The access_token does not provide the answer to the 2 questions that an "Authentication" protocol must answer.

An example to explain Oauth 2.0 (credits: OAuth 2 in Action, Manning publications)

Let's talk about chocolate. We can make many confections out of chocolate including, fudge, ice cream, and cake. But, none of these can be equated to chocolate because multiple other ingredients such as cream and bread are needed to make the confection, even though chocolate sounds like the main ingredient. Similarly, OAuth 2.0 is the chocolate, and cookies, TLS infrastucture, Identity Providers are other ingredients that are required to provide the "Authentication" functionality.

If you want Authentication, you may go for OpenID Connect, which provides an "id_token", apart from an access_token, that answers the questions that every authentication protocol must answer.

---

OAuth는 인증을 기반으로 인증을 구축합니다. 사용자는 애플리케이션에 자신의 ID에 대한 액세스 권한을 위임 한 다음 ID API의 소비자가되어 먼저 클라이언트에 권한을 부여한 사람을 찾습니다. http://oauth.net/ 기사 / 인증 /

참고 URL : https://stackoverflow.com/questions/1087031/whats-the-difference-between-openid-and-oauth