공개 소스 데스크탑 Twitter 클라이언트에 대한 OAuth v1 소비자 키와 비밀을 사용자에게 공개하지 않고 어떻게 저장합니까?

두꺼운 클라이언트, 데스크탑, 오픈 소스 트위터 클라이언트를 만들고 싶습니다. .NET을 내 언어로 사용하고 Twitterizer 를 OAuth / Twitter 래퍼로 사용하고 있으며 내 앱이 오픈 소스로 출시 될 수 있습니다.

OAuth 토큰을 얻으려면 다음 네 가지 정보가 필요합니다.

1. 액세스 토큰 (트위터 사용자 이름)
2. 접속 비밀 (트위터 비밀번호)
3. 소비자 키
4. 소비자 비밀

두 번째 정보는 PGP 개인 키와 같이 공유되지 않습니다. 그러나 OAuth 인증 흐름이 설계된 방식으로 인해 기본 앱에 있어야합니다. 애플리케이션이 오픈 소스가 아니고 컨슈머 키 / 비밀번호가 암호화 된 경우에도, 합리적으로 숙련 된 사용자는 컨슈머 키 / 시크릿 쌍에 액세스 할 수 있습니다.

내 질문은 어떻게이 문제를 해결할 수 있습니까? 데스크탑 트위터 클라이언트가 소비자 키와 비밀을 보호하기위한 적절한 전략은 무엇입니까?

나는 hueniverse 에 내려가는 것을 고려하고있는 길을 반영하는 답을 찾았 습니다 . OAuth Web Redirection Flow 너머 기사 는 몇 가지 제안을 제공하며 그중 하나는 토큰 교환 프로세스를 프록시하는 웹 URL입니다. 내 앱이이 프록시 페이지에 대한 인증을 요청하는 것임을 올바르게 인증하는 방법을 찾아야합니다. 그러나 가능합니다.

틀릴 수도 있지만 데스크톱 또는 모바일 앱과 키를 번들로 제공하거나 오픈 소스를 사용하거나 사용하지 않으면 액세스 할 수 있습니다. Twitter 및 Tumblr와 같은 서비스에서 OAuth 전용 API를 사용하도록 강제하는 경우 다음 두 가지 옵션이 있습니다.

• 모든 앱에 대한 인증 프록시 서비스 설정
• 앱과 함께 번들 키

전자는 더 어렵고 비용이 많이 들며 소규모 및 오픈 소스 앱에서 유지 관리 할 필요는 없습니다. 후자는 스패머가 키를 훔치면 앱이 차단되거나 차단 될 수 있음을 의미합니다. 트위터와 텀블러는 아직 더 나은 옵션을 제공하지 않고 모든 데스크톱 클라이언트, 오픈 소스 클라이언트를 포함하여 "빅 피쉬"키 를 배포 하고 대체로 사용하라는 제안이 있습니다.

마지막으로 모든 사용자가 API 키를 가져 오도록 하는 옵션이 있습니다.

OAuth 1을 정의하는 RFC 5849의 섹션 4.6 에는 소비자의 비밀이 실제로 트위터의 사용에도 불구하고 데스크탑 소비자가 사용하도록 의도되지 않았다고 명시되어 있습니다. Nelson Elhage가 " Dear Twitter " 에서 지적했듯이 , 클라이언트가 실패하기에 너무 크지 않은 경우 Twitter는 데스크톱 클라이언트의 소비자 키를 종료 할 수 있습니다. 그러나 데스크톱 또는 모바일 응용 프로그램에서 OAuth 1을 사용할 수 있도록하는 두 가지 해결 방법이 있습니다.

한 가지 방법은 운영하는 서버를 통해 전체 Twitter 프로토콜을 프록시하는 것입니다. 이런 식으로 소비자 비밀은 서버에 유지됩니다. 이것은 OAuth 1 사양의 편집자 인 Dick Hardt가 권장 하는 해결 방법 입니다. 이 해결 방법은이 서버 운영 비용을 해결하지 않습니다.

Raffi Krikorian 이 Twitter 개발 토크 Google 그룹에 게시 한 글 과 Chris Steipp 가 Wikipedia 메일 링리스트에 올린 글 에서 제안한 다른 방법 은 "각 사용자가 자신의 데스크탑 애플리케이션 사본을 자체 소비자로 등록하도록하는 것"입니다. 그런 다음 사용자는 새로 등록 된 소비자 키와 소비자 암호를 복사하여 응용 프로그램에 붙여 넣습니다. 응용 프로그램 설명서에는 Twitter 개발자 사이트에 새 응용 프로그램을 등록하는 방법에 대한 자세한 지침이 포함되어 있어야합니다. 이 공식적인 한계에는 몇 가지 실질적인 문제가 있습니다.

• 귀사의 고객은 잘 알려진 독점 고객에 비해 사용상의 단점이 있습니다.
• 새로운 응용 프로그램을 작성하는 양식은 필수 필드를 미리 채울 수있는 방법을 제공하기 위해 표시되지 않습니다. 즉, Twitter가 앱 등록 절차를 변경할 때마다 설명서의 등록 과정을 업데이트해야합니다.
• 개발자 계약에 따라 구속력있는 계약을 체결하려면 사용자가 법적 연령이어야합니다. 즉, 13 세에서 17 세 사이의 응용 프로그램 사용자는 부모가 사용자를 대신하여 계약에 동의해야합니다.
• Twitter의 개발자 정책 은 대량 등록 응용 프로그램 및 "이름 쪼그리고 앉기"를 금지합니다. "이름 쪼그리고 앉기"는 "다른 이름으로 같은 기능을 가진 여러 응용 프로그램을 제출하는"것으로 정의됩니다. Twitter가 하나의 응용 프로그램의 별도 사본을 "이름 스쿼터"로 등록한 관련없는 사용자를 처리했는지 여부에 대해서는 선례가 없습니다.

나는 대답 할 것이지만 나는 이것을 스스로 다루지 않았다는 경고를 받는다. 나는 모범 사례와 기존의 관련 경험을 떠난다.

나는 그것에 대해 너무 걱정하지 않을 것입니다. 클라이언트가 오픈 소스라면 어쨌든 소스에 액세스 할 수 있으며 프로그램으로 수행하는 작업을 제어하려고 시도하면 오픈 소스의 특성에 위배됩니다 (중요하지만 중요한 것은 하지 않습니다 ).

누군가가 프로그램을 디버깅하고 키를 추출하는 데 충분한 지식을 가지고 있다면 그보다 더 많은 작업을 수행하는 방법을 알고 아마도 더 많은 시간을 낭비하려고 할 것입니다.

예방책으로 키를 너무 자주 (가능한 경우) 변경하지만, 가능한 모든 키를 사용하는 것이 나에게 너무 심각하게 들리지 않는 것보다 귀하의 프로그램 인 것처럼 가장합니다.

전체 공개, 나는 Twitters API, twitterizer의 API, oauth 요구 사항 또는 의심스러운 것처럼 들리는 말에 익숙하지 않습니다.)

컨슈머 키와 시크릿은 애플리케이션에 바인딩되어 있으며 사용자에 바인딩되지 않습니다. 이를 통해 OAuth 제공자는 처리중인 애플리케이션을 알고 있습니다. 나머지 단계, 액세스 토큰 및 비밀은 첫 번째 단계가 완료된 후에 얻습니다.

프로토콜 작동 방식을 보여주는 자세한 내용 은 이 블로그 게시물 을 참조하십시오.