Roles and permissions
Commerce Layer supports a granular access control system on a resource level. Each access token gets a specific set of permissions. The client and the authorization flow determine your permitted actions for each resource.
Channel applications support Client Credentials, Password and Refresh Token grant types. If public access is enabled, they can authenticate without the client_secret. In such cases, the access tokens that they get have limited permissions on sensitive data.
Channel applications that authenticate through Client Credentials get the following permissions. The green icons show the ones that are granted with public access enabled.
|Skus||check_circle||Skus with stock items in the market' stock locations and a price in the market's price list.|
|Prices||check_circle||Prices associated to the market's price list.|
|Stock Items||check_circle||Stock items associated to the market' stock locations.|
|Delivery Lead Times||check_circle||Delivery lead times associated to the market' stock locations.|
|Orders||check_circle||check_circle||check_circle||Orders associated to the market scope. Can be read if "draft", "pending" or "placed" and updated if "draft" or "pending". Order lists are limited to one result.|
|Line Items||check_circle||check_circle||check_circle||check_circle||Line items belonging to "draft" or "pending" orders, in the market scope.|
|Shipping Methods||check_circle||Shipping methods associated to the market scope.|
|Shipments||check_circle||check_circle||Shipments associated to "draft" or "pending" orders, in the market scope.|
|Payment Methods||check_circle||Payment methods associated to the market scope.|
|Credit Cards||check_circle||check_circle||check_circle||Credit cards associated to "draft" or "pending" orders, in the market scope.|
|Paypal Payments||check_circle||check_circle||check_circle||Paypal payments associated to "draft" or "pending" orders, in the market scope.|
|Customer Password Resets||check_circle||check_circle||check_circle||check_circle|
Channel applications can authenticate a customer through the Password flow. The access tokens that they get include the sum of the client permissions plus the ones below.
|Customers||check_circle||check_circle||check_circle||The customer must be the authenticated resource owner.|
|Customer Addresses||check_circle||check_circle||check_circle||check_circle||The customer must be the authenticated resource owner.|
|Customer Subscriptions||check_circle||check_circle||check_circle||check_circle||The customer must be the authenticated resource owner.|
|Orders||check_circle||check_circle||check_circle||The customer must be the authenticated resource owner.|
|Parcels||check_circle||The parcels must belong to one of the customer's orders.|
An access token obtained through a refresh token inherit the same set of permissions of the one that expired.
Other application types
Integration, Zapier, and Webapp application types have more straightforward authorization rules, as described below:
- Integration applications support the Client Credentials grant type. The access tokens that they get include the set of permissions of their role.
- Zapier applications get the right amount of permissions that are required by our official Zapier app.
- Webapp applications support Authorization Code and Refresh Token grant types. They don't bring any grants to the access tokens, and get the set of permissions of to the authenticated user's role. Access tokens obtained through a refresh token inherit the same set of permissions of the one that expired.