[Facebook] Access Tokens

Access Token의 종류

사용자가 특정 앱을 사용하게 되면 해당 앱은 Access Token을 수령하게 됩니다. 사용자의 로그인하고 앱을 승인하면 이를 바탕으로 Access Token이 생성되어 앱에 전달되며, 앱은 Access Token을 사용하여 사용자 정보에 접근하하게 됩니다.

Access Token은 무작위 문자열로서 다양한 방법을 통해 생성될 수 있습니다. Token에는 Token의 완료일자, Token을 생성한 앱에 대한 정보를 포함하고 있습니다. Access token은 다음과 같이 여러 종류가 있으며, 각각 다른 방법과 목적으로 사용됩니다.

• User Access Token

  가장 보편적으로 사용되는 유형으로써 앱이 특정한 사용자의 정보를 읽거나 쓰거나 수정할 때 필요한 Token입니다. User Access Token은 Login Dialog를 통해서 해당 사용자가 로그인하고, 앱에 대해 승인하면 생성되게 됩니다.

• App Access Token

  앱의 설정을 변경하거나 읽거나, Open Graph action을 발행하는데 필요한 Token입니다.

• Page Access Token

  User Access Token과 동일하지만, 사용자가 아니라 페이스북 페이지에 대한 Token이라는 점이 다릅니다. Page Access Token을 얻기 위해서는 먼저 User Access Token을 요청하면서 manage_pages 권한을 요청해야 합니다. User Access Token을 받게 되면 Page Access Token은 Graph API 요청를 통해서 얻을 수 있습니다.

• Client Token

  스마트폰과 같은 Mobile App이나 PC등의 Desktop App에 포함되어 앱을 식별하는데 사용되는 Token입니다. 다른 Access Token과 달리 앱에 포함되기 때문에 이 Token은 Secret Identifier로 간주되지 않습니다. 보통 Access Token은 사적인 정보를 조회하고 사용자 정보를 수정할 수 있기 때문에 유출되지 않도록 관리해야 합니다. 하지만 Client Token은 Application에 직접 포함되는 Token이기 때문에 App-level API에 대한 요청만 할 수 있도록 기능이 제한됩니다. Client Token은 App의 Dashboard에서 확인할 수 있으며 굉장히 드물게 제한적으로 사용되므로 이 Token에 대해서는 크게 다루지 않을 예정입니다.

Access Token 생성하기

모든 플랫폼은 Access Token을 생성하기 위해 다른 API를 사용합니다. 그럼에도 다음과 같은 공통적인 기본 순서와 규칙을 따르게 됩니다.

앱에서 접근을 위한 권한과 승인을 얻기 위해 Login Dialog나 SDK를 통해서 페이스북에 요청하게 됩니다.

→

페이스북은 사용자에게 로그인을 통한 인증을 요청하게 되고, 앱을 승인할 지 물어보게 됩니다.

→

사용자가 승인하면 페이스북은 해당 앱에 AccessToken을 전달해줍니다.

플렛폼에 따라 Access Token을 얻거나 다루는 방법에는 차이가 있습니다.

• Facebook SDK for Javascript에서는 영구적인 Access Token을 자동적으로 생성합니다. FB.getAuthResponse를 호출하게되면 응답정보에 Access Token이 포함되게 됩니다. 보다 자세한 정보는 Login for Javascript 문서를 통해서 얻을 수 있습니다.
• Facebook SDKs for iOS and Android에서는 Access Token을 각 FBSession과 com.facebook.Session Class를 통해서 관리하게 됩니다. 해당 Class의 FBSession.accessTokenData, Session.getAccessToken을 통해 Access Token을 얻을 수 있습니다. 자세한 정보는 다음 문서를 참고하세요. (Facebook SDKs for iOS, Facebook SDKs for Android)
• 웹에서 Facebook SDK for Javascript를 이용하지 않고 AccessToken을 얻기 위해서는 다른 방법이 요구됩니다. 아래에 자세한 방법을 설명 드리고자 합니다.

Short-Term and Long-Term Tokens

User Access Token에는 두 가지 유형이 있습니다. Short-lived token과 Long-lived token입니다. Short-lived token은 보통 1~2시간안에 만료되게 됩니다. Long-lived token은 60일 동안 유지됩니다. 하지만 이 길이는 오류나 여러 요인에 의해서 더 짧아 질 수 있기 때문에 Access Token 만료에 대한 고려가 필요합니다.

웹에서 생성되는 Token은 Short-lived token이며 Short-lived token을 바탕으로 다시 Long-lived token을 요청할 수 있습니다. Mobile app과 Facebook’s mobile SDK는 기본적으로 Long-lived token을 얻습니다.

Token은 옮겨질 수 있습니다.

일단 Access Token이 생성되면 모바일, 웹브라우저 혹은 서버 등 다양한 위치에서 직접 페이스북으로 요청을 할 수 있습니다. 예를 들어 Client에서 생성된 Access Token을 서버로 전송하여, 서버에서 페이스북으로 API요청을 할 수 도 있으며 그 반대도 가능합니다.

Access Token을 사용할 수 있는 장소에 대한 제약이 없으며 누군가 이를 취득하게 될 경우 상당한 권한을 얻게되므로, Access Token을 전달하고 관리하는 방법에 대해서는 상당한 보안과 구조적 영향을 고려해서 앱을 작성하여 변조, 유출되지 않도록 해야 합니다. 자세한 정보는 다음 문서를 참고하세요. (https://developers.facebook.com/docs/facebook-login/access-tokens/#architecture)

App Tokens

App Access Token은 사용자가 아닌 앱에 관한 페이스북 API를 요청하는데 사용됩니다. 이 Token을 통해서 앱의 설정, 앱의 사용자, 앱의 Insight (페이스북에서는 통계정보를 Insight라고 함)를 조회할 수 있습니다. 또한 앱에 대해 Puglish 권한을 가진 사용자는 앱의 컨텐트도 작성할 수 있습니다.

주의 만약 앱 유형이 Native/Desktop이라면 페이스 북은 해당 App Access Token이 안전하지 않은 것으로 간주합니다. 따라서 이러한 API 요청은 동작하지 않을 것입니다. 페이스북은 Native/Desktop 앱은 실수 혹은 착오로 인해서 App Secret 정보를 Client의 어딘가에 보관할 수 있다고 가정합니다. 따라서 이 Secret를 통해서 App Token이 생성될 수 있기 때문에 Native/Desktop App에 대해서는 안전하지 않을 수 있다고 가정하며 API요청을 제한합니다.

App Access Token을 생성하기 위해서는 다음 Graph API 요청을 하면 됩니다.

	GET /oauth/access_token?
	client_id={app-id}
	&client_secret={app-secret}
	&grant_type=client_credentials

위의 요청을 통해서 생성된 App Access Token을 통해서 API 요청을 할 수 있습니다 보안을 위해서 Access Token은 절대 Cient에 하드코드 되어선 안됩니다. 만약 Client App에 하드코드 한다면 해당 앱의 이용자들 중 누군가 Decompile해 볼 것이고 해당 Access Token을 통해서 앱에 대한 모든 권한을 가지고 악용할 수 있기 때문입니다. 따라서 대부분의 경우에 Access Token을 Server to server 요청으로만 사용할 것이 권장됩니다.

주의 App Secret은 절대 유출되지 않도록 하는 것은 매우 중요합니다. 왜냐하면 App Secret를 통해 App Token을 생성할 수 있기 떄문입니다. 따라서 App Secret을 통해 Access Token을 요청하는 것은 반드시 서버에서 진행하는 것이 필요합니다.

위와 같은 API요청을 하는데 있어 App Access Token을 요구하지 않는 방법도 제공합니다. 단지 App Secret와 App Id를 포함하여 요청을 진행하면 됩니다.

http://graph.facebook.com/endpoint?key=value&access_token=app_id|app_secret

Token의 만료와 갱신

Javascript SDK, iOS SDK, Android SDK 등 페이스북 공식 API는 SDK가 토큰이 만료되기 전에 갱신되도록 Token을 관리합니다.

페이스북 SDK를 사용하는 Native Mobile Application들은 60일 동안 유효한 Long-lived Access Token을 가지게 됩니다. 그리고 페이스북으로 API요청이 만들어 질 때마다 하루에 한번 씩 만료일이 갱신되게 됩니다. 하지만 API요청이 없이 60일이 지나면 Token은 만료될 것이고, 그러면 다시 사용자는 로그인과 새로운 토큰을 받는 과정을 거쳐야 합니다.

웹에서 Access Token은 약 2시간 후 만료되는 Short-lived Token을 사용합니다. 하지만 60일 동안 유지되는 Long-lived Token이 필요하다면 Short-lived Token을 Long-lived Token으로 변환하는 과정이 필요합니다.

1. Client에서 Login Dialog를 통해서 Short-lived Access Token이 발급되고, 서버로 전달됩니다.
2. Server에서는 다음과 같은 요청을 통해서 Long-lived Access Token으로 교환할 수 있습니다.

   			GET /oauth/access_token?
   			grant_type=fb_exchange_token&
   			client_id={app-id}&
   			client_secret={app-secret}&
   			fb_exchange_token={short-lived-token}
   		

이 요청에는 App Secret이 포함되게 됩니다. App Secret는 절대로 유출되어선 안되는 정보입니다. 따라서 Long-lived Token으로 변경하는 위 요청문은 반드시 서버에서 진행해야 합니다.

Long-lived Token으로 교환하는 작업은 반드시 만료되지 않은 Short-lived Token으로 진행되어야 합니다. 일단 Short-lived Token이 만료되버리면 다시 처음부터 Short-lived Token을 수령하는 작업을 진행해야 합니다.

Long-lived Token의 갱신

Long-lived Token도 결국은 만료될 것이기 때문에 갱신이 필요합니다. 갱신이 필요하다면 언제든지 Access Token을 얻기 위해 거쳤던 로그인 과정을 다시 진행하면 됩니다. 물론 이 과정에서 사용자가 이미 로그인 되어 있다면 사용자는 다시 로그인이나 앱의 승인에 대한 화면을 보는 일 없이 즉시 Redirect되며 이를 통해 새로운 Access-Token이 서버로 전달 될 것입니다.

물론 사용하고 있는 SDK나 앱에 따라 로그인 과정은 다를 수 있지만, 이 과정을 통해서 새로운 Access Token이 생성될 수 있습니다. Javascript SDK를 이용하고 있다면 Background에서 작업이 진행될 것이고, Server에서 OAuth 2.0을 통해 인증을 한다면 사용자는 Login Dialog로 Redirect되며, 사용자가 로그인 되어 있다면 사용자에게 로그인 화면을 보여주지 않고 다시 서버로 Redirect되면서 서버는 새로운 Access Token을 얻을 수 있게 됩니다.

위의 과정을 거치면 새로운 Short-lived Access Token을 얻게 되며, 필요한 경우 이를 다시 Long-lived token로 갱신하시면 됩니다.

이 과정을 통해 생성되는 Access Token은 완전히 새로운 토큰입니다. 때때로 변경 전과 변경 후 Access Token이 동일한 경우도 있지만 실제로 같은 Access Token이 아닙니다.

페이스북 iOS, Android SDK에서는 기본적으로 Long-lived Token이 사용됩니다.

Page Access Token 확장하기

manage_Pages 권한을 가진 Admin 사용자로부터 Page Access Token을 얻을 수 있습니다. 이 때 Admin관리자의 User Access Token이 Short-lived Access Token이라면 이로부터 생성된 Page Access Token도 Short-lived Access Token입니다.

만약 Admin 사용자의 Token이 Long-live Access Token이라면 이를 통해 생성된 Page Access Token은 만료일을 가지지 않게 됩니다.

오류 처리하기

Access Token을 발급하면 Token과 더불어 만료일 정보도 전달되게 됩니다. 이러한 정보를 통해 Access Token이 만료되지 않도록 관리해야 합니다. 만약 만료된 Access Token을 바탕으로 요청을 하게 되면 해당 요청이 만료되었다는 에러를 받게 됩니다. 또한 보안과 관련된 이유로 만료일 이전에 만료될 수 있으므로 이에 대한 고려가 필요합니다.

이러한 오류는 HTT 400 (Bad Request) 상태 코드와 함께 오류 코드와 오류 내용이 JSON형태로 전달됩니다. 실제 전달되는 오류와 오류코드 정보는 다음 링크에서 확인하실 수 있습니다. (https://developers.facebook.com/docs/graph-api/using-graph-api/#errors)

Access Token이 만료된 경우

{
	"error": 
	{
		"message": "Error validating access token: Session has expired at unix
		time SOME_TIME. The current unix time is SOME_TIME.",
		"type": "OAuthException",
		"code": 190
	}
}

사용자가 로그아웃 하거나 비밀번호를 변경하여 Access Token이 더이상 유효하지 않게 된 경우

{
	"error": 
	{
		"message": "Error validating access token: The session is invalid
		because the user logged out.",
		"type": "OAuthException",
		"code": 190
	}
}

위와 같이 Access Token이 유효하지 않게 되면, 사용자를 다시 로그인 과정을 진행하게 하여 Access Token을 갱신해야 합니다.

Access Token의 크기

Access Token의 크기는 페이스북의 정책에 따라 변경될 수 있습니다. Access Token에 포함된 정보와 Encoding하는 방법 등의 변경에 의해서 Access Token의 길이가 변경될 수 있으므로 Access Token을 저장할 경우 길이에 대한 제한을 하지 않는 것이 좋습니다.