<div id="readability-page-1" class="page"><cite>Kaden Sungbin Cho</cite>
 2023. 9. 3. 01:31
 <div>
 아래는 개인적인 공부를 목적으로 RFC-8252인 OAuth 2.0 for Native Apps를 번역한 내용입니다. 이상한 부분 피드백 주시면, 감사히 수정하겠습니다 :)


<h2 data-ke-size="size26">네이티브앱을 위한 OAuth 2.0</h2>
Abstract
네이티브앱으로부터의 OAuth 2.0 인가 요청은 반드시 주로 유저의 브라우저인 외부유저에이전트를 통해 이뤄져야 합니다. 이 스펙은 왜 그러한지에 대해 보안적, 사용성적인 이유를 다루고, 네이티브앱과 인가 서버가 이 베스트프랙티스를 어떻게 구현할 수 있는지를 설명합니다.&nbsp;


<h3 data-ke-size="size23">1. Introduction</h3>
OAuth 2.0 인가 프레임워크를&nbsp;설명하는 RFC6749에선,&nbsp;인가 엔드포인트와 연동되는 native apps를 위해 2가지 방법을 제시합니다: 임베디트 유저에이전트(embedded user-agent)와 외부유저에이전트(external user-agent).

이 현 시점의 베스트프랙티스는 위 목적을 위해 브라우저와 같은 external user agent만을 사용할 것을 권장하고 상세 구현에 대한 내용을 소개합니다.&nbsp;

<h3 data-ke-size="size23">2. 컨벤션</h3>
(생략)

<h3 data-ke-size="size23">3. 용어</h3>
네이티브앱 (native app): 유저에 의해 기기에 설치된 앱 또는 애플리케이션으로, 브라우저 컨택스트에서만 실행되는 웹앱과 구분됨. 웹 기반의 기술을 통해 구현되었으나 네이티브앱을 통해 배포된 것, 소위 "하이브리드 앱"(예로, React Native 등)은 이 스펙에서는 네이티브앱과 동일한 것으로 간주함.
앱 (app): 네이티브앱을 지칭함.
앱스토어 (app store): 유저가 앱을 구매하고 다운로드할 수 있는 스토어.
외부유저에이전트 (external user agent): 인가 요청을 처리할 수 있는 유저 에이전트로 네이티브앱에 대해 구분된 entity이거나 security 도메인. 그렇기에 앱은 외부유저에이전트의&nbsp;쿠키 스토어나 페이지 컨텐츠를 살펴보거나 변경하거나 접근할&nbsp;수 없음.&nbsp;
임베디드유저에이전트 (embedded user agent): 네이티브앱에 의해 호스트된 유저 에이전트로 앱의 일부를 구성하거나 같은 security 도메인을 공유하는 인가 요청을 생성함. 그렇기에 쿠키 스토어나 페이지 컨텐츠 접근 및 변경이 가능함.&nbsp;
브라우저 (browser): http, https scheme을 핸들링하기 위해 운영체제에 의해 런칭되는 디폴트 애플리케이션.
인앱 브라우저 탭 (in-app browser tab): 호스트 앱 안에서 보여지는 브라우저로 브라우저의 일반적인 인증 상태 및 보안 특성을 가짐.&nbsp;
웹뷰 (webview): 앱에 embedded된 웹 브라우저 UI 컴포넌트로 앱의 컨트롤 하에 웹 페이지를 렌더링함.
claimed "https" scheme URI: 몇몇 플랫폼은 앱이 도메인 이름에 대한 소유권을 증명하면 특정 "https" scheme URI를 클레임할 수 있도록 함. Claimed된 URIs는 브라우저가 아니라 앱으로 열리게 됨.&nbsp;
private-use URI scheme: 앱에 의해 정의되고 운영체제에 등록된 URI scheme. 그러한 scheme에 대한 URI 요청은 요청을 처리하기 위해 등록된 앱을 런칭하게 됨.&nbsp;
reverse domain name notation: 도메인 이름 시스템에 기반한 네이밍 컨벤션으로, 도메인 컴포넌트가 reverse함. "app.example.com" → "com.example.app"

<h3 data-ke-size="size23">4. Overview</h3>
네이티브앱에서 유저에 대한 인가를 진행하기 위해서, 현재의 베스트프랙티스는 OAuth 인가 요청을 임베디드유저에이전트(웹뷰와 같은 것으로 구현된 것들)가 아닌 외부유저에이전트(주로 브라우저)에서 행하게 됩니다.&nbsp;

이전에는, 네이티브앱에서 OAuth 인가를 위해 임베디드유저에이전트를 사용하는 것이 흔하였습니다. 이러한 방식은 호스트 앱이 유저의 비밀정보나 쿠키에 접근할 수 있다는 취약점, 매 앱마다 로그인을 다시 해야한다는 점 등의 단점이 존재했습니다.&nbsp;

브라우저를 사용하는 네이티브앱 인가 플로우는, 이미 OAuth 인가 요청과 응답이 URI를 통해 이뤄지기에 OAuth 프로토콜 변경 없이도 가능합니다. 이것은 앱 간의 커뮤니케이션에 사용될 수 있는 URI들을 포함합니다. 이 스펙을 따르기 위해서는 모든 클라이언트가 confidential 한 것으로 가정하는 몇몇의 OAuth 서버 구현은 퍼블릭 네이티브앱 클라이언트에 대한 부분을 추가해야하며, 그러한 클라이언트가 사용하는 redirect URI들을 지원해야 합니다.&nbsp;


<h4 data-ke-size="size20">브라우저를 사용한 네이트브앱에서의 인가 플로우</h4>
<figure data-ke-mobilestyle="widthOrigin" data-origin-width="1222" data-origin-height="796">
 
 <img src="https://blog.kakaocdn.net/dn/dNm9n0/btssVMMNCiH/JEtQmQYGKwZYHsUjkCDW20/img.png" onerror="this.onerror=null; this.src='//t1.daumcdn.net/tistory_admin/static/images/no-image-v1.png'; this.srcset='//t1.daumcdn.net/tistory_admin/static/images/no-image-v1.png';" width="524" height="341" data-origin-width="1222" data-origin-height="796">
 
 <figcaption>Image from (1)</figcaption>
</figure>
위 표1은 유저에 대한 인가를 진행하기 위한 네이티브앱과 브라우저간 흐름을 나타내고 있습니다.

(1) 클라이언트 앱이 인가 요청과 같이 브라우저 탭을 열게됨.
(2) 인가 엔드포인트는 인가 요청을 받고, 유저를 인증하고, 인가를 획득함. 유저를 인증하는 부분은 다른 인증 시스템 연계를 포함할 수 있음.
(3) 인가 서버는 인가 코드(authorization code)를 발행하여 redirect URI를 통해 돌려줌.
(4) 클라이언트는 인가 코드를 redirect URI를 통해 받음.
(5) 클라이언트 앱은 토큰 엔드포인트에 인가 코드를 제출함.
(6) 토큰 엔드포인트는 인가 코드를 검증하고 요청된 토큰을 발행함.&nbsp;


<h3 data-ke-size="size23">5. OAuth를 위한 앱 간 URI 커뮤니케이션</h3>
URI가 웹상에서 OAuth 2.0 (RFC6749)에 사용되듯이, 네이티브앱에서 인가 요청을 시작하고, 응답을 받기 위해 URI를 사용할 수 있습니다.
OAuth 2.0 web과 동일한 방식을 채택하여 네이티브앱의 OAuth 역시 SSO 세션이나 보안과 같은 이점을 누릴 수 있습니다. 동일한 방식을 취하는 것은 구현 복잡도를 낮출 뿐만 아니라 특정 플랫폼을 위해 구현되지 않은 스탠다드 기반의 웹 플로우에 의존하면서 상호운용성을 높일 수 있습니다.
이&nbsp;베스트프랙티스를&nbsp;따르기 위해서, 네이티브앱은 OAuth 인가 요청을 수행하기 위해 반드시&nbsp;외부유저에이전트를 사용하여야 합니다. 외부에이전트의 사용은 인가요청을 브라우저에서 열고, 네이티브앱으로 돌아가기 위해 인가 응답을 돌려주는 redirect URI를 통해 가능합니다.


<h3 data-ke-size="size23">6. 네이티브앱에서의 인가요청을 시작하기</h3>
유저 인가가 필요한 네이티브앱은 RFC6749의 Section 4.1의 인가 코드 grant type을 넣어 인가 요청 URI를 생성하고, 네이티브앱이 받을 수 있는 redirect URI를 사용하게 됩니다.&nbsp;

네이티브앱의 인가요청을 위한 redirect URI의 기능은 웹 기반의 인가 요청에 있는 것과 비슷합니다. 인가 응답을 OAuth 클라이언트의 서버로 보내는 것 대신에, 네이티브앱이 사용하는 redirect URI은 응답을 앱으로 돌려보내줍니다. 다양한 플랫폼에 네이티브앱에 redirect URI를 통해 인가요청 응답을 돌려주는 방식은 섹션 7에 정리되어 있습니다.&nbsp;

퍼블릭 네이티브앱 클라이언트는 반드시 PKCE(Proof Key for Code Exchange)를 구현하여야 하며, 인가 서버도 그러한 클라이언트에 대해 반드시 PKCE를 지원하여야 합니다. 그 이유는 섹션 8.1에 기술되어 있습니다.

인가요청 URI를 생성한 이후에, 앱은 플랫폼-특정한 API를 사용해 URI를 외부유저에이전트에서 엽니다. 주로, 사용되는 외부유저에이전트는 디폴트 브라우저입니다. 그러나, 다른 형태의 외부유저에이전트를 사용할(MAY) 수도 있습니다.

이 베스트프랙티스는 네이티브앱을 위한 외부유저에이전트 중 브라우저를 추천하는(RECOMMENDED) 관점으로 기술합니다. 유저 인가를 위해 제작된 외부유저에이전트나 브라우저와 같이 인가 요청과 응답을 처리할 수 있는 대안이 있다면 사용될 수도 있습니다.&nbsp;

몇몇의 플랫폼은 인앱브라우저탭으로 알려진 브라우저 기능을 지원하기도 합니다. 앱이 컨텍스트 변경없이, 앱 컨텍스트 상에서 브라우저 탭을 보여주는 이러한 방식은 여전히 인증의 공유나 보안적 컨텍스트가 유지된다면 인가요청을 위해 추천되는 방법입니다.&nbsp;&nbsp;

<h3 data-ke-size="size23">7. 네이티브앱에서 인가응답을 받기</h3>
브라우저로부터 인가 응답을 받기 위한 부분에서 네이티브앱은 몇 가지 redirect URI 옵션을 가집니다.&nbsp;

이 베스트프랙티스를 fully support하기 위해서, 인가 서버는 반드시 하기의 방법 중 최소 3가지는 네이티브앱을 통해 제공하여야 합니다.&nbsp;


<h4 data-ke-size="size20">7.1 Private-Use URI Scheme Redirection</h4>
많은 모바일, 데스크탑 컴퓨팅 플랫폼은 앱이 private-use URI scheme을 등록하도록 하여(또는 "custom URL schemes"으로 불림) 앱 간의 커뮤니케이션을 지원합니다 (예, "com.example.app"). 브라우저나 다른 앱이 private-use URI scheme으로 URI를 로드하려고 하면, 등록된 앱이 요청 처리를 위해 런칭되고 scheme 이후의 path나 parameter 등을 통해 인증 응답을 앱에 전달하게 됩니다.

Private-use URI scheme redirect로 OAuth 2.0 인가 요청을 수행하기 위해서, 네이티브앱은 일반적인 인가 요청으로 브라우저를 열지만 운영체제에 등록된 redirect URI를 통해 응답을 받게됩니다.

앱과 관련한 URI scheme을 선택할 때에는, 앱은 반드시 컨트롤 가능한 도메인 이름에 기반하여 만들어야 합니다 (RFC7595 Section 3.8).&nbsp;

또한 동일한 퍼블리셔가 여러 앱을 소유한 경우, Scheme이 유니크하도록 주의하여야 합니다. 상세한 URI 형태는 RFC3986 Section 3.2에 따르며, 구체적으로는 아래 예시와 같은 형태입니다:

com.kadensungbincho.app:/oauth2/callback?code=2390hrilnfiaeobwoeqr&amp;state=lknqiniowerbntoiwerbtiowerubt

<h4 data-ke-size="size20">7.2 Claimed "https" Scheme URI Redirection</h4>
몇몇의 운영체제는 앱이 해당하는 앱의 컨트롤 하에 있는 "https" scheme[RFC7230] URI를 claim할 수 있도록 지원합니다. 브라우저가 claimed URI를 보게되면, 브라우저 상에서 페이지가 로딩되는 것이 아니라 런치 파라미터로 제공된 URI와 같이 네이티브앱이 런칭됩니다 (이 부분은 앱이 실행되는 환경(OS)에 따라서 설정하게 됩니다. 즉, IoS는 IoS방식으로, android는 android 방식으로).

그러한 URI들은 기존의 웹-기반 클라이언트 URI와 구분되지 않습니다. 예시로,

<a href="https://kadensungbincho.com/oauth2/callback?code=2390hrilnfiaeobwoeqr&amp;state=lknqiniowerbntoiwerbtiowerubt">https://kadensungbincho.com/oauth2/callback?code=2390hrilnfiaeobwoeqr&amp;state=lknqiniowerbntoiwerbtiowerubt</a>&nbsp;


redirect URI로는 confidential한 웹 클라이언트로부터 퍼블릭 네이티브앱 클라이언트를 구분할 수 없어서, Section 8.4에서 client type을 클라이언트 등록 시점에 등록하도록 권장하고 있습니다 (OAuth 스펙 상 client를 인가 서버에 등록하고 사용하게 되어 있는데, 그 시점에 타입을 추가하도록 권장하는 부분).

이 방법은 목적지 앱이 운영체제에 의해 인가 서버에 보증되기에 다른 방법과 비교해 장점을 가지며, 가능하다면 이 방법을 다른 옵션보다 우선해 사용해야(SHOULD)합니다.

<h4 data-ke-size="size20">7.3 Loopback 인터페이스 Redirection</h4>
특별한 권한 없이 loopback 네트워크 인터페이스 상의 포트를 열 수 있는 네이티브앱(예, 데스크탑 운영 체제)은 OAuth redirect를 받기 위해 loopback 인터페이스를 사용할 수 있습니다. Loopback redirect URIs는 "http" scheme을 사용하며 loopback ip literal과 클라이언트가 listening하는 어떤 포트로 구성되게 됩니다:

http://127.0.01:{port}/{path}
http://127.0.0.1:51004/oauth2redirect/example-provider
http://[::1]:{port}/{path}
http://[::1]:61023/oauth2redirect/example-provider

인가 서버는 반드시 loopback IP redirect URI를 위해 요청 시점에 어떤 포트인지 명시하는 것을 허용해야 합니다 (요청 시점에 운영체제로부터 가용한 임시 포트를 얻어 요청하는 클라이언트를 커버하기 위해서).


<h3 data-ke-size="size23">8. 보안적 고려 사항들</h3>
<h4 data-ke-size="size20">8.1 인가코드를 보호하기</h4>


Reference
(1) <a href="https://www.rfc-editor.org/info/rfc8252" target="_blank" rel="noopener">https://www.rfc-editor.org/info/rfc8252</a>
 
 
 </div></div>

Kaden Sungbin Cho

아래는 개인적인 공부를 목적으로 RFC-8252인 OAuth 2.0 for Native Apps를 번역한 내용입니다. 이상한 부분 피드백 주시면, 감사히 수정하겠습니다 :)
 
 
네이티브앱을 위한 OAuth 2.0
Abstract
네이티브앱으로부터의 OAuth 2.0 인가 요청은 반드시 주로 유저의 브라우저인 외부유저에이전트를 통해 이뤄져야 합니다. 이 스펙은 왜 그러한지에 대해 보안적, 사용성적인 이유를 다루고, 네이티브앱과 인가 서버가 이 베스트프랙티스를 어떻게 구현할 수 있는지를 설명합니다. 
 
 
1. Introduction
OAuth 2.0 인가 프레임워크를 설명하는 RFC6749에선, 인가 엔드포인트와 연동되는 native apps를 위해 2가지 방법을 제시합니다: 임베디트 유저에이전트(embedded user-agent)와 외부유저에이전트(external user-agent).
 
이 현 시점의 베스트프랙티스는 위 목적을 위해 브라우저와 같은 external user agent만을 사용할 것을 권장하고 상세 구현에 대한 내용을 소개합니다. 
 
2. 컨벤션
(생략)
 
3. 용어
네이티브앱 (native app): 유저에 의해 기기에 설치된 앱 또는 애플리케이션으로, 브라우저 컨택스트에서만 실행되는 웹앱과 구분됨. 웹 기반의 기술을 통해 구현되었으나 네이티브앱을 통해 배포된 것, 소위 "하이브리드 앱"(예로, React Native 등)은 이 스펙에서는 네이티브앱과 동일한 것으로 간주함.
앱 (app): 네이티브앱을 지칭함.
앱스토어 (app store): 유저가 앱을 구매하고 다운로드할 수 있는 스토어.
외부유저에이전트 (external user agent): 인가 요청을 처리할 수 있는 유저 에이전트로 네이티브앱에 대해 구분된 entity이거나 security 도메인. 그렇기에 앱은 외부유저에이전트의 쿠키 스토어나 페이지 컨텐츠를 살펴보거나 변경하거나 접근할 수 없음. 
임베디드유저에이전트 (embedded user agent): 네이티브앱에 의해 호스트된 유저 에이전트로 앱의 일부를 구성하거나 같은 security 도메인을 공유하는 인가 요청을 생성함. 그렇기에 쿠키 스토어나 페이지 컨텐츠 접근 및 변경이 가능함. 
브라우저 (browser): http, https scheme을 핸들링하기 위해 운영체제에 의해 런칭되는 디폴트 애플리케이션.
인앱 브라우저 탭 (in-app browser tab): 호스트 앱 안에서 보여지는 브라우저로 브라우저의 일반적인 인증 상태 및 보안 특성을 가짐. 
웹뷰 (webview): 앱에 embedded된 웹 브라우저 UI 컴포넌트로 앱의 컨트롤 하에 웹 페이지를 렌더링함.
claimed "https" scheme URI: 몇몇 플랫폼은 앱이 도메인 이름에 대한 소유권을 증명하면 특정 "https" scheme URI를 클레임할 수 있도록 함. Claimed된 URIs는 브라우저가 아니라 앱으로 열리게 됨. 
private-use URI scheme: 앱에 의해 정의되고 운영체제에 등록된 URI scheme. 그러한 scheme에 대한 URI 요청은 요청을 처리하기 위해 등록된 앱을 런칭하게 됨. 
reverse domain name notation: 도메인 이름 시스템에 기반한 네이밍 컨벤션으로, 도메인 컴포넌트가 reverse함. "app.example.com" → "com.example.app"
 
4. Overview
네이티브앱에서 유저에 대한 인가를 진행하기 위해서, 현재의 베스트프랙티스는 OAuth 인가 요청을 임베디드유저에이전트(웹뷰와 같은 것으로 구현된 것들)가 아닌 외부유저에이전트(주로 브라우저)에서 행하게 됩니다. 
 
이전에는, 네이티브앱에서 OAuth 인가를 위해 임베디드유저에이전트를 사용하는 것이 흔하였습니다. 이러한 방식은 호스트 앱이 유저의 비밀정보나 쿠키에 접근할 수 있다는 취약점, 매 앱마다 로그인을 다시 해야한다는 점 등의 단점이 존재했습니다. 
 
브라우저를 사용하는 네이티브앱 인가 플로우는, 이미 OAuth 인가 요청과 응답이 URI를 통해 이뤄지기에 OAuth 프로토콜 변경 없이도 가능합니다. 이것은 앱 간의 커뮤니케이션에 사용될 수 있는 URI들을 포함합니다. 이 스펙을 따르기 위해서는 모든 클라이언트가 confidential 한 것으로 가정하는 몇몇의 OAuth 서버 구현은 퍼블릭 네이티브앱 클라이언트에 대한 부분을 추가해야하며, 그러한 클라이언트가 사용하는 redirect URI들을 지원해야 합니다. 
 
 
브라우저를 사용한 네이트브앱에서의 인가 플로우
위 표1은 유저에 대한 인가를 진행하기 위한 네이티브앱과 브라우저간 흐름을 나타내고 있습니다.
 
(1) 클라이언트 앱이 인가 요청과 같이 브라우저 탭을 열게됨.
(2) 인가 엔드포인트는 인가 요청을 받고, 유저를 인증하고, 인가를 획득함. 유저를 인증하는 부분은 다른 인증 시스템 연계를 포함할 수 있음.
(3) 인가 서버는 인가 코드(authorization code)를 발행하여 redirect URI를 통해 돌려줌.
(4) 클라이언트는 인가 코드를 redirect URI를 통해 받음.
(5) 클라이언트 앱은 토큰 엔드포인트에 인가 코드를 제출함.
(6) 토큰 엔드포인트는 인가 코드를 검증하고 요청된 토큰을 발행함. 
 
 
5. OAuth를 위한 앱 간 URI 커뮤니케이션
URI가 웹상에서 OAuth 2.0 (RFC6749)에 사용되듯이, 네이티브앱에서 인가 요청을 시작하고, 응답을 받기 위해 URI를 사용할 수 있습니다.
OAuth 2.0 web과 동일한 방식을 채택하여 네이티브앱의 OAuth 역시 SSO 세션이나 보안과 같은 이점을 누릴 수 있습니다. 동일한 방식을 취하는 것은 구현 복잡도를 낮출 뿐만 아니라 특정 플랫폼을 위해 구현되지 않은 스탠다드 기반의 웹 플로우에 의존하면서 상호운용성을 높일 수 있습니다.
이 베스트프랙티스를 따르기 위해서, 네이티브앱은 OAuth 인가 요청을 수행하기 위해 반드시 외부유저에이전트를 사용하여야 합니다. 외부에이전트의 사용은 인가요청을 브라우저에서 열고, 네이티브앱으로 돌아가기 위해 인가 응답을 돌려주는 redirect URI를 통해 가능합니다.
 
 
6. 네이티브앱에서의 인가요청을 시작하기
유저 인가가 필요한 네이티브앱은 RFC6749의 Section 4.1의 인가 코드 grant type을 넣어 인가 요청 URI를 생성하고, 네이티브앱이 받을 수 있는 redirect URI를 사용하게 됩니다. 
 
네이티브앱의 인가요청을 위한 redirect URI의 기능은 웹 기반의 인가 요청에 있는 것과 비슷합니다. 인가 응답을 OAuth 클라이언트의 서버로 보내는 것 대신에, 네이티브앱이 사용하는 redirect URI은 응답을 앱으로 돌려보내줍니다. 다양한 플랫폼에 네이티브앱에 redirect URI를 통해 인가요청 응답을 돌려주는 방식은 섹션 7에 정리되어 있습니다. 
 
퍼블릭 네이티브앱 클라이언트는 반드시 PKCE(Proof Key for Code Exchange)를 구현하여야 하며, 인가 서버도 그러한 클라이언트에 대해 반드시 PKCE를 지원하여야 합니다. 그 이유는 섹션 8.1에 기술되어 있습니다.
 
인가요청 URI를 생성한 이후에, 앱은 플랫폼-특정한 API를 사용해 URI를 외부유저에이전트에서 엽니다. 주로, 사용되는 외부유저에이전트는 디폴트 브라우저입니다. 그러나, 다른 형태의 외부유저에이전트를 사용할(MAY) 수도 있습니다.
 
이 베스트프랙티스는 네이티브앱을 위한 외부유저에이전트 중 브라우저를 추천하는(RECOMMENDED) 관점으로 기술합니다. 유저 인가를 위해 제작된 외부유저에이전트나 브라우저와 같이 인가 요청과 응답을 처리할 수 있는 대안이 있다면 사용될 수도 있습니다. 
 
몇몇의 플랫폼은 인앱브라우저탭으로 알려진 브라우저 기능을 지원하기도 합니다. 앱이 컨텍스트 변경없이, 앱 컨텍스트 상에서 브라우저 탭을 보여주는 이러한 방식은 여전히 인증의 공유나 보안적 컨텍스트가 유지된다면 인가요청을 위해 추천되는 방법입니다.  
 
7. 네이티브앱에서 인가응답을 받기
브라우저로부터 인가 응답을 받기 위한 부분에서 네이티브앱은 몇 가지 redirect URI 옵션을 가집니다. 
 
이 베스트프랙티스를 fully support하기 위해서, 인가 서버는 반드시 하기의 방법 중 최소 3가지는 네이티브앱을 통해 제공하여야 합니다. 
 
 
7.1 Private-Use URI Scheme Redirection
많은 모바일, 데스크탑 컴퓨팅 플랫폼은 앱이 private-use URI scheme을 등록하도록 하여(또는 "custom URL schemes"으로 불림) 앱 간의 커뮤니케이션을 지원합니다 (예, "com.example.app"). 브라우저나 다른 앱이 private-use URI scheme으로 URI를 로드하려고 하면, 등록된 앱이 요청 처리를 위해 런칭되고 scheme 이후의 path나 parameter 등을 통해 인증 응답을 앱에 전달하게 됩니다.
 
Private-use URI scheme redirect로 OAuth 2.0 인가 요청을 수행하기 위해서, 네이티브앱은 일반적인 인가 요청으로 브라우저를 열지만 운영체제에 등록된 redirect URI를 통해 응답을 받게됩니다.
 
앱과 관련한 URI scheme을 선택할 때에는, 앱은 반드시 컨트롤 가능한 도메인 이름에 기반하여 만들어야 합니다 (RFC7595 Section 3.8). 
 
또한 동일한 퍼블리셔가 여러 앱을 소유한 경우, Scheme이 유니크하도록 주의하여야 합니다. 상세한 URI 형태는 RFC3986 Section 3.2에 따르며, 구체적으로는 아래 예시와 같은 형태입니다:
 
com.kadensungbincho.app:/oauth2/callback?code=2390hrilnfiaeobwoeqr&state=lknqiniowerbntoiwerbtiowerubt
 
7.2 Claimed "https" Scheme URI Redirection
몇몇의 운영체제는 앱이 해당하는 앱의 컨트롤 하에 있는 "https" scheme[RFC7230] URI를 claim할 수 있도록 지원합니다. 브라우저가 claimed URI를 보게되면, 브라우저 상에서 페이지가 로딩되는 것이 아니라 런치 파라미터로 제공된 URI와 같이 네이티브앱이 런칭됩니다 (이 부분은 앱이 실행되는 환경(OS)에 따라서 설정하게 됩니다. 즉, IoS는 IoS방식으로, android는 android 방식으로).
 
그러한 URI들은 기존의 웹-기반 클라이언트 URI와 구분되지 않습니다. 예시로,
 
https://kadensungbincho.com/oauth2/callback?code=2390hrilnfiaeobwoeqr&state=lknqiniowerbntoiwerbtiowerubt 
 
 
redirect URI로는 confidential한 웹 클라이언트로부터 퍼블릭 네이티브앱 클라이언트를 구분할 수 없어서, Section 8.4에서 client type을 클라이언트 등록 시점에 등록하도록 권장하고 있습니다 (OAuth 스펙 상 client를 인가 서버에 등록하고 사용하게 되어 있는데, 그 시점에 타입을 추가하도록 권장하는 부분).
 
이 방법은 목적지 앱이 운영체제에 의해 인가 서버에 보증되기에 다른 방법과 비교해 장점을 가지며, 가능하다면 이 방법을 다른 옵션보다 우선해 사용해야(SHOULD)합니다.
 
7.3 Loopback 인터페이스 Redirection
특별한 권한 없이 loopback 네트워크 인터페이스 상의 포트를 열 수 있는 네이티브앱(예, 데스크탑 운영 체제)은 OAuth redirect를 받기 위해 loopback 인터페이스를 사용할 수 있습니다. Loopback redirect URIs는 "http" scheme을 사용하며 loopback ip literal과 클라이언트가 listening하는 어떤 포트로 구성되게 됩니다:
 
http://127.0.01:{port}/{path}
http://127.0.0.1:51004/oauth2redirect/example-provider
http://[::1]:{port}/{path}
http://[::1]:61023/oauth2redirect/example-provider
 
인가 서버는 반드시 loopback IP redirect URI를 위해 요청 시점에 어떤 포트인지 명시하는 것을 허용해야 합니다 (요청 시점에 운영체제로부터 가용한 임시 포트를 얻어 요청하는 클라이언트를 커버하기 위해서).
 
 
8. 보안적 고려 사항들
8.1 인가코드를 보호하기
 
 
Reference
(1) https://www.rfc-editor.org/info/rfc8252

OAuth 2.0 for Native Apps, RFC-8252 (번역)

댓글