액세스 토큰 이동성

이 가이드에서는 요구 사항에 맞는 구성으로 앱을 빌드할 수 있도록 이동성에 대한 일반적인 시나리오를 몇 가지 설명합니다.

다양한 앱 유형에 대한 토큰 사용

액세스 토큰은 이동 가능합니다. 토큰을 얻으면 어떤 컴퓨터에서든 사용할 수 있습니다. 웹 인터페이스, 모바일 클라이언트, 서버를 결합하면 여러 가지 가능한 구성의 조합을 얻을 수 있습니다. 하지만 이런 구성의 차이는 기능과 보안 면에서 각각 장단점이 있습니다.

구성	장점	단점	보안 노트
로그인과 API 요청이 웹 클라이언트에서 실행됩니다(단기 실행 토큰).	구현이 간단합니다.	오프라인 게시가 없습니다. 장기 액세스가 불가능합니다. 자주 인증해야 합니다.
로그인과 API 요청이 네이티브 모바일 또는 웹 클라이언트에서 실행됩니다(장기 실행 토큰).	인증 빈도가 낮습니다.	오프라인 게시가 없습니다.
로그인과 API 요청이 웹 클라이언트에서 실행됩니다(코드 교환 후 장기 실행 토큰).	특정 상황에서 추가적인 보안을 제공합니다.	구현이 어렵습니다. 오프라인 게시가 없습니다.	특정 상황에서만 유용합니다.
로그인이 네이티브 모바일 또는 웹 클라이언트에서 실행됩니다. API 요청이 서버에서 실행합니다(장기 실행 토큰).	오프라인 게시가 가능합니다. 서버 기반 호출로 사용 가능한 보안 기능을 추가합니다.	클라이언트가 서버를 호출해 모든 호출을 프록시로 보내야 합니다.	모든 호출에 `appsecret_proof`를 사용합니다.
로그인이 네이티브 모바일 또는 웹 클라이언트에서 실행됩니다. API 요청이 서버 또는 클라이언트에서 실행됩니다.	오프라인 게시가 가능합니다. 클라이언트의 사용자 중심 게시입니다.	구현이 어렵습니다.	서버에서 보내는 모든 호출에 `appsecret_proof`를 사용합니다.

인증과 API 요청이 클라이언트에서 실행되는 가장 간단한 구성입니다. 이 모델에 가능한 세 가지 구성이 있습니다.

네이티브 또는 웹 클라이언트가 반환된 단기 실행 토큰이나 장기 실행 토큰을 인증하고 호출에 사용합니다.
웹 클라이언트가 서버를 통해 단기 실행 토큰을 인증하고 장기 실행 토큰으로 교환합니다. 이 토큰은 웹 클라이언트로 전송되고 웹 클라이언트는 이를 사용하여 API 호출을 보냅니다.
웹 클라이언트가 서버를 통해 단기 실행 토큰을 인증하고 장기 실행 토큰으로 교환합니다. 서버가 클라이언트에 코드를 전송합니다. 클라이언트가 코드를 장기 실행 토큰을 교환하고 이를 사용하여 API 호출을 보냅니다. 이 구성은 거의 사용하지 않습니다.

이 일반적인 구성에서 인증은 클라이언트에서 실행되지만 모든 API 호출은 클라이언트 대신 서버에서 보냅니다. 이 서버는 appsecret_proof 매개변수를 사용하여 호출 시 보안을 더욱 강화할 수 있습니다.

이 구성은 위의 방법을 조합한 것입니다.

Facebook SDK에서 API 호출에 사용할 액세스 토큰을 지정하는 방법은 여러 가지입니다.