OAuth 2.0 : 이점 및 사용 사례 – 이유는 무엇입니까?

누구나 OAuth2의 장점과이를 구현해야하는 이유를 설명 할 수 있습니까? 나는 그것에 대해 약간 혼란스러워서 묻습니다. 현재 생각은 다음과 같습니다.

OAuth1 (보다 정확하게 HMAC) 요청은 논리적이고 이해하기 쉽고 개발하기 쉽고 실제로 안전 해 보입니다.

대신 OAuth2는 권한 부여 요청, 액세스 토큰 및 새로 고침 토큰을 가져 오며, 세션 시작시 3 번의 요청을 수행하여 이후의 데이터를 가져와야합니다. 그러면 토큰이 만료되면 요청 중 하나가 결국 실패하게됩니다.

그리고 다른 액세스 토큰을 얻으려면 액세스 토큰과 동시에 전달 된 새로 고침 토큰을 사용하십시오. 이것이 보안 관점에서 액세스 토큰을 무용지물로 만드는가?

또한 / r / netsec이 최근에 보여 주듯이 SSL이 완전히 안전하지는 않으므로 안전한 HMAC 대신 TLS / SSL로 모든 것을 가져 오려는 노력으로 인해 혼란을 겪습니다.

OAuth는 안전이 약 100 %가 아니라 게시 및 완료한다고 주장하고 있습니다. 그것은 제공자의 관점에서 유망한 것으로 들리지 않습니다. 6 가지 흐름을 언급 할 때 초안이 달성하려는 것을 볼 수 있지만 머리에 맞지 않습니다.

나는 그것이 실제로 그것을 싫어하는 것보다 이점과 추론을 이해하는 것이 더 힘들 것이라고 생각하므로, 이것은 부당한 공격 일 수 있으며, 이것이 파문처럼 보일 수 있다면 미안합니다.

배경 : OAuth 1.0a 및 2.0에 대한 클라이언트 및 서버 스택을 작성했습니다.

OAuth 1.0a 및 2.0은 모두 서버가 사용자의 신원을 보증하는 2 다리 인증 및 서버가 사용자의 신원을 콘텐츠 제공자에 의해 보장하는 3 다리 인증 을 지원합니다. 3 단계 인증은 권한 부여 요청 및 액세스 토큰이 작동하는 위치이며 OAuth 1도 마찬가지입니다.

복잡한 것 : 세 다리 인증

의 OAuth 사양의 주요 포인트는위한 콘텐츠 제공 보장하기 위해 (예를 들어, 페이스 북, 트위터 등) 서버 (예 : 웹 응용 프로그램이 클라이언트를 대신하여 컨텐츠 공급자에 대한 토론 소원) 클라이언트가 어떤 정체성을 가지고 . 3-legged 인증이 제공하는 기능은 클라이언트 또는 서버 가 해당 ID의 세부 정보 (예 : 사용자 이름 및 비밀번호) 를 알 필요 가없이 수행 할 수 있다는 것 입니다.

OAuth의 세부 사항에 너무 깊이 들어 가지 않으면 (?) :

1. 클라이언트는 서버에 권한 부여 요청을 제출하여 클라이언트가 서비스의 합법적 인 클라이언트인지 확인합니다.
2. 서버는 클라이언트를 컨텐츠 제공자로 경로 재지 정하여 해당 자원에 대한 액세스를 요청합니다.
3. 콘텐츠 공급자는 사용자의 신원을 확인하고 종종 리소스 액세스 권한을 요청합니다.
4. 콘텐츠 공급자는 클라이언트를 서버로 다시 리디렉션하여 성공 또는 실패를 알립니다. 이 요청에는 성공시 인증 코드가 포함됩니다.
5. 서버는 콘텐츠 공급자에게 대역 외 요청을하고 인증 코드를 액세스 토큰으로 교환합니다.

서버는 이제 액세스 토큰을 전달하여 사용자 대신 컨텐츠 제공자에게 요청을 할 수 있습니다.

각 교환 (클라이언트-> 서버, 서버-> 콘텐츠 제공자)은 공유 비밀의 유효성 검증을 포함하지만 OAuth 1은 암호화되지 않은 연결을 통해 실행될 수 있으므로 각 유효성 검증은 유선을 통해 비밀을 전달할 수 없습니다.

이미 언급했듯이 HMAC를 사용하면됩니다. 클라이언트는 서버와 공유하는 비밀을 사용하여 권한 부여 요청에 대한 인수에 서명합니다. 서버는 인수를 가져 와서 클라이언트 키로 서명하고, 정당한 클라이언트인지 여부를 확인할 수 있습니다 (위의 1 단계).

이 서명은 클라이언트와 서버 모두 인수의 순서에 동의해야하며 (따라서 정확히 동일한 문자열에 서명해야 함) OAuth 1에 대한 주요 불만 중 하나는 서버와 클라이언트가 모두 동일하게 서명하십시오. 이것은 어리석은 코드이며 옳거나 401 Unauthorized거의 도움이되지 않습니다. 이로 인해 클라이언트 작성에 대한 장벽이 높아집니다.

인증 요청이 SSL을 통해 실행되도록 요구함으로써 OAuth 2.0은 인수 정렬 및 서명이 불필요합니다. 클라이언트는 자신의 비밀을 서버로 전달하여 서버를 직접 확인합니다.

서버-> 콘텐츠 제공자 연결에도 동일한 요구 사항이 있으며 이는 SSL이 OAuth 서비스에 액세스하는 서버를 작성하는 데있어 하나의 장벽을 제거하므로 SSL입니다.

따라서 위의 1, 2 및 5 단계에서 작업이 훨씬 쉬워집니다.

따라서이 시점에서 서버에는 사용자와 동등한 사용자 이름 / 비밀번호 인 영구 액세스 토큰이 있습니다. 요청의 일부로 (질의 인수, HTTP 헤더 또는 POST 양식 데이터로) 해당 액세스 토큰을 전달하여 사용자 대신 컨텐츠 제공자에게 요청을 작성할 수 있습니다.

컨텐츠 서비스가 SSL을 통해서만 액세스되면 완료됩니다. 일반 HTTP를 통해 사용할 수 있다면 어떤 방식 으로든 영구 액세스 토큰을 보호하고 싶습니다. 연결을 스니핑하는 사람은 사용자의 콘텐츠에 영원히 액세스 할 수 있습니다.

OAuth 2에서 해결되는 방식은 새로 고침 토큰 입니다. 새로 고침 토큰은 영구적 인 암호가되며 SSL을 통해서만 전송 됩니다. 서버가 컨텐츠 서비스에 액세스해야하는 경우 새로 고침 토큰을 단기 액세스 토큰으로 교환합니다. 그렇게하면 스니핑 가능한 모든 HTTP 액세스가 만료되는 토큰으로 이루어집니다. Google은 OAuth 2 API에서 5 분 만료를 사용하고 있습니다.

따라서 새로 고침 토큰 외에도 OAuth 2는 클라이언트, 서버 및 컨텐츠 제공자 간의 모든 통신을 단순화합니다. 또한 새로 고침 토큰은 콘텐츠에 암호화되지 않은 상태로 액세스 할 때만 보안을 제공하기 위해 존재합니다.

두 다리 인증

그러나 때로는 서버가 자체 컨텐츠에 대한 액세스를 제어하기 만하면됩니다. 클라이언트는 두 다리 인증을 통해 서버로 직접 사용자를 인증 할 수 있습니다.

OAuth 2는 널리 사용되는 OAuth 1의 일부 확장을 표준화합니다. 내가 가장 잘 아는 것은 Twitter에서 xAuth 로 소개 한 것 입니다. OAuth 2에서 리소스 소유자 비밀번호 자격 증명 으로 볼 수 있습니다 .

기본적으로 사용자의 자격 증명 (사용자 이름 및 비밀번호)으로 클라이언트를 신뢰할 수있는 경우, 컨텐츠 제공자와 직접 액세스 토큰을 교환 할 수 있습니다. 이렇게하면 3 개의 인증을 통해 모바일 앱에서 OAuth가 훨씬 더 유용 해집니다. 콘텐츠 서버의 인증 프로세스를 처리하려면 HTTP보기를 포함시켜야합니다.

OAuth 1에서는 공식 표준의 일부가 아니 었으며 다른 모든 요청과 동일한 서명 절차가 필요했습니다.

방금 리소스 소유자 암호 자격 증명을 사용하여 OAuth 2의 서버 측을 구현했으며 클라이언트 관점에서 액세스 토큰을 얻는 것이 간단 해졌습니다. 서버에서 액세스 토큰을 요청하고 클라이언트 ID / 비밀을 HTTP 인증 헤더로 전달하고 양식 데이터로서의 사용자 로그인 / 암호.

장점 : 단순성

따라서 구현 자의 관점에서 OAuth 2에서 볼 수있는 주요 장점은 복잡성이 줄어든다는 것입니다. 요청 서명 절차가 필요하지는 않지만 정확하게 어렵지는 않지만 확실합니다. 서비스의 클라이언트 역할을하는 데 필요한 작업을 크게 줄입니다 (현대 모바일 세상에서) 당신은 고통을 최소화하고자합니다. 서버-> 컨텐츠 제공자 엔드의 복잡성이 줄어듦에 따라 데이터 센터의 확장 성이 향상되었습니다.

그리고 현재 널리 사용되고있는 OAuth 1.0a (xAuth와 같은)의 일부 확장을 표준으로 체계화합니다.

먼저 OAuth 인증에 명확하게 표시된대로

OAuth 2.0은 인증 프로토콜이 아닙니다.

응용 프로그램에 액세스하는 사용자의 컨텍스트에서 인증하면 응용 프로그램에 현재 사용자가 누구인지, 존재하는지 여부를 알려줍니다. 완전한 인증 프로토콜은 고유 식별자, 이메일 주소 및 애플리케이션이 "Good Morning"이라고 말할 때 호출 할 항목과 같은이 사용자에 대한 여러 속성을 알려줄 것입니다.

그러나 OAuth는 응용 프로그램에 아무 것도 알려주지 않습니다. OAuth는 사용자에 대해 전혀 아무 것도 말하지 않으며 사용자가 자신의 존재를 어떻게 증명했는지 또는 여전히 존재하는지 여부를 말하지 않습니다. OAuth 클라이언트와 관련하여 토큰을 요청하고 토큰을 얻은 다음 해당 토큰을 사용하여 일부 API에 액세스했습니다. 누가 응용 프로그램을 인증했는지 또는 사용자가 있는지 여부는 알 수 없습니다.

OAuth2와 호환되는 OAuth : OpenID Connect를 사용하는 사용자 인증 표준이 있습니다.

OpenID Connect ID 토큰은 일반 OAuth 액세스 토큰과 함께 클라이언트 애플리케이션에 제공되는 서명 된 JSON 웹 토큰 (JWT)입니다. ID 토큰에는 사용자 (하위)의 식별자, 토큰을 발행 한 아이덴티티 공급자의 식별자 (iss) 및이 토큰이 생성 된 클라이언트의 식별자를 포함하여 인증 세션에 대한 클레임 집합이 포함됩니다 ( aud).

Go에서는 플러그 가능 커넥터가있는 OIDC (OpenID Connect Identity) 및 coreos / dex를 볼 수 있습니다.

이 포스트의 답변 vonc

나는이 질문에 약간 다르게 대답 할 것이고, @Peter T가 모든 것에 대답했기 때문에 매우 정확하고 간략하게 될 것입니다.

이 표준에서 볼 수있는 주요 이점은 두 가지 원칙을 준수하는 것입니다.

1. 우려의 분리.
2. 일반적으로 비즈니스를 제공하는 웹 응용 프로그램에서 인증을 분리합니다.

그렇게함으로써

1. 단일 STS를 신뢰하는 여러 응용 프로그램이있는 경우 Single SignOn의 대안을 구현할 수 있습니다. 모든 응용 프로그램에 대해 하나의 사용자 이름을 의미합니다.
2. 웹 응용 프로그램 (클라이언트)이 사용자에게 속하고 웹 응용 프로그램 (클라이언트)에 속하지 않은 리소스에 액세스 할 수 있습니다.
3. 인증 프로세스를 신뢰할 수있는 타사에게 위임 할 수 있으며 사용자 진위 검증에 대해 걱정할 필요가 없습니다.