반응형

Authentication

Core Concepts > Authentication

원문 : http://developers.facebook.com/docs/authentication/

flow : 흐름이 어울릴 때도 있고... 방법/방식이라고 하면 어울릴 때도 있고...;;;


페이스북 플랫폼은 인증과 권한에 대해서 OAuth 2.0 protocol 을 사용합니다. 페이스북은 여러분의 웹사이트, 모바일, 그리고 데스크탑 앱에서 사용할 수 있는 서로 다른 개수의 OAuth flows 를 지원합니다.

이문서는 각각의 OAuth flows를 지원하기 위해 페이스북이 사용하는 서로 다른 기술적흐름을 설명합니다. 이문서에서 예제는 서버사이드 프로그래밍에 대해서는 PHP를 사용하고 클라이언트 코드에 대해서는 HTML/JavaScript를 사용합니다. 이러한 예제들은 매우 직선적(분명하고)이고 쉽게 다른 개발언어로 전환할 수 있습니다. 

User Login

페이스북 플랫폼은 서로다른 2가지의 OAuth 2.0 flows를 지원합니다. 하나는 server-side(명세서에 인증코드흐름으로 알려진 것) 이고 다른 하나는 client-side(내재적 흐름으로 알려진 것) 입니다. 서버측 방식은 여러분의 웹 서버로부터 Graph API를 호출하려고 할 때마다 사용되어집니다. 클라이언트측 방식은 클라이언트로부터 Graph API 호출을 만들 때마다 사용되어지는데, 마치 웹 브라우저나 모바일 또는 데스크탑에서 자바스크립트가 실행중인 것과 같습니다. 

여러분이 사용하는 흐름에 상관없이, OAuth 2.0 에 대한 구현은 3가지 다른 단계를 포함합니다. : 사용자 인증, 앱권한 그리고 앱인증 입니다. 사용자 인증은 일반 사용자를 확인하는 것을 말합니다. 앱권한은 여러분의 앱의 사용자들이 여러분의 앱에 그들이 제공할 수 있는 데이터와 능력을 정확하게 아는 지(권한을 행사할 수 있는지)를 확인하는 것입니다. 앱인증은 사용자가 당신의 앱에 다른 사람의 것이 아니라 본인들의 정보를 주는지를 확인 하는 것입니다. 이 단계들이 완료됬을 때, 여러분의 앱에 access token 이 발행될 것이고 사용자 정보에 접근할 수 있을 것이며 사용자에 대해 행동을 수행할 수 있을 것입니다.

Server-side Flow

사용자 인증과 앱권한은 사용자에게 OAuth 대화창으로 보내짐으로써 같은 시간(동시에)에 처리되어 집니다. 이 대화창을 호출했을 때, 여러분은 Developer App 에서 여러분의 앱을 생성했 만들어진 여러분의 앱에 대한 아이디를 보내야만 하고(the client_id parameter) 앱인증이 끝났을 때 돌아갈 사용자 브라우저의 URL도 보내야만 합니다(the redirect_uri). redirect_uri 는 여러분이 개발자 앱의 요약 탭의 웹사이트 섹션의 요약부분에 명시한 사이트 URL의 경로에 있어야만 합니다. 주의하셈, 여러분의 redirect_uri는 redirector가 될 수 없습니다.
https://www.facebook.com/dialog/oauth?
     client_id=YOUR_APP_ID&redirect_uri=YOUR_URL

좀 더 많은 정보를 원한다면 아래의 Alternate Redirect URIs section 을 보십시요.

만약 사용자가 이미 로그인 했다면, 페이스북은 사용자의 브라우저에 저장한 로그인 쿠키를 검증할 것이고 그 사용자를 인증할 것입니다. 만약에 사용자가 로그인하지 않았다면, 사용자들은 그들의 신용정보를 입력해야 할 것입니다.


페이스북이 성공적으로 사용자를 인증했을 때, OAuth 대화창은 앱에 권한을 주려고 할 것입니다.


기본적으로, 사용자가 앱에 접근하려면 권한을 받기 위해 이용가능한 정책 또는 페이스북에 대한 기본적인 정보로 질의를 받습니다. 만약에 여러분의 앱이 좀 더 많은 기본적인 정보들을 필요로 한다면, 여러분은 사용자로부터의 특정한 권한을 요청해야만 합니다. 이것은 OAuth 대화창에 요청되는 권한을 콤마로 분리된 목록으로 scope 매개변수에 추가함으로써 이루어집니다. 아래의 예는 사용자의 이메일 주소와 그들의 뉴스피드에 접근하려면 어떻게 질의해야하는지를 보여줍니다.

https://www.facebook.com/dialog/oauth?
     client_id=YOUR_APP_ID&redirect_uri=YOUR_URL&scope=email,read_stream

아래 대화창의 결과는 사용자들이 인증받은 후에 보여집니다. :


승인의 모든 목록은 페이스북의 permissions reference 에서 이용할 수 있습니다. 여러분의 앱으로의 요청하는승인의 수와 그 요청들을 승인하는 것을 허락하는 사용자들의 숫자 사이에 강한 반대의 상관관계가 있습니다.
당신이 질의하려는 승인의 최대 수에 대해서, 그것에 권한을 부여할 사용자의 수가 매우 적을 수 있습니다; 그래서 페이스북은 여러분이 앱을 위해 절대적으로 필요로하는 승인에 대해서만 요청하기를 권장합니다.

만약 사용자가 허가안함을 누른다면, 여러분의 앱은 승인되지 않을 것입니다. OAuth 대화창은 여러분이 보낸 오류정보를 포함한 redirect_uri 매개변수의 URL로 사용자의 브라우저에 재전송(redirect) (HTTP 302를 통해) 할 것입니다. 

http://YOUR_URL?error_reason=user_denied&
     error=access_denied&error_description=The+user+denied+your+request.
만약 사용자가 허가함을 누른다면, 여러분의 앱은 승인될 것입니다. OAuth 대화창은 여러분이 보낸 인증코드를 포함한 redirect_uri 매개변수의 URL로 사용자의 브라우저에 재전송(redirect) (HTTP 302를 통해) 할 것입니다. 
http://YOUR_URL?code=A_CODE_GENERATED_BY_SERVER

손으로 쓴 이 코드와 함께, 앱인증, API 호출을 위해 필요한 access token 을 얻기 위해서, 여러분은 다음 단계로 나아갈 수 있을 것입니다.

여러분의 앱을 인증하기 위해서, 여러분은 인증코드와 app secret을 https://graph.facebook.com/oauth/access_token. 에 redirect_uri가 붙은 Graph API 끝에 붙여서 보내야만 합니다.  app secret은 Developer App 에서부터 이용가능하고 어느누구에게 공유되어지거나 당신이 배포하는 어떤 코드에 포함되서는 안 됩니다(여러분은 이 이나리오를 클라이언트측 흐름에서만 사용해야 합니다).

https://graph.facebook.com/oauth/access_token?
     client_id=YOUR_APP_ID&redirect_uri=YOUR_URL&
     client_secret=YOUR_APP_SECRET&code=THE_CODE_FROM_ABOVE

만약 당신의 앱이 성공적으로 인증되었고 사용자의 권한코드가 유효한 것이라면, 그 인증서버는  access token을 반환할 것입니다. 


추가적으로 access token(access_token 매개변수)에 대해서, 응답이 토큰이 만료될 때까지 수초동안 토큰을 가지고 있습니다(expires 매개변수). 토큰이 만료됐을 때, 비록 사용자가 여러분의 앱에 대한 권한을 가지고 있더라도, 여러분은 새로운 코드와 access_token을 생성하는 단계를 재실행 해야 할 필요가 있으며, 그것들은 다시 시작될 수 없습니다. 만약 여러분이 무한한 만료시간의 access token을 원한다면(아마 사용자들이 당신의 앱을 사용한 후에 행동이 있다면), 당신은 offline_access 승인을 요청할 수 있습니다.

여기에는 앱에 대한 인증 이슈가 있는데, 권한 서버가 HTTP 400 을 알리고 응답의 내부에 오류를 반환할 것입니다. 

{
   "error": {
      "type": "OAuthException",
      "message": "Error validating verification code."
   }
}
아래의 그림은 서버측 흐름을 통한 HTTP 호출에 대해 그렸습니다.:



이어지는 PHP 예제는 단독으로 실행가능한 CSRF protection 에 대한 서버측 흐름을 설명합니다.:
 <?php 

   $app_id = "YOUR_APP_ID";
   $app_secret = "YOUR_APP_SECRET";
   $my_url = "YOUR_URL";

   session_start();
   $code = $_REQUEST["code"];

   if(empty($code)) {
     $_SESSION['state'] = md5(uniqid(rand(), TRUE)); //CSRF protection
     $dialog_url = "http://www.facebook.com/dialog/oauth?client_id=" 
       . $app_id . "&redirect_uri=" . urlencode($my_url) . "&state="
       . $_SESSION['state'];

     echo("<script> top.location.href='" . $dialog_url . "'</script>");
   }

   if($_REQUEST['state'] == $_SESSION['state']) {
     $token_url = "https://graph.facebook.com/oauth/access_token?"
       . "client_id=" . $app_id . "&redirect_uri=" . urlencode($my_url)
       . "&client_secret=" . $app_secret . "&code=" . $code;

     $response = @file_get_contents($token_url);
     $params = null;
     parse_str($response, $params);

     $graph_url = "https://graph.facebook.com/me?access_token=" 
       . $params['access_token'];

     $user = json_decode(file_get_contents($graph_url));
     echo("Hello " . $user->name);
   }
   else {
     echo("The state does not match. You may be a victim of CSRF.");
   }

 ?>

Client-Side Flow

클라이언트측 흐름은 사용자 인증과 앱의 권한에 대해서 OAuth 대화창을 사용합니다. 오직 다른 한 가지는 response-type 매개변수의 token 값을 명시해야만 한다는 것입니다.:
https://www.facebook.com/dialog/oauth?
     client_id=YOUR_APP_ID&redirect_uri=YOUR_URL&response_type=token

서버측 흐름에 따라, 여러분은 scope 매개변수를 사용해서 추가적인 승인을 요청할 수 있습니다.:

https://www.facebook.com/dialog/oauth?
     client_id=YOUR_APP_ID&redirect_uri=YOUR_URL&scope=email,read_stream&
     response_type=token

사용자가 인증되고 앱에 대한 권한을 받았을 때, 브라우저는 redirect_uri를 리다이렉트 하겠지만 서버측흐름에서는 권한 코드(code 매개변수를 통해서)를 전달하는 대신, redirect_uri는 URI 요소에 access token을 전달할 것입니다.(#access_token).:

http://YOUR_URL#access_token=166942940015970%7C2.sa0&expires_in=64090

access token 이 URI 요소로 전달되어지기 때문에, 클라이언트측 코드(브라우저에서 실행되는 자바스크립트나 웹을 제어하기위해 호스팅하는 데스크탑 코드)는 token을 추출할 수 있습니다. 앱인증은 개발자 앱의 Site URL로 설정되어 있는 같은 경로의 redirect_uri가  다양하게 처리되어 집니다. 좀더 많은 정보를 보려면  Alternate Redirect URIs 영역을 보십시요.

아래의 그림은 클라이언트측 흐름을 통해 HTTP 호출을 만든는 것을 나타냅니다. :


이어지는 HTML/JavasScript 예제는 자기스스로 실행할 수 있는 예제들을 보여줍니다. :

 <html> 
   <head> 
     <title>Client Flow Example</title> 
   </head> 
   <body> 
   <script> 
     function displayUser(user) {
       var userName = document.getElementById('userName');
       var greetingText = document.createTextNode('Greetings, '
         + user.name + '.');
   userName.appendChild(greetingText);
     }

     var appID = "YOUR_APP_ID";
     if (window.location.hash.length == 0) {
       var path = 'https://www.facebook.com/dialog/oauth?';
   var queryParams = ['client_id=' + appID,
     'redirect_uri=' + window.location,
     'response_type=token'];
   var query = queryParams.join('&');
   var url = path + query;
   window.open(url);
     } else {
       var accessToken = window.location.hash.substring(1);
       var path = "https://graph.facebook.com/me?";
   var queryParams = [accessToken, 'callback=displayUser'];
   var query = queryParams.join('&');
   var url = path + query;

   // use jsonp to call the graph
       var script = document.createElement('script');
       script.src = url;
       document.body.appendChild(script);        
     }
   </script> 
   <p id="userName"></p> 
   </body> 
  </html>

Using the Acces Token

여러분은  Graph API 요청(그리고 Legacy REST API)에 access_token 매개변수 를 추가함으로써 Graph API를 유효한 access token으로 호출할 수 있습니다. :

 https://graph.facebook.com/me?access_token=ACCESS_TOKEN 

만약에 사용자가 패스워드를 변경했다면, access token 은 만료되거나 그 사용자는 App Dashboard 에서 당신의 앱에 대한 권한이 해제될 것이고, Graph API HTTP 400 를 발행할 것이고 응답으로 오류를 반환할 것입니다. :

{
   "error": {
      "type": "OAuthException",
      "message": "Error validating access token."
   }
}  

당신의 앱은 이러한 오류가 발생했을경우 적절한 흐름을 재수행함으로서 새로운 access token을 요청할 수 있습니다.

App Deauthorization

여러분의 앱 사용자가 App Dashboard 에서 앱을 제거하거나 뉴스피드에서 앱을 차단시키면, 당신의 앱은  Developer App 의 Deauthorize Callback URL 을 명시함으로써 알림을 받을 수 있습니다. 앱이 제거되는 동안 우리는 signed_request 인 단일 매개변수를 포함한 HTTP POST 요청을 보낼 것입니다. signed_request는 당신의 앱을 제거한 사용자의 id(UID)를 포함하고 있습니다. 당신은 이 요청에서는 사용자의 access token 을 받지 못할 것이고 모든 존재하는 사용자 access token은 자동적으로 만료될 것입니다.

Alternate Redirect URIs

redirect_uri 들이 인증 흐름에서 명시되어질 때, 사용자는 보편적으로 개발자앱의 요약탭의 기본정보부분에 여러분이 명시한 Site URL 경로에 대해 리다이렉트되어질 수 있습니다. 그러나 여러분은 이 행위를 덮어쓸 수 있고 개발자앱의 요약탭의 기본정보부분의 앱 도메인 필드의 각각의 도메인 이름을 명시함으로써 하나 또는 그 이상의 관련되거나 하위의 도메인들을 리다이렉트 할 수 있습니다.:


예를 들어, 여러분의 앱에 추가적인 앱 도메인들을 명시하는 것은 서버부하의 지리적 분산을 위해서 다른 서버들로 사용자들을 리다이렉트 하는 것은 유용합니다.

그러나 redirect_uri는 redirector 일 수 없다는 것을 명심하십시요.

Logout 

여러분은 아래의 URL을 사용함으로써 사용자들의 페이스북 세션을 벗어나는 사용자 로그를 남길 수 있습니다.:
https://www.facebook.com/logout.php?next=YOUR_URL&access_token=ACCESS_TOKEN 

Developer App 의 정의에 따라 YOUR_URL 은 여러분 사이트 도메인의 URL이어야만 합니다.



App Login

추가적인 사용자 로그인은, 페이스북 플랫폼은 OAuth 2.0 클라이언트 신용 흐름을 사용하는 App Login을 제공합니다. App Login은 여러분이 앱에 대한 다양한 관리적 활동을 수행하는 것을 허용하는데, Insights 데이터를 가져오거나 요청을 승인하는 것들을 의미합니다. app access token 을 요구하는 Graph API 를 호출하는 것은 명백하게 API 문서에 표시되어 있습니다.

당신은 https://graph.facebook.com/oauth/access_token 의 Graph API token 끝에 app id, app secret 그리고 grant_type 매개변수의 client_credentials를 명시함으로써 app access token을 얻을 수 있습니다. app id 와 app secret은 둘 다 당신의 앱이 Developer App 에서 만들어졌을 때 생성됩니다.
https://graph.facebook.com/oauth/access_token?client_id=YOUR_APP_ID&client_secret=YOUR_APP_SECRET&grant_type=client_credentials

위의 URL에 대한 HTTP GET 요청을 보내는 것은 그 응답의 내부에 access_token을 반환할 것입니다.:


그리고 여러분은 Graph API(App Insights 처럼) 의 특정한 부분을 앱이 호출할 때 이 access token을 사용할 것입니다.:

https://graph.facebook.com/YOUR_APP_ID/insights?access_token=TOKEN_FROM_ABOVE


Page Login

페이스북 페이지는 사용자와 앱로그인 에 대해서 약간 다른 흐름을 따릅니다. 모든 페이지는 하나 또는 그 이상의 관리자를 가지는데 관리자는 페이지에 대해서 특별히 허가된 운영을 수행할 수 있습니다. 여러분의 앱에 대해 이러한 특별히 허가된 운영을 수행하기 위해서, 사용자는 당신의 앱에 manage_pages 승인을 부여받아야만 합니다.:
https://www.facebook.com/dialog/oauth?client_id=YOUR_APP_ID&redirect_uri=YOUR_URL&scope=manage_pages&response_type=token


관리자가 여러분의 앱에 이 승인을 부여했을 때, 당신은 User Graph API 의 계정연결에 접근할 수 있습니다.:

https://graph.facebook.com/me/accounts?access_token=TOKEN_FROM_ABOVE

이 연결은 각페이지에 대하여 특정한 access token을 포함하는 페이지의 사용자 관리자들에 대한 모든 페이지들의 목록을 반환합니다. :


여러분은 해당 페이지의 사용자를 위해서 관리 활동을 수행하기 위한 주어진 페이지를 위해서 전달된 access token을 사용할 수 있습니다.



App Types

페이스북 플랫폼은 서로 다른 앱 형식의 OAuth 흐름 위에서 사용하기 위한 여러 가지의 방법들을 제공하는데,  WebsitesApps on Facebook.comMobile 그리고 Desktop Apps 들을 포함합니다.

Websites

페이스북의 Website Getting Started Guide 는  JavaScript SDK 과 Login Social Plugin를 사용해서 여러분의 웹사이트에 사용자 로그인을 추가하는 개요를 제공합니다.

App on Facebook.com

페이스북의 Apps on Facebook.com Getting Started Guide 는 여러분의 앱을 페이스북의 핵심경험으로 통합할 때 어떻게 사용자 로그인을 다뤄야 하는지에 대해 세세한 부분을 제공합니다.

Mobile Apps

Mobile App Getting Started Guide 는 페이스북의 mobile SDKs 를 어떻게 사용해야 하는지와 모바일에서 사용자 로그인을 수행하기위해 OAuth 대화창으로의 모바일지원부분을 부각시켜서 설명했습니다.

Desktop Apps

OAuth 2.0 구현은 특정한 데스크탑 앱 지원만을 포함하지 않습니다. 그러나, 만약 여러분의 데스크탑 앱이 웹 브라우저(대부분의 데스크탑 프레임워크 예로 .NETAIR 와 Cocoa 는 브라우저에 포함되어 지원합니다.)에 포함되어 있다면, 당신은 한 가지 수정(특정한 redirect_uri)만으로 client-side flow 를 사용할 수 있습니다. 개발자 앱에서 데스크탑 앱의 웹 서버와 인기있는 Site URL을 호스트 하기를 요구하는 것보다, 페이스북은 데스크탑 앱과 함께 사용할 수 있는 특정한 URL을 제공합니다.:https://www.facebook.com/connect/login_success.html.
 
  • 끼워진 웹 브라우저 그리고 클라이언트측 흐름을 사용하는 OAuth Dialog 로딩 (https://www.facebook.com/dialog/oauth)(i.e. response_type=token):
https://www.facebook.com/dialog/oauth?
    client_id=YOUR_APP_ID&
    redirect_uri=https://www.facebook.com/connect/login_success.html
  • 사용자가 앱으로부터 권한을 얻은 후에, 페이스북은 사용자가 돌아올 수 있게 URI 요소에 있는 redirect_uri를 access token과 함께 리다이렉트 합니다.:
https://www.facebook.com/connect/login_success.html#access_token=...
  • 이와 같은 리다이렉트를 인지하고 그 다음에 여러분의 프레임워크에 의해 제공되는 기술을 사용하는 URI읠 밖에서 access token을 읽으십시요. 


Security Considerations

Cross Site Request Forgery(CSRF)

Cross site request forgery 는 신뢰할 수 있는(인증받고 권한을가진) 웹사이트에서 사용자가 모르는 행동을 수행하는 공격을 말합니다. 이러한 공격을 막기 위해서는, 여러분은 state 매개변수에 식별자를 전달해야만 하고, 그리고나서 그 응답에 대해서 state 매개변수가 일치하는지 검증하면 됩니다. 페이스북은 페이스북 사용자 로그인을 구현하는 앱들이 이 매커니즘을 사용해서 CSRF 보호를 구현하는 것을 적극 추천합니다.

Redirect_URI

여러분은 redirect_uri 에 대해서 redirector를 명시할 수 없다는 것을 인지하십시요. OAuth 2.0 10.15 를 방문해서 더 자세하게 보세요.
 

 


반응형

+ Recent posts