OAuth 2.0의 클라이언트 비밀

Google 드라이브 API를 사용하려면 OAuth2.0을 사용하여 인증을해야합니다. 그리고 이것에 대해 몇 가지 질문이 있습니다.

1. 클라이언트 ID와 클라이언트 암호는 내 앱이 무엇인지 식별하는 데 사용됩니다. 그러나 클라이언트 애플리케이션 인 경우 하드 코딩되어야합니다. 따라서 모든 사람이 내 앱을 디 컴파일하고 소스 코드에서 추출 할 수 있습니다. 나쁜 앱이 좋은 앱의 클라이언트 ID와 시크릿을 사용하여 좋은 앱으로 가장 할 수 있다는 의미입니까? 따라서 사용자는 실제로 나쁜 앱에서 요청하더라도 좋은 앱에 대한 권한 부여를 요청하는 화면을 표시 할 것입니까? 그렇다면 어떻게해야합니까? 아니면 실제로 이것에 대해 걱정할 필요가 없습니까?

2. 모바일 애플리케이션에서 웹뷰를 앱에 임베드 할 수 있습니다. 그리고 권한을 요청하는 앱이 실제로는 "브라우저"이기 때문에 웹뷰에서 비밀번호 필드를 추출하기 쉽습니다. 그렇다면 모바일 애플리케이션의 OAuth는 클라이언트 애플리케이션이 서비스 공급자의 사용자 자격 증명에 액세스하지 못하는 이점이 없습니까?

나는 귀하의 질문에 대한 의견을 쓰기 시작했지만 말할 것이 너무 많다는 것을 알았으므로 여기에 답변의 주제에 대한 나의 견해가 있습니다.

1. 예, 이에 대한 실제 가능성이 있으며이를 기반으로 한 일부 익스플로잇이있었습니다. 제안은 앱에서 앱을 비밀로 유지하는 것이 아니라 배포 된 앱이이 토큰을 사용해서는 안된다는 사양의 일부도 있습니다. 이제 물어볼 수 있지만 XYZ가 작동하려면 필요합니다. 이 경우 사양을 제대로 구현하지 않고 A는 해당 서비스를 사용하지 않거나 (가능성이 낮음) B는 일부 난독 화 방법을 사용하여 토큰을 보호하여 서버를 프록시로 찾거나 사용하기 어렵게 만듭니다.

   예를 들어 Android 용 Facebook 라이브러리에서 로그에 토큰이 유출되는 버그가있었습니다. 여기에서 자세한 내용을 확인할 수 있습니다. http://attack-secure.com/all-your-facebook-access-tokens-are-belong -to-us 및 여기 https://www.youtube.com/watch?v=twyL7Uxe6sk . 제 3 자 라이브러리 사용에 대해 더욱 조심해야합니다 (실제로는 상식이지만 토큰 하이재킹이 큰 문제인 경우에는 신중함을 더 추가하십시오).

2. 나는 꽤 오랫동안 요점 2에 대해 외쳤다. 동의 페이지를 수정하기 위해 (예 : 앱에 맞게 확대 / 축소 및 디자인 변경) 내 앱에서 몇 가지 해결 방법을 수행했지만 사용자 이름과 암호를 사용하여 웹보기 내의 필드에서 값을 읽는 데 방해가되지는 않았습니다. 따라서 두 번째 요점에 전적으로 동의하며 OAuth 사양에서 큰 "버그"라고 생각합니다. 사양에서 "앱이 사용자 자격 증명에 액세스 할 수 없습니다"라는 점은 단지 꿈일 뿐이며 사용자에게 잘못된 보안 감각을 제공합니다. 또한 앱에서 Facebook, Twitter, Dropbox 또는 기타 자격 증명을 요청할 때 사람들이 일반적으로 의심하는 것 같습니다. 나는 많은 평범한 사람들이 OAuth 사양을 읽고 "Now I am safe"라고 말하지는 않지만 대신 상식을 사용하고 일반적으로 신뢰하지 않는 앱을 ​​사용하지 않습니다.

여기에있는 질문 1과 같은 질문을했고 최근에 직접 조사를했습니다. 결론은 "클라이언트 비밀"을 비밀로하지 않아도 괜찮다는 것입니다. 클라이언트 비밀의 기밀성을 유지하지 않는 클라이언트 유형은 OAuth2 사양에서 "공용 클라이언트"라고합니다. 악의적 인 누군가가 인증 코드를 얻고 토큰에 액세스 할 수있는 가능성은 다음과 같은 사실에 의해 방지됩니다.

1. 클라이언트는 서비스가 아닌 사용자로부터 직접 인증 코드를 받아야합니다.

사용자가 클라이언트를 신뢰하는 서비스를 표시하더라도 클라이언트는 클라이언트 ID와 클라이언트 시크릿을 표시하는 것만으로는 서비스에서 인증 코드를 얻을 수 없습니다. 대신 클라이언트는 사용자로부터 직접 인증 코드를 받아야합니다. (이것은 일반적으로 URL 리디렉션에 의해 수행되며 나중에 설명하겠습니다.) 따라서 악성 클라이언트의 경우 사용자가 신뢰하는 클라이언트 ID / 비밀을 아는 것만으로는 충분하지 않습니다. 클라이언트 ID / 비밀을 아는 것보다 더 어려워 야하는 인증 코드를 제공하기 위해 사용자를 어떻게 든 참여 시키거나 스푸핑해야합니다.

2. 리디렉션 URL은 클라이언트 ID / 비밀로 등록됩니다.

악성 클라이언트가 어떻게 든 사용자를 참여시키고 서비스 페이지에서 "Authorize this app"버튼을 클릭하도록 만들었다 고 가정 해 보겠습니다. 이렇게하면 인증 코드와 함께 서비스에서 사용자 브라우저로 URL 리디렉션 응답이 트리거됩니다. 그런 다음 인증 코드가 사용자의 브라우저에서 리디렉션 URL로 전송되고 클라이언트는 인증 코드를 수신하기 위해 리디렉션 URL을 수신해야합니다. (리디렉션 URL도 localhost가 될 수 있으며 이것이 "공용 클라이언트"가 인증 코드를받는 일반적인 방법이라고 생각했습니다.)이 리디렉션 URL은 클라이언트 ID / 비밀로 서비스에 등록되므로 악성 클라이언트는 그렇지 않습니다. 인증 코드가 제공되는 위치를 제어하는 ​​방법이 있습니다.

두 번째 질문에 대한 답변 : 보안상의 이유로 Google API는 인증 / 로그인을 앱 자체 내에서 수행 할 수 없으며 (예 : 웹뷰가 허용되지 않음) 더 나은 보안을 위해 브라우저를 사용하여 앱 외부에서 수행해야합니다. 아래에 자세히 설명되어 있습니다. https : //developers.googleblog.com/2016/08/modernizing-oauth-interactions-in-native-apps.html