Grato por sua visita. Neste momento esta página está apenas disponível em inglês.
 Using redirect authentication experience | Amazon Pay

Using redirect authentication experience

In some cases, like when your buyers are using a mobile device, you want to redirect buyers to the Amazon authentication page within the same window, rather than presenting the buyer with a pop-up window.

This section covers the following information:

  • Procedure - The changes you need to make to your website to enable a redirect authentication.
  • Cross-site request forgery - How to prevent attackers from using a buyer's web browser to perform unwanted actions after the buyer is authenticated.
  • When a buyer denies consent - How to handle cases during authentication when the buyer declines to grant you access to their Amazon Pay profile information.

Changes you need to make to your website to enable redirect authentication

  1. Whitelist the pages your buyers will login from and be returned to by updating allowed Javascript origins and allowed return URLs. Note: "Allowed Javascript Origins" and "Allowed Return URLs" can be a link. For details, see Adding allowed javaScript origins or allowed return URLs.
  2. In the button widget, set the popup parameter to false.
  3. On the webpage that you want to redirect users back to, add JavaScript code in your <header> section to retrieve the access token that is required by the widgets.
    The sample code below shows JavaScript code for retrieving the access token.
     
    <script type='text/javascript'>
      function getURLParameter(name, source) {
        return decodeURIComponent((new RegExp('[?|&|#]' + name + '=' +
          '([^&]+?)(&|#|;|$)').exec(source) || [,""])[1].replace(/\+/g,
          ' ')) || null;
      }
    
      var accessToken = getURLParameter("access_token", location.hash);
    
      if (typeof accessToken === 'string' && accessToken.match(/^Atza/)) {
        document.cookie = "amazon_Login_accessToken=" + accessToken +
          ";secure";
      }
    
      window.onAmazonLoginReady = function () {
        amazon.Login.setClientId('amzn1.application-oa2-
        client.d607ddd4957c44019e73086bc7cSAMPLE');
          
        amazon.Login.setUseCookie(true);
      };
    
    </script>
    
    <script src='https://static-na.payments-amazon.com/OffAmazonPayments/us/
      sandbox/js/Widgets.js?sellerId=YOUR_SELLER_ID'>
    </script>
        
    
  4. Delete the widget cookie. When you use the Login with Amazon SDK for JavaScript, you can call the amazon.Login.logout method to delete any cached tokens. If you are using redirect authentication, also delete the cookie used by the AddressBook and Wallet widgets. Doing so ensures that subsequent calls to amazon.Login.authorize present the login screen by default.
    The following code sample uses the amazon.Login.logout method from the Login with Amazon SDK for JavaScript to delete cached tokens.
     
    <script type="text/javascript">
      document.getElementById('Logout').onclick = function() {
        amazon.Login.logout();
        document.cookie = "amazon_Login_accessToken=; 
          expires=Thu, 01 Jan 1970 00:00:00 GMT";
        window.location = 'REDIRECT_URL';
      };
    </script>
        
    

Cross-site request forgery

Cross-site request forgery happens when an attacker tricks a user into clicking a malicious link, where the link goes to a site where the user is authenticated. Any commands embedded in the malicious link might be executed automatically because the user is already authenticated on the site, so the user does not see a login screen or any other evidence of malicious activity. In the case of Login with Amazon, cross-site request forgery could be used to mimic a client or an authentication server.

When a client registers for Login with Amazon, they are assigned a client identifier (client_id) and a client secret (client_secret). The client verifies their identity by using the client_id and client_secret parameters in access token requests (these values would have to be forged by an attacker).

Login with Amazon also uses the State parameter to prevent cross-site request forgery. The client sets the value of the State parameter when it initiates an authorization request. Unlike the client_id and client_secret values, the State value can and should be different for each authorization request. The authorization server returns the same value when communicating with the client to deliver authorization codes and access tokens. If the State parameter doesn't match the value from the initial call, the communication should be ignored. For more information about the state parameter and its use, see Cross-site request forgery in the Login with Amazon documentation.

Calculating the State parameter

Clients can calculate the State value in any way they choose, but you should ensure that the value is secure from forgery. Login with Amazon recommends using Hash-based Message Authentication Code (HMAC) to calculate State values. HMAC methodology is detailed in RFC2104. For more information, see RFC2104.

To calculate a State value using this method, you must have a csrf_secret known only to the client and an authenticator message. The State value is calculated as HMAC(csrf_secret, authenticator). The authenticator value is then stored by the client.

When the state is returned by an authorization response, you can verify the state by retrieving the authenticator value and running the HMAC(csrf_secret, authenticator) calculation again. If the values do not match, you should ignore the authorization response.

The first time a buyer signs in and is authenticated on your website, they must give their consent to share their Amazon Pay profile information with you. If, during a redirect authentication, a buyer clicks the Cancel button on the consent screen and denies you consent, Amazon Pay forwards the buyer to the redirect URL, but instead of passing back an AccessToken, an error description is returned.

Note that an AccessToken is returned in the URL Fragment, where an error description is returned via a query string. Before rendering the redirect URL, you need to check for a query string with an error description and, if found, redirect the buyer to the page where the login process was initiated.

The following example shows a URL fragment where the buyer gave their consent to share their Amazon Pay profile information with you.

 
https://www.sample-store.com/amazonReturn.html#access_token=Atza|IQEBLjAsAhQWkVKdr_uRdbW7QpkRY8LIxgQIUczBscZcklUALuEd651Nd1_ulkU8WiXq7ZmzcAlp9lZ6Vf_pwaAGL1eVBVKx2x74TmQJkdZiaMdVOT99M34V3HvWOtPgWOxUqIgcgBoJ4R1LenaOIg9ZMyU_YO0Ma4Xvsqg7R5fTozyZaVVv5PwGNRhrQq32RFU7x4Jr6riKsR1AWFoSW3i1arpDCmbF_P3CgVf5X7Y3Dmdkci7JTestAccessToken&token_type=bearer&expires_in=3600&scope=profile+payments:widget
    

The following example shows an error description returned in the query string when a buyer declines to share their profile information with you.

 
https://www.sample-store.com/amazonReturn.html?error_description=Access+not+permitted.&error=access_denied