dev:app_authentication_example
Differences
This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revision | ||
dev:app_authentication_example [2016/04/18 15:57] – su | dev:app_authentication_example [2017/11/21 16:46] (current) – su | ||
---|---|---|---|
Line 2: | Line 2: | ||
All Apps must authenticate through the App Store OAuth2 Authorization Server. | All Apps must authenticate through the App Store OAuth2 Authorization Server. | ||
+ | |||
+ | [https:// | ||
+ | |||
+ | OAuth is used extensively on the web already: if you have ever logged into a 3rd party web site using your Facebook, Google, or LinkedIn account, you have already used OAuth. | ||
+ | |||
+ | The App Store also has its own OAuth service, to allow applications such as the Valve Signature Tool to log users in via the App Store, and to allow those applications to charge users for application usage. | ||
Below is a simple example illustrating the [[https:// | Below is a simple example illustrating the [[https:// | ||
Line 8: | 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. | ||
- | == 1.1 Redirect URIs == | + | === 1.1 Redirect URIs === |
- | When registering your App, you will be 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:// | + | 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:// |
Since the HTTP request carries secure information, | Since the HTTP request carries secure information, | ||
- | == 1.2 Application Id and Secret Key == | + | === 1.2 Application Id and Secret Key === |
Upon App registration, | Upon App registration, | ||
Line 23: | 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, | 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, | ||
- | == 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 " | 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 " | ||
+ | === 1.4 Scopes === | ||
- | === 2. Authorization === | + | 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. |
+ | |||
+ | When a user is prompted to log into a web site via an OAuth service, the scopes are explained to the user so that they can decide whether or not to proceed. | ||
+ | |||
+ | The App Store' | ||
+ | |||
+ | * **UserInfo** - used to allow an application to access information about a user | ||
+ | * **AccountDebit** - used to allow an application to bill a user for usage | ||
+ | * **DataRead** - used to allow an application to access a user's App Store Connect data | ||
+ | |||
+ | Applications are not obliged to ask for access to all of the above scopes; they can pick and choose the scopes that they require. | ||
+ | |||
+ | |||
+ | ==== 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 75: | Line 97: | ||
</ | </ | ||
- | === 3. Authenticated Requests === | + | ==== 3. Authenticated Requests ==== |
+ | |||
+ | Now that you have an access token, you can make requests to the App Store API. | ||
+ | |||
+ | === 3.1 Access Tokens === | ||
+ | |||
+ | When an application logs a user in via an OAuth service, they receive an access token for the user, also known as a bearer token, as well as information about when the access token expires, and (possibly) a refresh token that can be used to retrieve a new access token when the old one expires, instead of requiring the user to explicitly log into the application again. | ||
+ | |||
+ | The token contains embedded information about the user, and is signed and encrypted by the OAuth service so that only the machine that issued the token can authenticate requests made using the token. | ||
+ | |||
+ | To authenticate requests made to the App Store API, the calling application must include a valid access token in the HTTP headers of the request. | ||
- | 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: | ||
< | < | ||
- | curl -H "Authorization: | + | var request = new HttpRequestMessage(HttpMethod.Get, |
- | https:// | + | request.Authorization = new AuthenticationHeaderValue(" |
+ | |||
+ | var response = await httpClient.SendAsync(request, | ||
+ | ... | ||
</ | </ | ||
dev/app_authentication_example.1460995035.txt.gz · Last modified: 2016/04/18 15:57 by su