2011-12-11 2 views
4

클라이언트, Facebook/LinkedIn/Twitter API 사용 측면에서 OAuth 사용법을 설명하는 많은 리소스가 있습니다. 괜찮아. 하지만 OAuth 서버 구현에 관심이 있습니다. 목표는 모바일 장치 (원시 응용 프로그램)에서 액세스 할 수있는 웹 응용 프로그램을 보유하는 것이므로 백엔드 Java 서버에 OAuth를 설정해야합니다. 그래서 LinkedIn/Facebook/Twitter가 OAuth를 서버 측에서 어떻게 구현했는지 알고 싶습니다. 그리고 auth_token-s 사이에서 사용자를 구분하고 해당 액세스 (일부 종류의 데이터베이스 매핑 - auth_token = 사용자 ID?)를 부여합니다.OAuth 1.0 또는 2.0 서버 구현? 네이티브 모바일 애플리케이션 인증

아니면 모바일 사용자를 인증하는 더 좋은 방법이 있습니다 (백 엔드에 REST 스타일 서비스를 사용하려고합니다).

답변

5

Facebook, LinkedIn 및 Twitter는 OAuth 1 (Twitter LinkedIn) 및 draft for OAuth 2 (Facebook, LinkedIn) 사양에 따라 OAuth를 구현했습니다.

OAuth 1 또는 OAuth 2 사용자 에이전트 흐름을 제안합니다. 당신의 마음이 OAuth에 설정되어 있다면. 당신은 언제나 simple basic authentication으로 시작하여 정말로 어려운 부분, 즉 API 자체의 디자인에 집중할 수 있습니다.

마음이 OAuth로 설정된 경우 코드 라이브러리 목록 http://oauth.net/code/을 확인하십시오. 또한 사양을 읽고 OAuth 공급자를 구현하려면 사양을 알고 이해해야합니다. 그렇지 않으면 당신은 모든 것을 "OAuthy"로 해결할 수있는 out-of-the-box 라이브러리를 찾는 고통의 세계에 나서게됩니다.

+0

OAuth 사양에 익숙한 경우 토큰을 생성하는 방법과 사용자 토큰 (런타임 해시 맵, 데이터베이스 등)에 맵 토큰을 지정하는 방법을 지정했는지,이 부분이 누락되어 있는지 명확히 할 수 있습니까? 사양에서, 그리고 공급자 구현에 따라 다르므로 Twitter/Facebook/LinkedIn 각각에 자체 공급자 구현이 있습니까? 어쩌면 이러한 회사의 OAuth 아키텍처/구현에서 사용할 수있는 프레젠테이션/문서를 알고 있습니까? – akazlou

+0

토큰 및 비밀 생성은 명시되지 않았지만, 실제로 다음과 같은 진술을 가진 구현 자에게 달려있다. '조심스러운쪽에 잘못을 표시하고 합리적인 가장 긴 비밀을 사용하라'. 나는 정말로 무작위적이고 복잡한 소금과 함께 어려운 암호화 알고리즘을 사용한다. OAuth에 관해서는 1을 읽어보십시오 : https://dev.twitter.com/docs/auth/oauth. 그것은 클라이언트의 구현자가 무엇을해야하는지, 그리고 따라서 제공자가 준수하고 지원해야 할 것이 무엇인지를 설명합니다. 더 자세한 구현 기사를 찾지 못했습니다. 내 견해로는 사양을 이해하는 데 달려 있습니다. –

+1

또 다른 요점은 OAuth 1의 문제 도메인에서 소비자 (클라이언트)와 공급자 (서버)는 실제로 동일한 작업을 수행하며 동일한 비밀 정보를 사용하여 매개 변수에 서명하므로 서명 요청을위한 클라이언트 라이브러리를 사용하여 쉽게 서명 할 수 있습니다 서버 측에서 유효성 검사를 요청합니다. 차이점은 일단 완료되면 한 파트는 응답을 보내고 다른 파트는 응답을 수신한다는 것입니다. OAuth 2의 경우 어떤 흐름을 선택 하느냐에 따라 더 많은 차이가 있습니다. 사용자 에이전트 흐름이 가장 보편적 인 것으로 보입니다. 그러나 OAuth 2는 여전히 사양 초안이라는 점을 명심하십시오. –