처음부터 커뮤니티 플랫폼을 빌드하려고합니다. 우리는 먼저 WebServices를 만들고 공동체에는 일부 타사 구성 요소가있을 수 있으므로 견고한 WebServices를 갖는 것이 좋은 아이디어입니다.OAuth를 사용하여 GAE를 사용하여 REST WebService 빌드
서비스가 stateless이므로 모든 단일 호출에 대해 인증이 필요합니다. 우리가 유일한 소비자 일지라도이 작업을 수행하기 위해 서비스 제공 업체를 위해 OAuth 프로토콜을 구현하는 것이 좋은 생각입니까?
그런데 : 우리는 웹 사이트가 시작되기 전에 모바일 응용 프로그램을 제공 할 것입니다.
OAuth의 요점은 다른 웹 사이트 (소비자)가 귀하의 데이터 (귀하가 제공 업체)에 액세스 할 수있게하는 것입니다. 데이터를 유일한 소비자로 사용하기 때문에 개발 단계에서 OAuth를 구현할 필요가 없습니다.
빠른 속도로 빌드하고 사용자/테스터 앞에 놓습니다. 이 시점에서만 실제 버그를 발견하고 서비스에 대한 피드백을 얻을 수 있으므로 개선하고 올바른 방향으로 개발을 이끌 수 있습니다.
참고 : OAuth는 provided by App Engine (두 번째 단락)은 OpenID를 사용하는 경우에도 Google 계정 사용자 만 지원합니다.
저의 경험에 비추어 볼 때 인증 독립적 인 방법으로 REST WS를 만들었습니다. 저지 방법은 모든 것을 허용하고 요청을 검증하기 위해 몇 가지 필터가 있습니다. 웹 파트에 OpenId 인증, API에 OAuth 및 BASIC AUTHENTICATION (SSL 포함)을 사용했습니다.
아마 모든 것을 처음부터 만들 필요는 없지만 가능한 한 REST 끝점을 인증에서 제외하는 것이 좋습니다. API를 출시 할 때 큰 이점이 있습니다.
마지막 "철학적 인 것": OAuth는 완전히 비 상태가 아닙니다. 사실 사용자를 인증하는 임시 토큰을 가지고 있으며 브라우저의 세션과 유사합니다!
Thx Michele. 그 저지 일을 파헤쳐 볼 것 같아 .. – Dominik
좋습니다. 나중의 구현을 염두에두고 OAuth를 가능한 한 분리 할 것이다. – Dominik
틀린데, OAuth는 현재 데이터에 실제로 액세스하지 않고 인증하기 위해 (즉 당신이 누구인지) 널리 사용되고 있습니다. 예를 들어 OAuth2.0을 사용하여 인증하는 것이 좋습니다. 당신은 단지'id'와 아마'email' 외의 어떤 범위도 요구하지 않습니다. 그리고 Android 사용자를 올바르게 인증하는 유일한 방법입니다. –
@DzmitryLazerka : OAuth는 인증 표준이 아닌 인증 표준으로 정의되었습니다. 물론 실제 소비자는 OAuth 만 사용하여 인증하지만 OAuth가 설계된 것이 아닙니다. 또한 OAuth는 인증을 정의하지 않으므로 모든 OAuth 공급자는 자체 방식으로 인증을 구현하므로 통합이 어려워집니다. –