To exchange the authorization code for an access token, the app makes a POST request to the service’s token endpoint. Exchange the authorization code for an access token This helps ensure that you only exchange authorization codes that you requested, preventing attackers from redirecting to your callback URL with arbitrary or stolen authorization codes. Your app should compare the state with the state it created in the initial request. If you include a “state” parameter in the initial authorization URL, the service will return it to you after the user authorizes your app. The app then needs to exchange this authorization code for an access token. If they allow the request, they will be redirected back to the redirect URL specified along with an authorization code in the query string. Example Authorization RequestĪfter the user is taken to the service and sees the request, they will either allow or deny the request. Upon being directed to the auth server, the user sees the authorization request. Connect Your Account The user approves the request The app initiates the flow by crafting a URL containing ID, and optionally scope and state. The app initiates the authorization request The following step-by-step example illustrates using the authorization grant type for single-page apps. Note that the lack of using a client secret means that using the state parameter is even more important for single-page apps. This also serves as a CSRF protection mechanism. This may be used to indicate what action in the app to perform after authorization is complete, for example, indicating which of your app’s pages to redirect to after authorization.
This gives your app a chance to persist data between the user being directed to the authorization server and back again, such as using the state parameter as a session key. When the user is redirected back to your app, whatever value you include as the state will also be included in the redirect. The state parameter serves two functions. The values will depend on the particular service. Include one or more scope values to request additional levels of access. This must match the redirect URL that you have previously registered with the service. This is the URL to which you want the user to be redirected after the authorization is complete. The redirect_uri is optional in the spec, but some services require it. You will have received a client_id when first registering your app with the service. The client_id is the identifier for your app. Response_type is set to code indicating that you want an authorization code as the response. The following parameters are used to make the authorization request. If the user clicks “approve”, the server will redirect back to the website, with an authorization code and the state value in the URL query string. &redirect_uri=https%3A%2F%%2FauthĪfter the user visits the authorization page, the service shows the user an explanation of the request, including application name, scope, etc. The authorization URL is usually in a format such as: This is accomplished by creating an authorization request link for the user to click on. The first step of the web flow is to request authorization from the user. The code itself is obtained from the authorization server where the user gets a chance to see what the information the client is requesting, and approve or deny the request.
The authorization code is a temporary code that the client will exchange for an access token. The user’s browser communicates directly with the API server Authorization In this case, the app’s server never makes API requests to the service, since everything is handled directly in the browser. After first downloading the Javascript and HTML source code from the client, the browser then makes direct API requests to the service. The diagram below illustrates an example where the user interacts with their browser, which in turn makes API requests directly to the service. This has a number of security issues as described Implicit Flow and should no longer be used.
0 kommentar(er)
