OAuth 2.0을 사용하여 모바일 앱용 웹 API에서 위임 된 권한 부여를 구현하려고합니다. 사양에 따르면 암시 적 권한 부여 흐름은 새로 고침 토큰을 지원하지 않습니다. 즉, 특정 기간 동안 액세스 토큰이 부여되면 사용자는 토큰이 만료되거나 취소되면 앱에 다시 권한을 부여해야합니다.
사양에 언급 된대로 브라우저에서 실행되는 일부 자바 스크립트 코드에 대한 좋은 시나리오라고 생각합니다. 사용자가 토큰을 얻기 위해 앱에 권한을 부여해야하는 시간을 최소화하려고하므로 새로 고침 토큰을 지원하는 인증 코드 흐름이 좋은 옵션 인 것처럼 보입니다.
그러나이 흐름은 리디렉션을 수행하기 위해 웹 브라우저에 크게 의존하는 것 같습니다. 임베디드 웹 브라우저를 사용하는 경우이 흐름이 여전히 모바일 앱에 적합한 옵션인지 궁금합니다. 아니면 암시 적 흐름을 따라야합니까?
답변:
설명 : 모바일 앱 = 네이티브 앱
다른 의견과 온라인의 몇 가지 소스에서 언급했듯이 암시 적은 모바일 앱에 자연스럽게 적합 해 보이지만 최상의 솔루션이 항상 명확한 것은 아닙니다 (실제로 아래에서 설명하는 이유로 암시 적 사용을 권장하지 않음).
네이티브 앱 OAuth2 모범 사례
어떤 접근 방식을 선택하든 (고려해야 할 몇 가지 절충안이 있음) OAuth2를 사용하는 네이티브 앱에 대해 여기에 설명 된 모범 사례 ( https://tools.ietf.org/html/rfc8252)에 주의를 기울여야합니다.
다음 옵션을 고려하십시오.
절대적인
암시 적을 사용해야합니까?
섹션 8.2에서 인용하려면 https://tools.ietf.org/html/rfc8252#section-8.2
OAuth 2.0 암시 적 권한 부여 흐름 (OAuth 2.0 [RFC6749]의 섹션 4.2에 정의 됨)은 일반적으로 브라우저에서 권한 부여 요청을 수행하고 URI 기반 앱 간 통신을 통해 권한 부여 응답을받는 방식으로 작동합니다.
그러나 암시 적 흐름은 PKCE [RFC7636] (섹션 8.1에서 필요)에 의해 보호 될 수 없으므로 네이티브 앱과 함께 암시 적 흐름을 사용하는 것은 권장되지 않습니다 .암시 적 흐름을 통해 부여 된 액세스 토큰도 사용자 상호 작용 없이는 새로 고칠 수 없으므로 새로 고침 토큰을 발급 할 수있는 권한 부여 코드 부여 흐름이 액세스 토큰 새로 고침이 필요한 기본 앱 인증에 대한보다 실용적인 옵션이됩니다.
인증 코드
인증 코드를 사용하는 경우 한 가지 접근 방식은 자신의 웹 서버 구성 요소를 통해 프록시하는 것입니다.이 방법은 토큰 요청을 클라이언트 암호로 강화하여 장치의 분산 앱에 저장하지 않도록하는 것입니다.
아래 발췌 : https://dev.fitbit.com/docs/oauth2/
인증 코드 부여 흐름은 웹 서비스가있는 애플리케이션에 권장됩니다. 이 흐름에는 응용 프로그램의 클라이언트 암호를 사용하는 서버 간 통신이 필요합니다.
참고 : 앱 스토어 또는 클라이언트 측 JavaScript를 통해 다운로드 한 앱과 같은 분산 코드에 클라이언트 암호를 넣지 마십시오.
웹 서비스가없는 애플리케이션은 암시 적 허가 흐름을 사용해야합니다.
결론
최종 결정은 원하는 사용자 경험뿐만 아니라 최종 접근 방식에 대한 적절한 위험 평가를 수행하고 그 의미를 더 잘 이해 한 후 위험에 대한 욕구도 고려해야합니다.
훌륭한 읽기는 여기 https://auth0.com/blog/oauth-2-best-practices-for-native-apps/입니다.
또 다른 하나는 https://www.oauth.com/oauth2-servers/oauth-native-apps/ 입니다.
현재 업계 모범 사례는 권한 부여 흐름을 사용하고 클라이언트 암호를 생략하고 외부 사용자 에이전트를 사용하여 흐름을 완료하는 것입니다. 외부 사용자 에이전트는 일반적으로 기기의 기본 브라우저 (기본 앱과 별도의 보안 도메인 포함)이므로 앱이 쿠키 저장소에 액세스하거나 브라우저 내부의 페이지 콘텐츠를 검사 또는 수정할 수 없습니다.
PKCE 고려 사항
여기에 설명 된 PKCE도 고려해야합니다. https://www.oauth.com/oauth2-servers/pkce/
특히 Authorization Server도 구현하는 경우 https://www.oauth.com/oauth2-servers/oauth-native-apps/checklist-server-support-native-apps/ 는
웹보기 고려 사항
웹 뷰를 사용하는 많은 예가 있습니다. 즉, 내장 된 사용자 에이전트가 있지만이 접근 방식은 피해야하며 (특히 앱이 자사가 아닌 경우) 일부 경우 API를 발췌로 사용하는 것이 금지 될 수 있습니다. 여기 에서 아래는 보여줍니다
OAuth 2.0 인증 페이지를 삽입하려고하면 애플리케이션이 Fitbit API에서 금지됩니다.
보안을 위해 OAuth 2.0 인증 페이지는 전용 브라우저보기에 표시되어야합니다. Fitbit 사용자는 URL 표시 줄 및 TLS (전송 계층 보안) 인증서 정보와 같은 브라우저에서 제공하는 도구가있는 경우에만 정품 Fitbit.com 사이트에서 인증하고 있음을 확인할 수 있습니다.
기본 애플리케이션의 경우 이는 인증 페이지가 기본 브라우저에서 열어야 함을 의미합니다. 네이티브 애플리케이션은 사용자 지정 URL 체계를 리디렉션 URI로 사용하여 사용자를 브라우저에서 권한을 요청하는 애플리케이션으로 다시 리디렉션 할 수 있습니다.
iOS 애플리케이션은 앱을 Safari로 전환하는 대신 SFSafariViewController 클래스를 사용할 수 있습니다. WKWebView 또는 UIWebView 클래스의 사용은 금지됩니다.
Android 애플리케이션은 앱을 기본 브라우저로 전환하는 대신 Chrome 맞춤 탭을 사용할 수 있습니다. WebView 사용은 금지되어 있습니다.
더 명확히하기 위해 위에 제공된 모범 사례 링크의 이전 초안 중이 섹션 에서 인용 한 내용 이 있습니다.
일반적으로 웹보기로 구현되는 임베디드 사용자 에이전트는 기본 앱을 인증하는 대체 방법입니다. 그러나 정의상 제 3자가 사용하기에 안전하지 않습니다. 여기에는 전체 로그인 자격 증명으로 로그인하는 사용자가 포함되며 덜 강력한 OAuth 자격 증명으로 축소됩니다.
신뢰할 수있는 자사 앱에서 사용하는 경우에도 내장 된 사용자 에이전트는 필요한 것보다 더 강력한 자격 증명을 획득하여 최소 권한 원칙을 위반하여 잠재적으로 공격 표면을 증가시킵니다.
내장 된 사용자 에이전트의 일반적인 웹보기 기반 구현에서 호스트 응용 프로그램은 다음을 수행 할 수 있습니다. 사용자 이름과 암호를 캡처하기 위해 양식에 입력 된 모든 키 입력을 기록합니다. 자동으로 양식을 제출하고 사용자 동의를 우회합니다. 세션 쿠키를 복사하고이를 사용하여 사용자로 인증 된 작업을 수행합니다.
사용자가 브라우저에있는 일반적인 주소 표시 줄 및 기타 ID 기능없이 내장 된 웹보기에 자격 증명을 입력하도록 장려하면 사용자가 합법적 인 사이트에 로그인하고 있는지 여부를 알 수 없으며, 로그인하는 경우에도 교육을받습니다. 사이트를 먼저 확인하지 않고 자격 증명을 입력해도됩니다.
보안 문제 외에도 웹보기는 인증 상태를 다른 앱이나 시스템 브라우저와 공유하지 않으므로 사용자가 모든 인증 요청에 로그인해야하고 사용자 경험이 저하됩니다.
위의 이유로 신뢰할 수있는 자사 앱이 다른 앱에 대한 외부 사용자 에이전트 역할을하거나 여러 자사 앱에 대한 단일 사인온을 제공하는 경우를 제외하고는 내장 된 사용자 에이전트를 사용하지 않는 것이 좋습니다.
인증 서버는 가능한 경우 자체가 아닌 내장 된 사용자 에이전트를 통해 로그인을 감지하고 차단하는 조치를 취하는 것을 고려해야합니다 (SHOULD).
여기에서도 몇 가지 흥미로운 점이 제기됩니다. /security/179756/why-are-developers-using-embedded-user-agents-for-3rd-party-auth-what-are-the- ㅏ
불행히도이 질문에 대한 명확한 답은 없다고 생각합니다. 그러나 내가 확인한 옵션은 다음과 같습니다.
사용자에게 자격 증명을 요청해도 괜찮다면 Resource Owner Password Credentials 를 사용하십시오 . 그러나 이것은 어떤 이유로 인해 가능하지 않을 수 있습니다.
브라우저 기반 흐름을 사용해야하는 경우 인증 코드 흐름 을 사용합니다 . 여기서의 정의 redirect_uri는 다음과 같은 옵션이있는 주요 과제입니다.
redirect_uri(예 :urn:ietf:wg:oauth:2.0:oob :)는 클라이언트 앱으로 다시 리디렉션하는 대신 인증 코드를 표시하도록 인증 엔드 포인트에 신호를 보냅니다. 사용자가이 코드를 수동으로 복사하거나 앱이 HTML 문서 제목에서 코드를 가져올 수 있습니다.localhost장치에서 서버를 (포트 관리가 쉽지 않을 수 있음).myapp://...역 참조시 등록 된 "핸들러"를 트리거 하는 사용자 지정 URI 체계 (예 :)를 사용합니다 (세부 사항은 모바일 플랫폼에 따라 다름).도움이 되었기를 바랍니다
페드로
1. 암시 적 부여 유형
암시 적 부여 유형은 모바일 앱에서 매우 인기가 있습니다. 하지만 이렇게 사용되는 것은 아닙니다. 리디렉션과 관련된 보안 문제가 있습니다. Justin Richer는 다음과 같이 말합니다 .
문제는 원격 서버 URL과 달리 지정된 리디렉션 URI와 특정 모바일 애플리케이션 간의 바인딩이 적용되는지 확인할 수있는 신뢰할 수있는 방법이 없다는 것을 인식 할 때 발생합니다. 기기의 모든 앱은 리디렉션 프로세스에 자신을 삽입하고 리디렉션 URI를 제공하도록 할 수 있습니다. 그리고 무엇을 추측하십시오. 네이티브 애플리케이션에서 암시 적 흐름을 사용한 경우 공격자에게 액세스 토큰을 건네주었습니다. 그 시점에서 복구 할 수 없습니다. 그들은 토큰을 가지고 있고 그것을 사용할 수 있습니다.
그리고 사실과 함께 액세스 토큰을 새로 고칠 수 없다는 사실을 피하는 것이 좋습니다.
2. 인증 코드 부여 유형
인증 코드 부여에는 클라이언트 암호가 필요합니다. 그러나 모바일 앱의 소스 코드에 민감한 정보를 저장해서는 안됩니다. 사람들은 그것들을 추출 할 수 있습니다. 클라이언트 시크릿을 노출하지 않으려면 Facebook이 다음 과 같이 작성 하는 것처럼 중개자로 서버를 실행해야합니다 .
최상의 보안을 제공하기 위해 앱 액세스 토큰은 앱 서버에서 직접 사용하는 것이 좋습니다. 네이티브 앱의 경우 앱이 자체 서버와 통신 한 다음 서버가 앱 액세스 토큰을 사용하여 Facebook에 API 요청을하는 것이 좋습니다.
이상적인 솔루션은 아니지만 모바일 장치에서 OAuth를 수행하는 새롭고 더 나은 방법이 있습니다. 코드 교환을위한 증명 키
3. PKCE를 통한 인증 코드 부여 유형 (코드 교환을위한 증명 키)
한계에서 벗어나 클라이언트 암호없이 인증 코드를 사용할 수있는 새로운 기술이 만들어졌습니다. 전체 RFC 7636 또는 이 짧은 소개를 읽을 수 있습니다 .
PKCE (RFC 7636)는 클라이언트 암호를 사용하지 않는 공용 클라이언트를 보호하는 기술입니다.
기본 및 모바일 앱에서 주로 사용되지만 모든 공용 클라이언트에도 적용 할 수 있습니다. 권한 부여 서버의 추가 지원이 필요하므로 특정 공급자에서만 지원됩니다.
모바일 애플리케이션에서 웹뷰를 사용하는 것은 Android 플랫폼에서 OAuth2.0 프로토콜을 구현하는 저렴한 방법이어야합니다.
redirect_uri 필드의 경우, http://localhost좋은 선택 이라고 생각 하며 , 매개 변수 를 확인한 후 클래스 onPageStarted에서 함수 구현을 재정의 WebViewClient하고 웹 페이지로드를 중지 할 수 있으므로 애플리케이션 내부에 HTTP 서버를 포팅 할 필요가 없습니다 .http://localhosturl
public void onPageStarted(final WebView webView, final String url,
final Bitmap favicon) {}
가장 원활한 인증 사용자 경험이자 가장 쉽게 구현할 수있는 방법은 앱에 웹뷰를 포함하는 것입니다. 인증 포인트에서 웹뷰가 수신 한 응답을 처리하고 오류 (사용자 취소) 또는 승인을 감지합니다 (URL 쿼리 매개 변수에서 토큰 추출). 실제로 모든 플랫폼에서 그렇게 할 수 있다고 생각합니다. ios, android, mac, windows store 8.1 앱, windows phone 8.1 앱에 대해 성공적으로이 작업을 수행했습니다. 나는 dropbox, google drive, onedrive, box, basecamp와 같은 서비스를 위해 이것을했습니다. Windows가 아닌 플랫폼의 경우 전체 플랫폼 특정 API를 노출하지 않는 Xamarin을 사용했지만이를 가능하게하는 데 충분했습니다. 따라서 크로스 플랫폼 관점에서도 매우 액세스 할 수있는 솔루션입니다.