OAuth 권한 부여 및 인증

Question 1

OAuth 용어는 오랫동안 저를 괴롭 혔습니다. OAuth 인증은 일부가 제안하는 것처럼 또는 인증입니까?

내가 틀렸다면 저를 정정하십시오. 그러나 나는 항상 Authorization을 누군가가 리소스에 액세스하도록 허용하는 행위로 읽었지만 OAuth에는 실제로 사용자에게 주어진 리소스에 대한 액세스를 허용하는 구현이없는 것 같습니다. 모든 OAuth 구현에서 말하는 것은 사용자에게 토큰 (서명되고 때로는 암호화 됨)을 제공하는 것입니다. 그런 다음이 토큰은 OAuth 문제가 아닌 유효성을 확인하는 백엔드 서비스 끝점에 대한 모든 호출과 함께 전달됩니다.

OAuth 인증 (모든 기사에서 그렇지 않다고 말함)을 사용하려면 사용자가 자격 증명을 제공해야하는데, 이는 사용자가 액세스 권한을 가져야한다는 것을 증명하는 것입니까?

따라서 OAuth는 다른 프로세스에서 수행해야하기 때문에 Authorization NOR 인증이 아닌 것 같습니다. 그래서 도대체 무엇입니까? 토큰을 전달하는 프로세스입니까? 정말 특별한 의미가없는 보풀 한 말인가요?

수수께끼와 미신 (유령과 고블린)처럼 들리지 않고이 주제에 대해 질문하기가 어렵 기 때문에이 질문에 대답하는 것도 간단한 일이 아닐 것으로 예상합니다. 자신의 책임하에 입력하십시오.

Question 2

OAuth는 인증을위한 사양입니다.

OAuth 2.0은 인증을위한 사양이지만 인증을위한 것이 아닙니다. RFC 6749, 3.1. Authorization Endpoint 는 다음과 같이 명시 적으로 말합니다.

권한 부여 끝점은 리소스 소유자와 상호 작용하고 권한 부여를 얻는 데 사용됩니다. 권한 부여 서버는 먼저 자원 소유자의 신원을 확인해야합니다. 인증 서버가 리소스 소유자를 인증하는 방법 (예 : 사용자 이름 및 비밀번호 로그인, 세션 쿠키) 은이 사양의 범위를 벗어납니다 .

OAuth 인증?

인증은 "누군가"에 대한 정보를 다룹니다. 승인은 "누가 누구에게 어떤 권한을 부여하는지"에 대한 정보를 다룹니다. 인증 흐름에는 첫 번째 단계로 인증이 포함됩니다. 사람들이 종종 혼란스러워하는 이유입니다.

인증을 위해 OAuth 2.0을 사용하는 많은 라이브러리와 서비스가 있습니다. 종종 "소셜 로그인"이라고 불리며 사람들을 더 혼란스럽게 만듭니다. "OAuth 인증"( "OAuth 인증"아님)이 표시되면 인증에 OAuth를 사용하는 솔루션입니다.

OpenID 연결

OpenID 1.0 및 OpenID 2.0은 인증을위한 이전 사양입니다. 사양을 만든 사람들은 사람들이 인증을 위해 OpenID를 사용할 것으로 예상했습니다. 그러나 일부 사람들은 인증을 위해 OAuth 2.0을 사용하기 시작했고 (권한이 아닌) OAuth 인증이 빠르게 보급되었습니다.

OpenID 사용자의 관점에서 OAuth 기반 인증은 충분히 안전하지 않지만 사람들이 OAuth 인증을 선호한다는 것을 인정해야했습니다. 결과적으로 OpenID 직원들은 OAuth 2.0 위에 새로운 사양 인 OpenID Connect 를 정의하기로 결정했습니다 .

예, 이것은 사람들을 훨씬 더 혼란스럽게 만들었습니다.

OAuth 2.0 및 OpenID Connect의 한 문장 정의

OAuth 2.0 은 서비스 사용자가 애플리케이션에 자신의 자격 증명 (ID 및 비밀번호)을 공개하지 않고 타사 애플리케이션이 서비스에 호스팅 된 데이터에 액세스하도록 허용 할 수있는 프레임 워크입니다.

OpenID Connect 는 타사 애플리케이션이 서비스에서 관리하는 사용자의 ID 정보를 얻을 수있는 OAuth 2.0 기반의 프레임 워크입니다.

^{(죄송합니다.이 정의는 회사 개요 페이지 에서 발췌 한 것입니다.)}

구현 자의 관점에서 본 정의

인증 은 최종 사용자의 주체 (= 고유 식별자)를 결정하는 프로세스입니다. 주제를 결정하는 방법에는 여러 가지가 있습니다. 아이디 및 비밀번호, 지문, 홍채 인식 등

권한 부여 는 주체를 요청 된 권한 및 권한을 요청한 클라이언트 응용 프로그램과 연결하는 프로세스입니다. 액세스 토큰은 연결을 나타냅니다.