Skip to content

Application Registration

To develop using the Indee API, your application has to be registered with Indee. This process is currently manual and you are required to reach out to Customer success team with:

  1. Your application name.
  2. Type of application (Administration / Watch).
  3. Number of API keys required and any expiry date (typically we provide 1 year valid keys).

Post registration you will be provided with the API keys that can be used for development.

API keys

Access to Indee APIs for authentication requires the use of an API key. The API key is required only during authentication and should be sent as part of the standard HTTP Authentication header as a bearer token.

The API key cannot be used to access all the APIs of Indee. This key is used ONLY during the authentication process and post authentication, the JWT tokens should be used for all API calls.

Authentication

Viewing Applications (Watch Apps)

Indee supports multiple forms of authentication for viewing applications. This is to facilitate both security of access and ease of use and in some cases, guild mandated methods. Currently we support the following forms of Authentication:

  1. Pin: A random set of characters that can be used for authentication. Typically used in FYC application use cases.
  2. Username/password: Traditional Authentication method used for access to Indee videos.

Administration Applications (Admin Apps)

Indee supports two forms of authentication for Admin applications. If the Enterprise has been configured to support Single Sign on (SSO) based authentication with your company's SSO provider. Authentication API will allow authentication using the provider.

The SSO login process involves an orchestration between the front end application and the backend Indee servers and the authorization servers of the enterprise. The diagram below outlines the process of API flow.

SSO Workflow

If the enterprise did not opt for SSO and instead decided to use Indee's own authentication mechanism, the authentication API will support this mechanism. Based on the API key, the platform determines the appropriate authentication mechanism and enables access.

Admin Authentication workflow

  1. Validate developer key.
  2. Authenticate user using either external authentication (SSO) or Indee authentication according to the enterprise configuration.
  3. Once authenticated, establish a JWT token pair (Refresh & Access token).
  4. Associate required information with the JWT access and refresh token (as part of the token claim).

The Admin Auth API should be used to login.

Authorization

Indee has a well established set of role based authorization already in place. We have account level roles as well as project level.

Some account level roles would be owner, global admins and project level roles would be uploader, publisher, project admin, etc.

The authentication and authorization will honor the same authorization roles as established for the user credentials. User will be allowed to perform a certain action based on the permissions of the role defined for them, as well as the permissions defined on the API key used.

Role Allowed activity
Uploader Video management
Publisher Audience management
Project Admin Project management, Video management, Audience management
Global Admin All
Owner All

Token management

Indee uses JWT tokens to represent an authenticated user. Further to ensure that the tokens are secure, Indee authentication mechanism uses the Access token / Refresh Token model as outlined in OAuth 2.0

The token pair is provided as a response to the login API call. The Refresh token should be stored securely while the Access token should be used for all subsequent API calls.

The Access token typically tends to be short lived in nature and will potentially expire in minutes. When the auth token expires, a new auth token can be obtained by calling the token refresh API.

key Security

Developer keys should be treated as passwords and shouldnt be exposed and stored in the browser. They should be stored and managed on the front end server (express or node).

JWT tokens as outlined in teh specification have two types of tokens, namely Authorization token and refresh token. The refresh token should stored on the customer server in a secure fashion and should not be shared with the browser. The Authorization token should be shared with the browser for API calls to the Indee server.