Partners

Developers

Developers that represent your partners may register for access via the Developer Portal, but they can also be manually created via the management console. Basic information about the developer contact and their company are standard but extended information may also be stored. You can customize the developer portal to capture any or all of these fields.

Applications

Developers will enter Application profiles that contain information that is important for 3-legged authorization like OAuth. For example, your authorization screen might show the application information such as name, description, author, and company. It also stores valid callback URLs which are used by OAuth to verify that the application requesting the permissions is genuine.

An application can be tied to a Plan, which will enforce the request quotas defined by that Plan and assign the fee to be paid by the application developer.

Clients

An application can support multiple platforms (e.g. Web, iOS, Android, etc.) or data centers where traffic originates. You may want to track each of these separately in reporting. A client is created for each platform of interest. The analytics engine can produce reports specific to an application as a whole or to a specific client.

Like Providers, Clients have credentials in the form of an API Key and Shared Secret. These credentials should be communicated to partners in a secure fashion (e.g. Over the phone, encrypted email, or developer portal).

Permissions and Access Delegation

Security policies are configured at this level to provide granularity on what permissions are allowed from where (e.g. Mobile apps might be more constrained). Permissions are granted to the client itself (2-legged, B2B) or delegated by the user/customer (3-legged, B2C). Delegated permissions are granted via a token, which could be created from one of the several OAuth flows or even a custom flow. Permissions are defined in Authorization Schemes individually in order to control permissions for each of these possible approaches.

The figure below shows the management panel for configuring Authorization Schemes.

The Scheme can be enabled or disabled at any time. Expiration controls how long the token will live while Life Span controls how the system expires the token. A Finite life span means that the token will expire after the timespan has elapsed since its creation. A Session life span means that the token will expire after it has not been used in a request for the defined timespan (like how a web application session behaves).

User Interface Options are flags that the OAuth application uses in order to loosen some of the security constraints it imposes on client applications.

  • Allow refresh enables Refresh Tokens, meaning that when the token expires, the client may retrieve a new one without obtaining authorization from the user.

  • Auto authorize permissions is a useful setting for internal applications. Since you are the author of the application, your users should not have to explicitly authorize the application to perform certain operations. Enable this and the authorization step of OAuth will be bypassed.

  • Allow native web view controls applies to native applications that might embed a web browser control inside their application. This poses a potential security risk because the application may be able to capture keystrokes that make up your username and password. This should only be enabled when the native application is from a trusted partner and you are able to audit the application's source code.

  • Allow popup windows and IFrames is similar to the above. However, it applies to desktop web applications that use popup windows or IFrames to send the user to OAuth. Using JavaScript, a developer could capture your account credentials.

Under User Permissions, the Manage Globally option applies permissions universally to all tokens created by this authorization scheme. If you change the permissions, the change is applied to all tokens. Without this option enabled, each token is given a copy of the assigned permissions at the time of creation. Changing the permission settings will not impact previously created tokens.

For the permissions themselves, the options will be different depending on if they are Action Permissions or Entity Permissions. Action Permissions have a simple "on/off" state. Entity Permissions can control creating, reading, updating and deleting, with an "on/off" state for each.