Permissions

Overview

As a Workplace system administrator, you can control the capabilities offered to each integration by creating apps and granting them specific permissions. Each app can be named to reflect the service it enables. Apps come with unique access tokens and permissions to control what information is allowed to be read or written by that app.

This guide describes the app and permission model in more detail.

The permission controls when editing a custom integration app

Available Permissions

Each Workplace app can be granted its own set of permissions to control the level of functionality available to it on the Graph API and Account Management API.

When you create an app and grant permissions, those permissions are applied to every account in your community. Account holders don't need to grant additional permissions to the app in order to benefit from its functionality. This differs from the permission model on Facebook, where each user individually grants permissions to an app when logging in.

Below is a full list of the app permissions available to integrations, along with an overview of how they can be used.

Group-Level Permissions

For some permissions, it's possible to limit an integration to be enabled on specific groups. This allows you to scope an integration's access to just the content you want to expose.

For example, you can allow an alert-posting integration to post only in a team's own group, or enable an employee app integration to read content only in specific open groups.

To specify group-level permissions for a custom integration, use the Group Access panel in the Edit Integration dialog.

Enabling group level permission for this integration.

Group-level permissions apply to the following permissions:

• Read group content - Read posts, comments and member profiles in selected groups
• Manage group content - Manage posts and comments in selected groups
• Manage groups - Edit or remove selected groups and their members

You can configure an integration such that group-level permissions can be applied to either All groups, Specific groups as chosen by a system administrator, or Let group admins enable for their groups.

Admin Install Flow

When Let group admins enable for their groups is enabled, an admin of a group will see a new Integrations tab under the Manage Group screen, allowing them to enable the integration on their group.

An example app which can now be enabled by the group admin.

App Tokens & Usage

When you create a new app for Workplace, an access token is generated for use with the Graph API, Account Management API, or Webhooks.

This access token will only be shown once, so it's important to store the token securely for later usage in code.

The token reset flow for a custom integration app

Workplace app tokens never expire, and do not need to be refreshed unless they have been manually reset. If you edit the permissions available to a given app, the existing token will still work, and you won't need to generate a new token.

If you ever need to invalidate a token, you can reset the token via the Reset Access Token button in the Edit App dialog. A new token will be generated and displayed, and the existing token will be immediately invalidated.

Token Security

Access tokens are powerful. They grant access to your company's data on Workplace. When creating an app, consider the minimal set of permissions necessary to complete the integration features, and don't grant any unnecessary permissions.

When storing tokens or adding them to code repositories, great care should be taken to ensure that they aren't shared with the wrong people.

To add an additional layer of security for integrations, you should add an IP whitelist, which will restrict token usage to servers only on the whitelisted list of IP addresses.

Adding an IP whitelist to restrict token usage to specified servers and requiring App Secret Proof

Automatic removal of unused permissions

If a custom integration makes no calls using a particular permission for 30 days, that permission will be removed. After this has happened once for a custom integration, an option will be available to stop this removal process.

If a valid webhook subscription has been set up, the webhooks sent by this count as a use of the relevant permission.

Controls for automatic removal of permissions

App Secret Proof

Access tokens for Workplace don't expire. Custom integrations can require an app secret proof to add an additional layer of security. Enabling the 'Require App Secret Proof' option ensure that API calls are only ever made from server-side code, an expiring app-secret proof will be required along with a the access token when making API calls.

To generate an expiring app-secret proof, you'll need to concatenate the token with a unix timestamp, separated by a pipe symbol |, then create a SHA-256 hash of the concatenated string, using your app secret as the key. Here's an example in PHP:

$appsecret_proof = hash_hmac('sha256', $access_token.'|'.time(), $app_secret); 

To make API calls with your app-secret proof, pass the generated hash via the appsecret_proof parameter, along with the appsecret_time set to the timestamp you used when hashing the app secret, along with your access token.

GET https://graph.facebook.com/v2.9/community/groups?
&access_token={access-token}
&appsecret_proof={appsecret_proof}
&appsecret_time={appsecret_time}

Exploring API Functionality with Postman

Postman is a widely used tool for working with web APIs. You may find it convenient to explore the Workplace API using Postman, but the $appsecret_proof parameter presents a complication - since this value must be calculated and expires after five minutes, it would simplify matters if Postman could generate the value at request time. In fact Postman can do so using its Prerequests Scripts & Params features. This script can be used as a starting point:

// Add to Postman's Pre-request Script Tab
var access_token = "replace-me";
var app_secret = "replace-me";
var time = (new Date().getTime()/1000|0);
postman.setEnvironmentVariable("access_token", access_token)
postman.setEnvironmentVariable("appsecret_time", time);
postman.setEnvironmentVariable("appsecret_proof", CryptoJS.HmacSHA256(access_token + '|' + time, app_secret));

1) Create an active environment (there isn't one by default), then 2) add these three parameters, which are calculated by your pre-request script.