> This page is for 플랫폼, version 레거시.
> For other versions, use one of these documentation indexes:
> - V4 (default): https://next.developer.frame.io/platform/v4/llms.txt
> - V4 실험적: https://next.developer.frame.io/platform/v4-experimental/llms.txt
> - 레거시: https://next.developer.frame.io/platform/v2/llms.txt

> For clean Markdown of any page, append .md to the page URL.
> For a complete documentation index, see https://next.developer.frame.io/llms.txt.
> For AI client integration (Claude Code, Cursor, etc.), connect to the MCP server at https://next.developer.frame.io/_mcp/server.

# OAuth 2 권한 부여 코드 흐름

## 개요

Frame.io는 OAuth 2 애플리케이션의 생성 및 관리를 지원합니다. [개발자 토큰](/getting-started/authentication#developer-tokens)과 달리 OAuth 2 앱은 모든 Frame.io 사용자가 보안 로그인을 통해 자신의 자격 증명을 부여할 수 있도록 하며, 그 후 앱이 해당 사용자를 대신하여 작업을 수행할 수 있습니다.

간단히 말해, 개별 사용자의 컨텍스트와 액세스 권한이 중요한 통합 시나리오에서는 OAuth 2 앱이 가장 적합합니다.





## OAuth 2 코드 흐름




### 기본 순서




큰 틀에서 볼 때 OAuth 2에는 다음 세 당사자가 있습니다.



1. **사용자**(이 경우: Frame.io 로그인 계정이 있는 모든 사람)
2. 클라이언트 **애플리케이션**(외부 OAuth 2.0 앱)
3. 자격 증명 **서버**(이 경우: Frame.io)





OAuth 2의 코드 흐름은 다음 4단계 프로세스로 이루어집니다.



1. **애플리케이션**이 **사용자**에게 로그인 화면을 표시합니다.
2. **사용자**가 자신의 자격 증명을 입력하면, 이 정보는 **서버**로 직접 전송됩니다.
3. 로그인에 성공하면, **서버**는 **사용자**에게 **애플리케이션**에 사전 구성된 권한 집합을 부여할 것인지 확인하는 페이지를 반환합니다.
4. **사용자**가 동의하면, **서버**는 **애플리케이션**이 요청된 권한 내에서 **사용자**를 대신하여 작업할 수 있도록 토큰을 애플리케이션에 전송합니다.





이러한 방식으로 클라이언트 애플리케이션은 사용자의 실제 자격 증명을 보거나 직접 다루지 않고도, 사용자의 승인하에 안전하게 사용자를 대신하여 작업을 수행할 수 있습니다.





### 콜백 주기




위의 순서는 서버(Frame.io)가 각각 고유한 경로를 가진 두 개의 서비스를 호스팅하는 방식에 의존합니다.




| 서비스 | URL | 방법 | 설명 |
| ---------- | ---------- | ---------- | ---------- |
| 인증 | `https://applications.frame.io/oauth2/auth` | `GET` | OAuth 클라이언트 애플리케이션에 대한 정보가 주어지면, 서버와 권한 부여 흐름을 호출합니다. |
| 토큰 | `https://applications.frame.io/oauth2/token` | `POST` | 인증 단계에서 전달된 정보를 바탕으로 사용자를 대신해 토큰을 가져옵니다. |




이 주기에서 OAuth 2 애플리케이션의 역할은 서버에 자신을 식별시키고 위의 두 가지 요청을 수행하는 것입니다.





## 간단한 예시



<Info title="이전에 OAuth 2 앱을 구축해 본 적이 있으신가요?">
  OAuth 2.0의 기반 구조에 익숙하다면 아래 예시만으로도 시작하기에 충분할 수 있습니다. 조금 더 자세한 내용이 필요하다면 [여기](/oauth-2-applications/building-an-oauth2-app)에서 상세 가이드를 확인하세요.
</Info>


### 앱 설정



1. Frame.io 자격 증명을 사용하여 [Frame.io Developer Portal](/)에 로그인한 뒤, 왼쪽의 링크를 사용해 **OAuth Apps**로 이동하여 **New**를 클릭해 앱 설정을 시작합니다.
2. 다음 화면에서 앱의 **이름**과 **리디렉션 URI**를 입력하고 **권한**을 선택한 다음 **PKCE** 사용 여부를 결정합니다.
3. 저장하면 새 앱 구성이 표시됩니다.




<Info title="PKCE 정보">
  PKCE(**P**roof **K**ey for **C**ode **E**xchange) 설정을 활성화하면 앱이 `client_secret`을 제공하지 않고도 토큰을 요청할 수 있습니다. 따라서 별도의 `client_secret`이 발급되지 않으며, 앱의 콜백 주기에서 토큰을 요청(`POST`)할 때 `Authorization` 헤더를 포함해서는 안 됩니다. 즉, **콜백에 반드시 `client_id`를 포함해야 하며**, 그렇지 않으면 요청이 거부됩니다.
</Info>


#### PKCE는 언제 사용해야 하나요?




일반적으로 PKCE를 사용함에 있어 부정적인 부작용은 없으며, 이를 사용하는 것이 가장 권장되고 선호되는 방식입니다. OAuth 2.0 클라이언트 애플리케이션을 개발할 때 권한 부여 코드 흐름은 다음 두 가지 컨텍스트 중 하나에서 구현됩니다.

- **비공개**: 흐름이 서버 측 언어(Python, Java 등)로 구현되며, 귀하가 제어하는 서버에서 `client_secret`을 안전하게 관리할 수 있습니다. - **공개**: 흐름이 클라이언트측 언어(JavaScript) 또는 최종 사용자가 제어하는 클라이언트 장치(iOS, Android)에서 직접 구현됩니다.

일반적인 원칙으로, 애플리케이션 개발자가 시크릿(secret) 교환과 관련된 모든 네트워크 트래픽을 확인하고 제어할 수 없는 경우 해당 애플리케이션을 &quot;공개(Public)&quot;로 간주해야 합니다. 이는 클라이언트 측 애플리케이션뿐만 아니라 모바일 디바이스 앱, 임베디드 디바이스, 또는 최종 사용자 네트워크에 연결된 모든 기기(AppleTV, Roku 등)를 공개로 간주해야 함을 의미합니다.





비공개 컨텍스트에서는 PKCE를 *선택적으로 사용*할 수 있습니다. 공개 컨텍스트에서는 PKCE를 *반드시 사용*해야 합니다.





## OAuth 2 애플리케이션 구축




이제 Frame.io에 앱 구성이 완료되었으므로, 위의 표에 따라 콜백 주기를 완료하기 위한 두 가지 주요 경로를 처리하도록 콜백 서버를 설정할 수 있습니다.

애플리케이션을 구축하는 방법에 대한 자세한 내용은 [OAuth 2 앱 구축하기](/oauth-2-applications/building-an-oauth2-app)를 참조하세요.