모바일 플랫폼 용 OAuth2와 함께 사용자 에이전트 흐름을 사용할 때 인증 서버가 응용 프로그램의 client_id를 인증 할 수있는 방법이 없습니다. client_id에 대한 OAuth2 보안 고려 사항
이
은 OAuth2를 관리하지 않는 ...그래서, 사람이 CLIENT_ID를 복사하여 내 응용 프로그램을 가장 할 수 있습니다 (그래서 내 대신 모든 액세스 토큰을 얻을), 이것은, 페이스 북, 포 스퀘어에 적용 할 수있다? 또는 나는 무엇인가 놓쳤다?
웹 응용 프로그램 (웹 서버 흐름)의 경우 액세스 토큰이 서버쪽에 저장되고 클라이언트는 비밀 키를 사용하여 인증됩니다.
좋은 답변이 없습니다. 네이티브 앱 콜백은 일반적으로 맞춤 등록 된 URI 스키마를 통해 발생합니다 (예 : 콜백 리디렉션 URI는 myapp : // oauth? code = xyz123과 같습니다). 불행히도 모든 앱은 주어진 프로토콜 체계의 소유권을 주장하고 콜백을받을 수 있습니다.
이 문제는 "신뢰할 수있는 클라이언트"가있는 프로토콜을 잠그는 것과 매우 유사합니다. 메신저 네트워크가 제 3 자 클라이언트를 잠 그려면 전투를 생각해보십시오 (2000 년 초). 결국 클라이언트는 & 프로토콜 엔드 포인트가 배치 된 클라이언트를 타사 개발자가 리버스 엔지니어링 할 수 있기 때문에 포기합니다. 의 OAuth WG 메일 링리스트에이 주제에 대한 몇 가지 활성 논의도있다 :
주
웹 앱 전용 http://www.ietf.org/mail-archive/web/oauth/current/msg08177.html일반적으로 client_id는 사이트의 URL과 연결됩니다. OAuth 응답/리디렉션은 등록 된 URL로만 전송됩니다. 따라서 공격자는 자신의 사이트에서 요청 결과를 수신 할 수 없습니다 (귀하와 공격자 페이지가 같은 도메인에 있지 않는 한).
이 적용, 어떻게 장치에 대한? – davecon
링크 및 설명 주셔서 감사합니다. 현재의 초안에서 분명히 알 수 있습니다 : http://tools.ietf.org/html/draft-ietf-oauth-v2-22#section-1.3.2. 이것은 바뀔 것이기를 희망합니다. 그렇지 않으면 우리는 client_id의 악의적 인 사용을 (가능합니까?) 감지하기 위해 인증 서버를 신뢰할 수밖에 없습니다 .... – davecon
맞습니다. 실제로 Resource Server (RS - 대상 OAuth가 RESful API로 보호 됨)에서 비정상적인 트랜잭션에 사용되는 client_id 이상의 악의적 인 사용을 탐지하는 것은 매우 까다로운 작업입니다. –