- OAuth 2.0 Cookbook
- Adolfo Eloy Nascimento
- 443字
- 2021-07-08 09:35:02
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.
- JS全書:JavaScript Web前端開發(fā)指南
- Python機器學習編程與實戰(zhàn)
- Bootstrap 4:Responsive Web Design
- VMware虛擬化技術(shù)
- Getting Started with Gulp
- 青少年信息學競賽
- Java實戰(zhàn)(第2版)
- AutoCAD 2009實訓指導
- Apache Camel Developer's Cookbook
- App Inventor 2 Essentials
- Instant Zurb Foundation 4
- Backbone.js Testing
- Java EE Web應用開發(fā)基礎
- Oracle Database XE 11gR2 Jump Start Guide
- Mastering ArcGIS Server Development with JavaScript