모바일 앱에 적합한 OAuth 2.0 흐름은 무엇입니까?

모바일 앱에 적합한 OAuth 2.0 흐름은 무엇입니까?

---

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/ 는

• 클라이언트가 리디렉션 URL에 대한 사용자 지정 URL 체계를 등록 할 수 있도록합니다.
• 데스크톱 앱을 지원하기 위해 임의의 포트 번호로 루프백 IP 리디렉션 URL을 지원합니다.
• 네이티브 앱이 비밀을 유지할 수 있다고 가정하지 마십시오. 모든 앱이 공개인지 기밀인지 선언하도록 요구하고 클라이언트 비밀은 기밀 앱에만 발급해야합니다.
• PKCE 확장을 지원하고 공용 클라이언트가이를 사용하도록 요구합니다.
• 권한 부여 인터페이스가 시스템 브라우저에서 시작되는 대신 기본 앱의 웹보기에 임베드되는시기를 감지하고 해당 요청을 거부하십시오.

웹보기 고려 사항

웹보기 (예 : 내장 된 사용자 에이전트)를 사용하는 많은 예제가 있지만이 접근 방식은 피해야하며 (특히 앱이 자사가 아닌 경우) 경우에 따라 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).

여기에서도 몇 가지 흥미로운 점이 제기됩니다. https://security.stackexchange.com/questions/179756/why-are-developers-using-embedded-user-agents-for-3rd-party-auth-what-are-the- ㅏ

---

불행히도이 질문에 대한 명확한 답이 없다고 생각합니다. 그러나 내가 확인한 옵션은 다음과 같습니다.

• If it is ok to ask the user for his/her credentials, then use the Resource Owner Password Credentials. However, this may not be possible for some reasons, namely

  • Usability or security policies forbid the insertion of the password directly at the app
  • The authentication process is delegated on an external Identity Provider and must be performed via an HTTP redirect-based flow (e.g. OpenID, SAMLP or WS-Federation)

• If usage of a browser based flow is required, then use the Authorization Code Flow. Here, the definition of the redirect_uri is a major challenge, for which there are the following options:

  • Use the technique described in https://developers.google.com/accounts/docs/OAuth2InstalledApp, where a special redirect_uri (e.g. urn:ietf:wg:oauth:2.0:oob) signals the authorization endpoint to show the authorization code instead of redirecting back to the client app. The user can manually copy this code or the app can try to obtain it from the HTML document title.
  • Use a localhost server at the device (the port management may not be easy).
  • Use a custom URI scheme (e.g. myapp://...) that when dereferenced triggers a registered "handler" (the details depend on the mobile platform).
  • If available, use a special "web view", such as the WebAuthenticationBroker on Windows 8, to control and access the HTTP redirect responses.

Hope this helps

Pedro

---

TL;DR: Use Authorization Code Grant with PKCE

1. Implicit Grant Type

The implicit grant type is quite popular with mobile apps. But it was not meant to be used like this. There are security concerns around the redirect. Justin Richer states:

The problem comes when you realize that unlike with a remote server URL, there is no reliable way to ensure that the binding between a given redirect URI and a specific mobile application is honored. Any app on the device can try to insert itself into the redirection process and cause it to serve the redirect URI. And guess what: if you’ve used the implicit flow in your native application, then you just handed the attacker your access token. There’s no recovery from that point — they’ve got the token and they can use it.

And together with the fact, that it does not let you refresh the access token, better avoid it.

2. Authorization Code Grant Type

The authorization code grant requires a client secret. But you should not store sensitive information in the source code of your mobile app. People can extract them. To not expose the client secret, you have to run a server as a middleman as Facebook writes:

We recommend that App Access Tokens should only be used directly from your app's servers in order to provide the best security. For native apps, we suggest that the app communicates with your own server and the server then makes the API requests to Facebook using the App Access Token.

Not an ideal solution but there is new, a better way to do OAuth on mobile devices: Proof Key for Code Exchange

3. Authorization Code Grant Type with PKCE (Proof Key for Code Exchange)

Out of the limitations, a new technique was created that let you use the Authorization Code without a client secret. You can read the full RFC 7636 or this short introduction.

PKCE (RFC 7636) is a technique to secure public clients that don't use a client secret.

It is primarily used by native and mobile apps, but the technique can be applied to any public client as well. It requires additional support by the authorization server, so it is only supported on certain providers.

from https://oauth.net/2/pkce/

---

Using a webview in your mobile application should be an affordable way to implement OAuth2.0 protocol on Android platform.

As for redirect_uri field, I think http://localhost is a good choice and you don't have to port a HTTP server inside your application, because you can override the implementation of onPageStarted function in the WebViewClient class and stop loading the web page from http://localhost after you check the url parameter.

public void onPageStarted(final WebView webView, final String url,
        final Bitmap favicon) {}

---

The smoothest user experience for authentication, and the easiest to implement is to embed a webview in your app. Process the responses received by the webview from the authentication point and detect error (user cancel) or approval (and extract token from url query parameters). And I think you can actually do that in all platforms. I have successfully made this work for the following: ios, android, mac, windows store 8.1 apps, windows phone 8.1 app. I did this for the following services: dropbox, google drive, onedrive, box, basecamp. For the non-windows platforms, I was using Xamarin which supposedly does not expose the entire platform specific APIs, yet it did expose enough for making this possible. So it is a pretty accessible solution, even from a cross platform perspective, and you don't have to worry about the ui of the authentication form.

참고URL : https://stackoverflow.com/questions/17427707/whats-the-right-oauth-2-0-flow-for-a-mobile-app