The following authentication models are supported by the AT&T OAuth 2.0 Authentication Management API:

• Server Access with No Customer Context: where only the application is required to authenticate (grant_type=client_credentials).
• Server Access With Customer Context: where a web browser is acting as a user agent and providing a vehicle for user consent capture (grant_type=authorization_code).
• Note: Authentication where the user and application need to consent consists of a two-step process:
1. The first step involves getting the user's consent via a browser, and returns an "Authorization Code".
2. The second step involves the application consent PLUS passing in the "Authorization Code" and returns an OAuth token peculiar to a combination of user and application.

The two complimentary strategies that developers may consider when handling expired tokens are as follows:

1. Track the creation of the OAuth access token and use the refresh token at appropriate intervals, based on the OAuth access token creation time, in order to generate a new OAuth access token before the expires_in parameter value for the current OAuth access token has elapsed.
2. Capture the response with the HTTP Status code of 401 Unauthorized and invoke logic that retries the appropriate Get Access Token method request, as follows:
   • Generate a new OAuth access token.
   • Use the new OAuth access token to resubmit any previously failed method requests that failed due to an expired OAuth access token.

In the future, AT&T may change the default values of the expiration parameters for the OAuth access token and refresh token. So it is strongly advised that you always check the expires_in parameter value that is returned with the response to the Get Access Token method call.

The AT&T implementation is generally consistent with the OAuth 2.0 Draft 13 framework. However, there are several nuances to the AT&T implementation, such as the use of commas instead of spaces to delineate parameters within the scope variable.

For more details, see the OAuth 2.0 Authentication Management API documentation.

All of the RESTful APIs provided by AT&T use the OAuth 2.0 Authentication Management API for authentication.

The following API uses the OAuth Authorization Code:

• In-App Messaging API

The following APIs use the Application Key and Application Secret:

• Advertising API
• SMS API
• Speech API
• Enhanced WebRTC API

For further information, please see the online documentation.

No. At this time consent capture is only available to customers of the AT&T Wireless network.

The OAuth 2.0 Authentication Management API is more secure than the typical user name and password paradigm as the credentials are not stored on the mobile device.

The URL that you use in your requests must either be an exact match to the OAuth Redirect URI in your application on the AT&T Developer Program website or be an extension of that value. The Redirect URI uses the following rules:

• If the redirect_uri parameter is not present in the request, then the API Gateway uses the value of the OAuth redirect URI that you provided when you created your application.
• If the redirect_uri parameter is present in the request, then this parameter value is validated to ensure that the value of the redirect_uri parameter matches the base URI that you provided when you created your application. For example, if the URI you provided during application creation was https://yourdomain.com/abc, then the following values will match:
• • • https://yourdomain.com/abc?query=abcd
    • https://yourdomain.com/abc/def
    • https://yourdomain.com/abc
    • https://yourdomain.com/abc/def?query=abcd
• • But these values will not match:
• • • https://yourdomain2.com/abc
    • https://yourdomain.com/def

No. The custom_param flag (found in the request parameters under the Get User Authorization method) can be used to force an off-network authentication flow, but that is the only way to indicate a specific authentication flow in your app.

A customer is authenticated either using on-network or off-network authentication flows, but not both. The specific flow used is determined by the OAuth 2.0 Authentication Management API.

• On-Network Authentication: Consent can be sent from the customer's devices with a single button press.
• Off-Network Authentication: The consent process redirects the customer to a web page where a PIN must be sent from their device using SMS.

The following precautions must be observed in the handling of the Application Secret for your application in the production realm:

• The Application Secret must only be distributed to authorized and trusted personnel.
• The Application Secret must be stored on a secure server that is set up as follows:
  • Free from computer viruses and unauthorized software.
  • Only accessible by authorized personnel and software.
• The Application Secret is only intended to be used in a server-to-server API request over HTTPS and must never be transmitted or shared with applications on a user's mobile device.
• If unauthorized access to the Application Secret is detected, then the Application Secret for your application must be changed immediately by creating a fresh application on the developer portal.

Applications must always use an OAuth token in the API request header called Authorization: in order to consume any of the APIs provided by AT&T.

An OAuth access token is obtained by invoking the OAuth API which triggers the authorization process. This process may involve interaction between the application and the API Platform only, as in the case of OAuth Token request, or it may involve interaction between the user's browser and the API platform. In the latter case, the secure interaction is initiated by the developer's application but the secure authentication is intentionally routed around the developer's application and, in so doing, assures the end-user that their user credentials are kept secure and are only passed between AT&T and the user's browser.

OpenID is about authentication (i.e. proving who you are). OAuth is about authorization (i.e. granting access to functionality, data, etc., without dealing with the original authentication).

For example, OAuth could be used in an external site to allow a user access to protected data without the external site having to re-authenticate the user.

After the lifetime that is specified in the expires_in parameter has elapsed, the OAuth access token is no longer valid. When that occurs, any attempt to use the expired OAuth access token results in an OAuth 2.0 Authentication Management API response with the HTTP Status Code of 401 Unauthorized. A developer must provide logic in their app to handle conditions when the expired OAuth access token may be used.

No. You must use AT&T's OAuth service to use any of AT&T's APIs.

No. An OAuth access token can be used until it expires.

For more details on token expiration, see Does the Oauth access token expire?.

No. The OAuth 2.0 Authentication Management API may only be used with RESTful APIs provided by AT&T.