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

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.

主站蜘蛛池模板: 青河县| 巨鹿县| 博湖县| 巴彦县| 特克斯县| 马尔康县| 琼中| 盈江县| 安远县| 红原县| 灌云县| 蒙自县| 横峰县| 河北区| 大冶市| 日土县| 大化| 南召县| 游戏| 鄢陵县| 湾仔区| 通化县| 贵港市| 甘谷县| 耿马| 永宁县| 彭水| 关岭| 平昌县| 杂多县| 湖南省| 山丹县| 遵义县| 长寿区| 南宁市| 湖南省| 嘉兴市| 乌海市| 芒康县| 巴东县| 台南市|