5
twitter API를 사용하는 동안 기본적으로 (요청 본문 + 요청 매개 변수 + nonces/timestamps + consumer_secret)의 해시 인 oauth_signature이 나타났습니다. consumer_secret은 요청을 보내는 응용 프로그램에만 알려져 있습니다. 트위터의 경우oauth_signature가 SSL 휠을 다시 발명하지 않습니까?
는 :
- 모든 통신은 SSL을 통해 발생한다.
- 트위터가 승인 된 각 애플리케이션에
consumer_secret을 발급합니다.oauth_signature의 기본 사용 (즉, 더 가슴이 (운송 조작 없음) : MITMs을 방지하기 때문에
,이 특정 유스 케이스가 상호 SSL을 통해 해결 될 수 있다는 것을 나에게 보인다
- Twitter는
consumer_secret을 발급하는 대신 각 애플리케이션에 대해 SSL 인증서를 발급 할 수 있습니다. 클라이언트 SSL - 인증서의이 아이디어는 1990 년대 인터넷 아케처럼 보일 수도 있지만
, 그것 때문에 크게 클라이언트 인증서에 대한 신뢰의 체인을 검증하는 문제의 실패했습니다. 트위터가 인증서의 유일한 발급자 및 검증 자일 것이므로이 문제는 여기에서 발생하지 않습니다. 단점은 트위터를 대신하여 초기 애플리케이션/클라이언트 SSL 인증서를 생성하는 데 훨씬 더 많은 노력이 필요하지만 클라이언트가 자신이 말하는 사람이라는 보장에 의존 할 수있는 REST API의 단순함에 따른 것입니다.
이 경우 트위터는 예제 일뿐입니다. AFAIK, 다른 oauth 구현 자의 대부분은 비슷한 전략을 사용하고 있으며, 여기에서 요점은 SSL을 이미 요구하는 대규모 OAuth 구현 자에게 적용된다는 점입니다.
무엇이 여기에 있습니까? 인터넷 관성?
질문이 누락되었습니다. 나는 상호 SSL-certs가 OAuth가 해결하는 문제를 해결할 것이라고 말하고있는 것이 아닙니다. 나는'oauth_signature' 메카니즘이 기본적으로 상호 SSL-certs가 제공하는 양방향 인증을 재발 명한다고 말하고 있습니다. – Manav
그러나 상호 SSL 인증서는 문제의 절반 (응용 프로그램 토큰면) 만 해결하고 소비자 토큰면에서는 아무 작업도 수행하지 않습니다. OAuth 2.0을 살펴보면 그 방향으로 움직였습니다. –