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 개념이 없으므로 로그인에 사용한다는 것은 사용자 정의 매개 변수를 추가하거나 (트위터에서 수행 한대로) 현재 "로그인 한"사용자를 얻기 위해 다른 API 호출을하는 것을 의미합니다.

3. 기술 구현

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

각 프로토콜은 요청 또는 응답의 진위 여부를 확인하는 데 사용되는 서명을 계산하는 방법이 다르며 각각 등록 요구 사항이 다릅니다.

OpenID는 (주로) 식별 / 인증을위한 것이므로 stackoverflow.com본인은 chris.boyle.name(또는 어디에서든) 알고 있으므로 chris.boyle.name어제 소유하고 평판이 좋은 사람 일 가능성이 높습니다 .

OAuth는 사용자를 대신하여 조치를 취할 수 있도록 권한 부여 용으로 설계되어 stackoverflow.comTwitter 비밀번호를 몰라도 자동으로 트윗 할 수있는 권한을 요청할 수 있습니다.

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

무료 위키 백과

OAuth

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

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

OpenID

사용 authenticate 단일 로그온 정체성. 모든 OpenID는 OpenID 제공자가 귀하의 말을 증명할 수 있도록해야합니다. 그러나 많은 사이트에서 ID 인증을 사용하여 권한을 제공합니다 (그러나 두 사이트를 분리 할 수는 있음)

즉, 하나는 공항에서 자신의 이름을 가진 사람의 이름이 자신이 사용하는 티켓임을 증명 (또는 증명)하기 위해 여권을 보여줍니다.

사용자가 Facebook 또는 Twitter로 로그인하려는 경우 OAuth를 사용하십시오. 사용자가 "다른 사람이 자신의 ID를 소유하고 싶지 않기 때문에"자신의 OpenID 공급자를 실행하는 목 수염 인 경우 OpenID를 사용하십시오.

• OpenID 는 OpenID Foundation에서 제어 하는 개방형 표준 및 분산 인증 프로토콜입니다.
• OAuth 는 액세스 위임을위한 공개 표준 입니다.
• OIDC ( OpenID Connect ) OpenID와 OAuth의 기능을 결합하여 인증과 권한 부여를 모두 수행합니다.

OpenID 는 일부 "OpenID 공급자", 즉 ID 공급자 (idP)가 관리 하는 고유 한 URI 형식을 취합니다 .

OAuth 는 소유권 동의 및 액세스 위임에 OAuth가 사용되는 반면 XACML은 권한 부여 정책을 정의하는 데 사용되는 XACML과 함께 사용할 수 있습니다.

OIDC 는 간단한 JWT (JSON Web Web Token)를 사용하며, OAuth 2.0 사양을 준수하는 플로우를 사용하여 얻을 수 있습니다 . OIDC 는 OAuth 2.0 위에 구축 된 인증 계층 이므로 OAuth 는 OIDC 와 직접 관련됩니다 .

예를 들어 , Google 계정을 사용하여 Auth0 에 로그인하기로 선택한 경우 OIDC 를 사용 했습니다 . Google 인증에 성공하고 Auth0 이 귀하의 정보에 액세스 하도록 승인 하면 Google은 사용자 및 수행 된 인증에 대한 Auth0 정보를 다시 보냅니다 . 이 정보는 JSON 웹 토큰 (JWT)으로 반환됩니다 . 액세스 토큰과 요청이있을 경우 ID 토큰을 받게됩니다. 토큰 유형 : 출처 : OpenID Connect

유추 :
조직 사용 ID를 식별하기위한 목적 카드는 칩을 포함하고, 그것과 함께 직원에 대한 세부 정보를 저장하는 권한 즉, 캠퍼스 / 문 / ODC에 액세스 할 수 있습니다. ID 카드는 OIDC 역할을 하고 칩 은 OAuth 역할을합니다 . 더 많은 예제 와 양식 위키

OpenID 및 OAuth는 각각 인증 및 / 또는 권한 부여를위한 HTTP 기반 프로토콜입니다. 두 가지 모두 사용자가 클라이언트 또는 타사에 인증 자격 증명이나 담요 권한을 부여하지 않고도 작업을 수행 할 수 있도록 고안되었습니다. 그것들은 비슷하고, 둘을 함께 사용하기 위해 제안 된 표준이 있지만, 그것들은 별도의 프로토콜입니다.

OpenID는 페더레이션 인증을위한 것입니다. 클라이언트는 모든 제공자로부터 신원 주장을 수락합니다 (클라이언트는 제공자를 무료로 허용하거나 블랙리스트에 추가 할 수 있지만).

OAuth는 위임 된 권한 부여를위한 것입니다. 클라이언트는 공급자를 등록하며, 사용자를 대신하여 조치를 수행하기 위해 승인 토큰을 제공합니다.

인증 후 추가 상호 작용이 프로토콜에 내장되어 있지만 두 프로토콜이 모두 발전하고 있기 때문에 OAuth는 현재 권한 부여에 더 적합합니다. OpenID 및 해당 확장은 권한 부여에 사용될 수 있고 OAuth는 인증에 사용될 수 있으며 인증이 필요하지 않은 것으로 간주 될 수 있습니다.

의견에서 지적 했듯이이 질문을 다시 방문하는 것이 합리적이라고 생각합니다. 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는 서버 A에 액세스 권한을 부여 할 수 있습니다. 따라서 B는 너무 많은 전력을 공급하지 않고 임시로 특정 액세스 키를 A에 전달할 수 있습니다. 큰 호텔에서 OAuth 서버를 핵심 마스터로 생각할 수 있습니다. 그는 직원들에게 들어가야 할 방의 문을 여는 열쇠를 주지만 각 열쇠는 제한되어 있습니다 (모든 방에 대한 접근 권한을 부여하지는 않습니다). 또한 몇 시간이 지나면 키가 자체 파괴됩니다.

어느 정도까지 엔티티 A가 B로부터 OAuth를 통해 액세스 키를 가져 와서 서버 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이며 인증 된 사용자에 대한 정보를 포함합니다. 아이덴티티 공급자가 서명하며 아이덴티티 공급자에 액세스하지 않고도 읽고 확인할 수 있습니다.

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

이를 통해 사용자가 여러 자격 증명 공급자 중에서 선택할 수있는 코드를보다 쉽게 ​​작성할 수 있습니다.

(출처)

구글의 OAuth 2.0

Google의 OAuth 2.0 API는 인증 및 권한 부여에 모두 사용될 수 있습니다. 이 문서는 OpenID Connect 사양을 준수하며 OpenID 인증을받은 인증을위한 OAuth 2.0 구현에 대해 설명합니다. OAuth 2.0을 사용하여 Google API에 액세스 의 문서 도이 서비스에 적용됩니다. 이 프로토콜을 대화식으로 탐색하려면 Google OAuth 2.0 Playground를 권장합니다 .

(출처)

답변보다 질문에 대한 확장이 많지만 위의 훌륭한 기술 답변에 대한 관점이 추가 될 수 있습니다. 저는 여러 분야에서 숙련 된 프로그래머이지만 웹 프로그래밍에 대한 멍청한 놈입니다. 이제 Zend Framework를 사용하여 웹 기반 응용 프로그램을 구축하려고합니다.

확실히 응용 프로그램 별 기본 사용자 이름 / 암호 인증 인터페이스를 구현하지만 점점 더 많은 사용자에게 또 다른 사용자 이름과 암호에 대한 생각이 억제 적이라는 것을 인식하십시오. 정확히 소셜 네트워킹은 아니지만 응용 프로그램의 잠재적 인 사용자 중 상당수가 이미 페이스 북이나 트위터 계정을 가지고 있다는 것을 알고 있습니다. 응용 프로그램은 실제로 해당 사이트에서 사용자 계정에 대한 정보를 원하거나 액세스 할 필요가 없으며, 원하지 않는 경우 사용자가 새 계정 자격 증명을 설정하지 않아도되는 편리함을 제공하고자합니다. 기능적인 관점에서 보면 OpenID의 포스터 자식처럼 보입니다. 그러나 페이스 북이나 트위터는 OpenID 제공 업체가 아닌 것으로 보이지만 사용자 데이터에 액세스하기 위해 OAuth 인증을 지원합니다.

두 기사와 그 차이점에 대해 읽은 모든 기사에서 위의 Karl Anderson의 관찰을 볼 때까지 "OAuth는 인증에 사용될 수 있으며 이는 승인이없는 승인으로 생각할 수 있습니다." OAuth가 내가하고 싶은 일에 충분하다는 명백한 확인을 보았습니다.

사실, 당시의 회원이 아닌이 "답변"을 게시하려고 할 때, 나는이 페이지의 맨 아래에서 자신을 식별하기위한 옵션을 길고 열심히 보았습니다. OpenID 로그인을 사용하거나 로그인하지 않았지만 트위터 나 페이스 북에 대한 정보가없는 경우 로그인하는 옵션은 OAuth가 작업에 적합하지 않은 것으로 나타났습니다. 그러나 다른 창을 열고 stackoverflow에 대한 일반 가입 프로세스를 찾았습니다. 그리고 페이스 북과 트위터를 포함한 많은 타사 인증 옵션이 있습니다. 결국 나는 내 Google ID (OpenID)를 사용하기로 결정했기 때문에 친구 목록 및 페이스 북이 사용자에 대해 공유하기를 좋아하는 다른 항목에 스택 오버 플로우 액세스 권한을 부여하고 싶지는 않습니다.

누군가 이러한 종류의 여러 타사 인증 설정 지원에 대한 정보 또는 정보에 대한 포인터를 게시하고 인증을 취소하거나 타사 사이트에 대한 액세스 권한을 상실하는 사용자를 처리하는 방법에 대한 정보를 게시 할 수 있다면 정말 좋을 것입니다. 또한 여기에서 내 사용자 이름이 기본 인증으로 설정하고 다른 타사 인증자를 통해 동일한 계정에 액세스 할 수있는 고유 한 스택 오버 플로우 계정을 식별한다는 인상을 얻습니다 (예 : 로그 된 것으로 간주됩니다) Google, Facebook 또는 Twitter에 로그인 한 경우 stackoverflow에 로그인하십시오 ...). 이 사이트가 그 일을하고 있기 때문에, 여기 누군가가 아마도 그 주제에 대해 꽤 좋은 통찰력을 가지고있을 것입니다. :-)

죄송합니다. 답변이 너무 길어서 질문이 많았습니다. 그러나 Karl의 발언은 OAuth 및 OpenID의 스레드 볼륨 중에 게시하기에 가장 적합한 장소 인 것 같습니다. 내가 찾을 수없는 더 좋은 곳이 있다면 미리 사과드립니다.

OpenID 는 당신이 누구인지 증명합니다.

OAuth 는 승인 당사자가 제공 한 기능에 대한 액세스 권한을 부여합니다.

현재 OAuth 2.0 및 OpenID 연결 사양을 연구 중입니다. 여기 내 이해가 있습니다.

1. OpenID는 Google이 독점적으로 구현 한 것으로 신문 웹 사이트와 같은 타사 애플리케이션을 사용하면 Google을 사용하여 로그인하고 기사 및 기타 유스 케이스에 댓글을 달 수 있습니다. 따라서 기본적으로 신문 웹 사이트에 비밀번호를 공유하지 않습니다. 여기에 정의를 두겠습니다. 엔터프라이즈 접근 방식에서이 접근 방식을 페더레이션이라고합니다. 페더레이션에는 인증 및 권한을 부여한 서버 (IDP, 아이덴티티 공급자)와 일반적으로 사용자 자격 증명 키퍼가 있습니다. 비즈니스가있는 클라이언트 응용 프로그램을 SP 또는 서비스 공급자라고합니다. 동일한 신문 웹 사이트 예로 돌아 가면 신문 웹 사이트는 SP이고 Google은 IDP입니다. 기업에서는이 문제가 SAML을 사용하여 이전에 해결되었습니다. 당시 XML은 소프트웨어 산업을 지배하는 데 사용되었습니다. 따라서 웹 서비스에서 구성에 이르기까지 모든 것이 XML로 이동하여 SAML을

2. OAuth : OAuth는 이러한 모든 독점적 접근 방식을 검토하는 표준으로 부상 한 것으로 보았으므로 OAuth 1.o를 표준으로 사용했지만 권한 만 처리했습니다. 많은 사람들이 눈치 채지 못했지만 일종의 픽업을 시작했습니다. 그 다음에 2012 년에 OAuth 2.0을 사용했습니다. CTO, Architects는 세계가 클라우드 컴퓨팅으로 이동하고 컴퓨팅 장치가 모바일 및 기타 장치로 이동함에 따라 실제로 주목하기 시작했습니다. OAuth는 소프트웨어 고객이 한 회사에 IDP 서비스를 제공하고 salesforce, SAP 등과 같은 여러 공급 업체의 많은 서비스를 제공 할 수있는 주요 문제를 해결하는 것으로 보았습니다. 따라서 SAML을 사용하는 것은 페더레이션 시나리오에서 하나의 큰 문제로 보입니다. OAuth 2.o를 살펴 보겠습니다. 이 시점에서 구글은 OAuth가 실제로

   ㅏ. OAuth 2.o는 클라이언트 등록이 어떻게 발생하는지 명확하게 말하지 않습니다. b. SP (Resource Server)와 클라이언트 응용 프로그램 간의 상호 작용에 대해서는 언급하지 않습니다 (데이터를 제공하는 Analytics Server는 Resource Server이고 해당 데이터를 표시하는 응용 프로그램은 Client 임).

기술적으로 여기에 훌륭한 답변이 있습니다. 나는 간단한 진화 관점을 줄 것이라고 생각했습니다.

OpenId는 OAuth를 사용하여 인증을 처리합니다.

유사하게, .NET이 Windows API에 의존하는 것과 같습니다. Windows API를 직접 호출 할 수는 있지만 너무 광범위하고 복잡하며 메서드 인수가 너무 커서 실수 / 버그 / 보안 문제를 쉽게 만들 수 있습니다.

OpenId / OAuth와 동일합니다. OpenId는 OAuth를 사용하여 인증을 관리하지만 특정 토큰 (Id_token), 디지털 서명 및 특정 흐름을 정의합니다.

이 의견에서 파악한 것처럼이 질문의 특정 측면을 다루고 싶습니다.

OAuth : 일부 기능에 대한 액세스 권한을 부여하기 전에 인증을 수행해야합니다. OAuth = OpenId는 어떤 기능에 대한 액세스 권한을 부여합니까? – Hassan Makarov 6 월 21 일 1시 57 분

예 ... 아니요 답은 미묘하므로 나와 함께 견뎌내십시오.

의 OAuth 흐름이 대상 서비스 (인 OAuth를 제공,)로 리디렉션 할 때 입니다 토큰은 클라이언트 응용 프로그램 / 서비스에 손으로 돌아올 전에 해당 서비스를 인증해야합니다 가능성이 높습니다. 결과 토큰은 클라이언트 앱이 지정된 사용자 대신 요청을 할 수 있도록합니다.

마지막 문장의 일반성을 주목하십시오. 구체적으로, 나는 " 당신 을 대신하여 "가 아니라 " 주어진 사용자를 위해"를 썼습니다 . "주어진 사용자가 소유 한 리소스와 상호 작용할 수있는 능력을 갖는다"는 것은 "귀하와 귀하가 대상 리소스의 소유자가 동일하다는 것을 암시합니다"라고 가정하는 것은 일반적인 오류입니다.

이 실수하지 마십시오.

OAuth 제공자 (예 : 사용자 이름 및 비밀번호 또는 SSL 클라이언트 인증서 또는 기타 다른 수단)로 인증하는 것이 사실이지만 클라이언트가받는 것을 반드시 신원 증명으로 간주 해서는 안됩니다 . 다른 사용자의 리소스에 대한 액세스가 위임 된 흐름이 그 예입니다 된 사용자 (및 프록시 인 OAuth 클라이언트)가 있습니다. 인증은 인증을 의미하지 않습니다.

인증을 처리하기 위해 OpenAuth Connect를 살펴볼 수 있습니다. OpenID Connect는 본질적으로 OAuth 2.0에서 설정 한 기초 위에 또 다른 계층입니다. https://oauth.net/articles/authentication/ 에서 OpenID Connect와 관련하여 가장 두드러진 점을 포착 한 인용문은 다음과 같습니다 .

OpenID Connect는 OAuth 2.0을 사용하여 사용자 인증을 수행하는 상호 운용 가능한 방법을 정의하는 2014 년 초에 공개 된 공개 표준입니다. 본질적으로, 그것은 다양한 전문가들에 의해 시도되고 테스트 된 초콜릿 퍼지에 대해 널리 공개 된 레시피입니다. 응용 프로그램은 각각의 잠재적 아이덴티티 공급자에 대해 서로 다른 프로토콜을 구축하는 대신 작업하려는만큼 많은 공급자에게 하나의 프로토콜을 말할 수 있습니다. 개방형 표준이므로 OpenID Connect는 제한이나 지적 재산권 문제없이 누구나 구현할 수 있습니다.

OpenID Connect는 OAuth 2.0에 직접 구축되며 대부분 OAuth 인프라와 함께 (또는 그 위에) 배포됩니다. OpenID Connect는 또한 서명 및 암호화 된 정보를 다른 장소로 운반하기 위해 JSON (JSON Object Signing And Encryption) 사양 세트를 사용합니다. 실제로, JOSE 기능이있는 OAuth 2.0 배치는 이미 완전히 호환되는 OpenID Connect 시스템을 정의하기위한 먼 길이며,이 둘 사이의 델타는 비교적 작습니다. 그러나이 델타는 큰 차이를 만들어냅니다. OpenID Connect는 OAuth 기반에 몇 가지 주요 구성 요소를 추가하여 위에서 논의한 많은 위험을 피할 수 있습니다. [...]

그런 다음 문서는 토큰 ID 및 UserInfo 엔드 포인트를 설명합니다. 전자는 일련의 클레임 (귀하가 누구인지, 토큰이 발행 된시기 등) 및 업스트림 서비스를 요청 하지 않고 공개 된 공개 키를 통해 토큰의 진위 여부를 확인하는 서명을 제공합니다. 예를 들어, 사람들이 OpenID Connect 이전에 표준화 한 OAuth에 대한 임시 확장과 달리, 사용자의 이름 / 성, 전자 메일 및 유사한 정보 비트를 모두 표준화 된 방식으로 요청하는 수단.

두 프로토콜 모두 다른 이유로 만들어졌습니다. OAuth는 제 3자가 리소스에 액세스 할 수있는 권한을 부여하기 위해 만들어졌습니다. OpenID는 분산 ID 확인을 수행하기 위해 만들어졌습니다. 이 웹 사이트 에는 다음 이 명시되어 있습니다.

OAuth는 최종 사용자의 신원을 확인하고 타사에 권한을 부여하도록 설계된 프로토콜입니다. 이 검증은 토큰이됩니다. 타사는이 토큰을 사용하여 사용자 대신 리소스에 액세스 할 수 있습니다. 토큰에는 범위가 있습니다. 범위는 사용자가 리소스에 액세스 할 수 있는지 여부를 확인하는 데 사용됩니다.

OpenID는 분산 인증에 사용되는 프로토콜입니다. 인증은 신원에 관한 것입니다. 사용자를 설립하는 것은 실제로 그가 주장하는 사람입니다. 이를 분산시키는 것은이 서비스가 보호해야 할 자원이나 응용 프로그램의 존재를 인식하지 못한다는 것을 의미합니다. 이것이 OAuth와 OpenID의 주요 차이점입니다.

OpenID Connect는 OAuth 2.0 인증 프로토콜을 확장하여 인증 프로토콜로 사용하므로 OAuth를 사용하여 싱글 사인온을 수행 할 수 있습니다. OpenID Connect는 클라이언트가 사용자의 신원을 확인할 수 있도록하는 보안 토큰 인 ID 토큰의 개념을 소개합니다

OAuth 2.0은 보안 프로토콜입니다. 인증이나 인증 프로토콜이 아닙니다.

정의에 의한 인증은 두 가지 질문에 대한 답변입니다.

1. 사용자는 누구입니까?
2. 사용자가 현재 시스템에 있습니까?

OAuth 2.0에는 다음과 같은 보조금 유형이 있습니다

• client_credentials : 한 앱이 다른 앱과 상호 작용하고 여러 사용자의 데이터를 수정해야하는 경우
• authorization_code : 사용자는 권한 부여 서버가 클라이언트가 보호 된 자원에 액세스하는 데 사용할 수있는 access_token을 발행하도록 위임합니다.
• refresh_token : access_token이 만료되면 새로 고침 토큰을 활용하여 새로운 access_token을 얻을 수 있습니다
• 비밀번호 : 사용자는 권한 부여 서버를 호출하고 access_token을받는 클라이언트에 로그인 신임 정보를 제공합니다.

4 개 모두 공통된 하나 인 access_token을 가지고 있는데, 이는 보호 자원에 액세스하는 데 사용할 수있는 아티팩트입니다.

access_token은 "인증"프로토콜이 답변해야하는 두 가지 질문에 대한 답변을 제공하지 않습니다.

Oauth 2.0을 설명 하는 예 (신용 : OAuth 2 in Action, Manning 서적)

초콜릿에 대해 이야기합시다. 초콜릿, 퍼지, 아이스크림 및 케이크를 포함한 많은 과자를 초콜릿으로 만들 수 있습니다. 그러나 초콜릿이 주성분처럼 들리더라도 크림과 빵과 같은 여러 가지 다른 성분이 과자를 만드는 데 필요하기 때문에 이들 중 어느 것도 초콜릿과 동일 할 수 없습니다. 마찬가지로 OAuth 2.0은 초콜릿이며 쿠키, TLS 인프라, 아이덴티티 공급자는 "인증"기능을 제공하는 데 필요한 다른 구성 요소입니다.

인증을 원하면 access_token과는 별도로 "id_token"을 제공하는 OpenID Connect를 사용하여 모든 인증 프로토콜이 답변해야하는 질문에 답변 할 수 있습니다.

OAuth는 권한 부여를 기반으로 인증을 구축합니다. 사용자는 자신의 ID에 대한 액세스 권한을 응용 프로그램에 위임 한 다음 ID API의 소비자가되므로 먼저 http://oauth.net/ 에서 클라이언트를 승인 한 사람을 찾습니다. 기사 / 인증 /