App Store Wiki

User Tools

Site Tools

Trace:
dev:app_authentication_example

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revisionBoth sides next revision
dev:app_authentication_example [2016/04/21 17:01] – sudev:app_authentication_example [2016/04/21 17:04] – su
Line 14: Line 14:
  
  
-=== 1. Registering your Web App ===+==== 1. Registering your Web App ====
  
 In order to use the App Store OAuth service, an application must be registered with the App Store.  In order to use the App Store OAuth service, an application must be registered with the App Store. 
  
-== 1.1 Redirect URIs ==+=== 1.1 Redirect URIs ===
  
 When registering your App, you are asked to provide one or more valid Redirect URIs. The Authorization Server will only respond to HTTP requests from registered URIs. This helps prevent [[https://en.wikipedia.org/wiki/Man-in-the-middle_attack|Man-in-the-Middle attacks]]. When registering your App, you are asked to provide one or more valid Redirect URIs. The Authorization Server will only respond to HTTP requests from registered URIs. This helps prevent [[https://en.wikipedia.org/wiki/Man-in-the-middle_attack|Man-in-the-Middle attacks]].
Line 25: Line 25:
  
  
-== 1.2 Application Id and Secret Key ==+=== 1.2 Application Id and Secret Key ===
  
 Upon App registration, you are assigned an Application Id and Secret Key. The Application Id is considered public information. It composes part of the URL request to the App Store Authorization Server and can easily be identified by the user. Upon App registration, you are assigned an Application Id and Secret Key. The Application Id is considered public information. It composes part of the URL request to the App Store Authorization Server and can easily be identified by the user.
Line 31: Line 31:
 The Secret Key, however, **must** remain confidential. It should only be used server-side (i.e not in the web-browsing client). If a deployed app cannot keep the secret confidential, then an alternative grant flow must be considered. The Secret Key, however, **must** remain confidential. It should only be used server-side (i.e not in the web-browsing client). If a deployed app cannot keep the secret confidential, then an alternative grant flow must be considered.
  
-== 1.3 Application Status ==+=== 1.3 Application Status ===
  
 Your registered App is given a status. Be sure this is not active until you are satisfied it is fully tested. Once an App is "Active" attempts debit requests are treated as genuine and transactions are processed. Your registered App is given a status. Be sure this is not active until you are satisfied it is fully tested. Once an App is "Active" attempts debit requests are treated as genuine and transactions are processed.
  
-== 1.4 Scopes ==+=== 1.4 Scopes ===
  
 OAuth permissions are known as scopes, and are used to control which information about a user an application can access, or restrict the actions that the application can perform on behalf of a user. OAuth permissions are known as scopes, and are used to control which information about a user an application can access, or restrict the actions that the application can perform on behalf of a user.
Line 50: Line 50:
  
  
-=== 2. Authorization ===+==== 2. Authorization ====
  
 In your App, create a "Log In" link sending the user to: In your App, create a "Log In" link sending the user to:
Line 97: Line 97:
 </code> </code>
  
-=== 3. Authenticated Requests ===+==== 3. Authenticated Requests ====
  
 Now that you have an access token, you can make requests to the App Store API. You can make an API request using cURL as follows: Now that you have an access token, you can make requests to the App Store API. You can make an API request using cURL as follows:
dev/app_authentication_example.txt · Last modified: 2017/11/21 16:46 by su