官术网_书友最值得收藏!

How it works...

To start using OAuth 2.0's protected resources, before requesting the access_token through the user's grant, we registered the application client-implicit through the OAuth 2.0 Provider (Facebook). The responsibility of maintaining the client's data belongs to the Authorization Server. In using Facebook the boundaries between the Authorization Server and the Resource Server is not so clear. The most important thing to understand here is that Facebook is acting as an OAuth 2.0 Provider.

As per the specifications, we have performed the three important steps in client registration process, which was to choose the client type, register the redirection URI, and enter the application's information.

By registering the application, we've received the client_id and client_secret, but as we are using the Implicit grant flow the client_secret won't be needed. That's because this first recipe presents an application which runs directly on the web browser. So, there is no way to safely protect the client_secret. When not using the client_secret we must try not to expose the received access_token that comes with the URL fragment after the user grants permission to access her resources. Another measure to help the application to not expose the access token was to clear the URL fragment.

Another measure that might be applied is to not use any external JavaScript code as such that was used to send usage metrics (in such a way that the access_token could be sent to the external service).

After the registration process we got into the code to effectively interact with the Facebook Graph API, which at the time of this writing was version 2.9. Facebook offers two ways to log a user with a valid account:

  • By using the Facebook SDK
  • By manually building a login flow

To make the OAuth 2.0 usage explicit, this recipe was written by manually building a login flow. So to start the process of user's authentication and authorization, the client-implicit application builds the URL for the Authorization Server manually as follows:

var request_endpoint = auth_endpoint + "?" + 
   "response_type=" + response_type + "&" + 
   "client_id=" + client_id + "&" + 
   "redirect_uri=" + encodeURI(redirect_uri) + "&" + 
   "scope=" + encodeURI(scope); 
 
window.location.href = request_endpoint; 

After simply redirecting the user to the Authorization Server's endpoint, the flow is transferred to Facebook, which authenticates the user if needed, and the user authorizes whether or not the client application can make use of its resources. Once the user authorizes the client, she is redirected back to the registered redirection URI, which in our case was http://localhost:8080/callback.

When receiving the access_token all we need to do is extract the token from the URL fragment and start using the Facebook Graph API.

主站蜘蛛池模板: 甘孜县| 株洲县| 收藏| 黄浦区| 克山县| 城市| 慈溪市| 博罗县| 海淀区| 桑植县| 黎城县| 察雅县| 闽侯县| 芒康县| 绥中县| 广宁县| 罗甸县| 黎城县| 杭锦后旗| 普兰县| 东城区| 洪洞县| 新巴尔虎左旗| 丰原市| 明光市| 屏山县| 昭苏县| 正定县| 牙克石市| 新民市| 青海省| 西华县| 利川市| 涟源市| 永平县| 清镇市| 花垣县| 濉溪县| 大化| 类乌齐县| 东海县|