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

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.

主站蜘蛛池模板: 孟津县| 姚安县| 伊川县| 沧源| 得荣县| 荆州市| 满洲里市| 苗栗市| 获嘉县| 柏乡县| 万盛区| 和林格尔县| 榆树市| 汨罗市| 曲麻莱县| 卢湾区| 平度市| 信阳市| 华阴市| 苍梧县| 会理县| 阳泉市| 东山县| 乐昌市| 扶绥县| 郓城县| 汶上县| 惠东县| 梅州市| 上犹县| 泰宁县| 运城市| 丹东市| 南皮县| 荆门市| 潼南县| 石首市| 阜宁县| 福泉市| 丹江口市| 绍兴县|