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

배경 : 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와 같은)의 일부 확장을 표준으로 체계화합니다.

---

답변