Tiki Marketplace provides an identity platform that helps you build applications your users can sign in to using their Tiki account, and also provides authorized access to Tiki APIs like Order APIs, Product APIs, …
There are several components around the Tiki Marketplace identity platform:
- Authentication and authorization server: An unified system manages all identities and their scopes of access for the entire platform.
- Tiki Business (https://business.tiki.vn): A service helps your organization to manage its own groups, users, as well as connect to Tiki services and manage all integrated Tiki services in one place.
- Tiki OpenAPI (https://open.tiki.vn/ ): Technical documentation including get-started, quick-starts, how-to guides helps you easily integrate your client app with Tiki Marketplace through the API and a console portal (https://open.tiki.vn/console) to register and configure your application and service account enables your client app to integrate with Tiki Marketplace via APIs.
Tiki uses the term “application” for “app registration”. Your client app needs to be registered before it can be used. Tiki Marketplace identity platform performs identity and access management only for registered applications.
When you create an application, you’ll get a managed service account with a client id and client secret to authenticate and be authorized to access data and resources in Tiki Marketplace.
Service AccountService account is an account intended to represent a non-human user that needs to authenticate and be authorized to access data and resources in Tiki Marketplace through APIs.
Why do you need an application?
You need an account to authenticate and be authorized to access data and resources in Tiki Marketplace. Almost everyone is familiar with user accounts. They are specific to individuals and allow us to sign in with our own credentials.
Service accounts differ from normal user accounts in multiple ways:
- They don’t have a password and can’t be used for browser-based sign-in.
- They’re created and managed as a resource that belongs to Tiki OpenAPI for client applications and they’re specific to Tiki OpenAPI while the users managed in Tiki Business can work across a multitude of Tiki services.
Service accounts are intended for scenarios where a workload, such as a custom application, client app, needs to access resources or perform actions without end-user involvement.
By creating an application, you’ll get a managed service account for your client app.
Moreover, registering your client app with an identity provider through an application (or app registration) creates a trusting relationship between your client app and the identity provider, which also means a way for your client app to trust the security tokens (access tokens, refresh tokens) issued to it by the identity provider.
Tiki provides 2 types of applications depending on the operating model of various partners (individual sellers, multi-channel sales platform, retail supermarkets,…) who want to integrate their business with the Tiki Marketplace through API.
- Public application: Your platform supports many of your own customers (sellers – who want to sell on Tiki) to optimize operational capabilities, manage efficiency, and increase revenue effectively by integrating with Tiki Marketplace through API while leaving inventory, shipping, and returns handled by Tiki Marketplace.
- In-house application: Your app supports an individual seller to sell on Tiki Marketplace automatically and effectively by integrating with Tiki Marketplace through API.
What exactly is the application you need?
If you want to build an application for only one seller and only need access to that seller’s data. It’s best to create an in-house application because it is easier to create and use.
Your application only needs seller to confirm the connection before it can access that seller’s stores.
When an in-house application is connected to a seller X, it can represent the seller X (it has all the permissions the seller X has) to authenticate with the Tiki System (using client app’s credentials) and get an access_token. Anyone using the inhouse app can access protected resources without request authorization from that seller.
You can create multiple in-house applications for multiple individual sellers. But your client app has to manage all the in-house app’s credentials and use the appropriate app’s credentials to obtain an access token for the corresponding seller.
If you want to build a platform to support multiple sellers and need access to the data of multiple sellers without creating more applications for these users. You have to create a public application.
The scenario here is you are building a platform to allow multiple sellers (seller X, Y, Z) manage their products and orders that are selling in the Tiki Marketplace.
To access that seller’s data in Tiki Marketplace, your platform needs permission from these sellers. You may have many sellers and your client app has to request authorization from these sellers to access their data in the defined scope.
Each request asks to access the data of a specific seller, and then you’ll get an access token corresponding to that seller.
However, the public application has to be reviewed by Tiki’s moderator to be verified, and you may have to wait 2–24 hrs. In some cases, your application may be rejected because the information you provide is not satisfactory.
|Support one app for multiple sellers
and your client app can access data of multiple sellers without creating more applications for these sellers
|Need to be verified by Tiki’s moderator
|Have to wait for review (2-24hrs)
Hard to use and debug than inhouse app when obtain access token (you may have to implement 3 different auth flows – authorization code flow, refresh token and client credentials)
Have to request authorization from user (seller)
|Have all permissions the seller has so don’t need to to request authorization from user (seller)
Easy to use and debug when obtain access token (you need only to implement client credentials to obtain access token)
|Need to be connected by User (Seller Admin)
|Don’t support one app for multiple sellers
- If you want to build an application for an individual seller, you should create an inhouse app. For example, you build an app for an individual seller, multi-channel sales platform, retail supermarkets,…
- If you have a fixed number of sellers, you could also consider creating a corresponding number of in-house apps for these sellers and then managing and using them. For example, you build an app for a retail supermarket that has several fixed sellers.
- If you want to build a platform that supports many of your own customers (sellers – who want to sell on Tiki) to optimize operational capabilities, manage efficiency, and increase revenue effectively by integrating with Tiki Marketplace through API. You should create a public app. For example, you want to build a multi-channel sales platform or POS (Point of Sale) platform.