우리는 Android와 iOS에서 실행되는 두 가지 앱에 의해 소비되는 REST API를 개발했습니다. API는 공개되지 않았습니다. 우리는 사내에서 앱을 제작했습니다.OAuth - 각 소비자 플랫폼을위한 다른 소비자 키
각기 다른 소비자 키를 각기 다른 플랫폼에 제공하는 것이 맞습니까 (예 : 스마트 폰의 iOS, 태블릿의 iOS, 스마트 폰의 Android 용 ...)?
여러 개의 키가있는 이점 중 하나는 장치 세분화 분석을 쉽게 할 수 있다는 것입니다 (그러나 다른 방법으로도 가능함).
두 가지 전략 중 하나의 장점은 무엇입니까?
장점과 단점은 무엇입니까?
감사합니다.
OAuth와 관련하여 최종 사용자 장치 (iOS 및 Android 장치 포함)에서 실행되는 모든 응용 프로그램은 비밀 키가 응용 프로그램과 함께 배포되기 때문에 "공용"클라이언트라고합니다.
키가 안전하게 안전하게 유지 될 수있는 서버 측 웹 응용 프로그램과는 대조적입니다. 허용 된 개발자 및 운영 직원 만 액세스 할 수 있습니다. 장치에 배포되는 응용 프로그램의 경우 심지어 난독 화가 발생하더라도 권한이없는 당사자 (본질적으로 주머니에있는 앱을 가진 사람)에게 비밀이 노출되지 않도록 보장하여 키를 공개적으로 사용할 수있게합니다.
보안 관점에서 고유 클라이언트 ID와 비밀 정보를 API에 액세스하는 장치에 할당하는 것은별로 중요하지 않습니다. 악의있는 개발자는 공개 자격 증명을 사용하여 "승인 된"응용 프로그램으로 쉽게 사용할 수 있습니다.
참고로 클라이언트 ID를 사용하여 장치 세분화를 수행 할 수 있지만 잘못된 보안 의미를 전달하지 않는 User-Agent 헤더와 같은 다른 방법도 있습니다.
요약하면 플랫폼을 기반으로하는 앱에 고유 한 클라이언트 ID를 발행하는 것은 실제로 이점이 없습니다. 그러나 API에 대한 액세스 권한을 부여 할 때 공개 클라이언트가 보안 문제를 고려하는 방법을 고려하는 것이 중요합니다.
앱 개발자가 각 플랫폼마다 여러 개의 OAuth 고객 키를 사용하게하면 개발자는 만족스럽지 않을 것입니다! 개발자는 어떻게 든 이러한 키를 관리해야합니다. 앱 개발자가 키를 다시 발행해야하는 경우 어떻게해야합니까? 새로운 플랫폼에서 앱을 시작한다면? 이러한 개발자가 키를 유지 관리하는 데 얼마나 많은 노력이 필요합니까? 또한 새로운 모바일 OS, 이상한 장치, 비정상적인 사용 사례 등 사용자가 알지 못하는 플랫폼을 고려하십시오. 서비스 사용의 모든 변형을 제한하고 제어 하시겠습니까?
여전히 그렇게 할 수있는 이유 중 하나는 각 플랫폼에 대해 API 서비스를 별도로 판매 할 수 있다는 것입니다 (가격이 다를 수 있음).
안녕하세요. 귀하의 답변에 감사드립니다. 실제로 우리는 2 개의 모바일 앱을 내부적으로 구축하고 있습니다. 그건 내 질문에 분명하지 않았다. 나는 그것을 편집했다. 답변을 기반으로 답변을 조정해야한다고 생각하십니까? – dan
내가 할 수있는 것은 다음과 같은 client_ids를 할당하는 것입니다 :'your_app_name : ios'와'your_app_name : android'. 나는 앱에 비밀을 할당하지 않을 것입니다. 실제로 client_id는 분석하기가 쉬운 사용자 에이전트와 동일합니다. 예를 들어 사용자가 사용하고있는 장치 목록을 표시하고 잃어 버렸을 때 장치를 비활성화 할 수 있도록 응용 프로그램을 구분하는 데 사용할 수 있습니다. –
흥미로운 Jared.client_id는 OAuth 용어의 consumer_key일까요? – dan