Skip to main content
Connect Bynder to Oleria to see who has access to your Bynder portal and to the content in it: its users and their security profiles, its groups, and who can see or edit access-controlled assets. Oleria reads this data through a Bynder OAuth app that acts as a Bynder user you choose, so you can see where access is over-provisioned and take action directly from Oleria.

​
What Oleria discovers

Once connected, Oleria continuously discovers and maps the following from your Bynder portal:
  • Accounts - every user in your portal, active and deactivated, with their name, email address, alternate email address, username, job title, department, and last login. For deactivated users, Oleria reads only the fields in Bynder’s user list, so their job title, department, and last login are empty. Users marked as SSO user in Bynder are shown as requiring single sign-on. Users whose security profile requires multi-factor authentication on login are shown as requiring MFA - see Known limitations. Users whose security profile can manage users, groups, or permissions are marked as administrators.
  • Roles - every security profile, as a role and an account role, with the profile each user holds. Oleria also maps what each profile allows on assets, collections, and access-controlled options, such as editing, deleting, or making assets public.
  • User groups - portal user groups with their members, and, if your portal has Bynder Workflow, Workflow user groups with their members and the user who created them.
  • Resources - brands and sub-brands, collections (with their owner and whether they have a public link), public assets, Brand Guidelines guides if your portal has Brand Guidelines (with their owner and visibility), and metaproperty options that have access rights.
  • Access rights - for each access-controlled metaproperty option, which users, groups, and security profiles are granted access to its assets, and who is explicitly hidden from them. Public collections, public assets, and public guides are shown as accessible to anyone with the link.
  • Non-human identities - the OAuth app Oleria connects with and its client secret, with the scopes it was granted and the Bynder user it acts as.
  • Activity - events from Bynder’s Analytics API: sign-ins, user creations, asset views, downloads, uploads, removals, archives and deletions, and collection views. Events on assets and collections that Oleria doesn’t import (see the note below) show who acted, but aren’t linked to a resource. Views and downloads that Bynder records without a user, such as through public links, appear as anonymous activity. Activity requires Bynder’s Analytics for BI Access add-on - see Prerequisites.
Oleria refreshes users, groups, and resources on its regular sync schedule. Bynder makes analytics data available with a delay of up to 24 hours, so Oleria imports each event about 24 hours after it happens, and the first sync reaches back at most 12 months.
Oleria doesn’t inventory every asset in your portal. It imports public assets individually and represents access to all other assets through the access-controlled metaproperty options and security profiles that govern them.

​
Prerequisites

  • A Bynder portal on its original Bynder domain, ending in .bynder.com or .getbynder.com. Custom domains aren’t supported.
  • OAuth Apps enabled for your portal. If you don’t see Settings > Advanced Settings > Portal settings > OAuth Apps, ask Bynder Customer Support to enable it. If OAuth Apps is enabled but you still don’t see it, check that your security profile has the Manage OAuth apps permission.
  • A dedicated Bynder user for the OAuth app to act as. Its security profile must have the USERMANAGEMENT, GROUPMANAGEMENT, and PERMISSIONMANAGEMENT permissions.
  • Optional: Bynder’s Analytics for BI Access add-on, to collect activity.
  • Admin access to the Oleria workspace.
For a complete inventory and for remediation actions, also give the integration user’s security profile:
Use a dedicated Bynder user instead of a named person’s account. Every call Oleria makes runs with this user’s security profile. If the user is deactivated or loses these permissions, syncs and actions stop working.

​
Register an OAuth app in Bynder

1

Create the app

Sign in to Bynder as a user with the Manage portal settings and Manage OAuth apps permissions. Go to Settings > Advanced Settings > Portal settings > OAuth Apps and register a new application for Oleria.
2

Choose the grant type and assigned user

Select the Client Credentials grant type and choose the dedicated integration user as the app’s assigned user. Oleria doesn’t use any other grant type.
3

Select the scopes

Select the scopes for what you want Oleria to do:You can’t change an app’s scopes after you create it. To add a scope later, create a new app and update the integration in Oleria.
4

Copy the credentials

Copy the app’s client ID and client secret. Bynder shows the client secret only once.
The exact location of these settings can change over time. If the steps above don’t match what you see, refer to Bynder’s own documentation.

​
Connect Bynder to Oleria

1

Open the integration

Go to your Oleria workspace, select Integrations -> select Bynder.
2

Complete the connection form

Select Continue and provide the following:
3

Confirm the connection

Select Authenticate. Before it saves anything, Oleria requests a token, reads the app’s assigned user, and checks that the user’s security profile has the USERMANAGEMENT, GROUPMANAGEMENT, and PERMISSIONMANAGEMENT permissions and, when Bynder reports the app’s scopes, that the app has the three required scopes. Find the newly connected portal on the Connected tab of your Oleria Integrations page.
Besides valid credentials for a Bynder domain, Authenticate requires only the permissions and scopes marked as required. A missing optional scope or permission, or a missing Analytics for BI Access add-on, doesn’t stop the connection: Oleria skips the data it can’t read. Confirm the data after the first sync, as described in Verify the integration.

​
Verify the integration

Confirm the Bynder portal appears on the Connected tab of your Oleria Integrations page with a status of Healthy. After the first sync completes, check that users, security profiles, groups, and collections appear in your Oleria workspace, and that the OAuth app appears as a non-human identity. If you have the Analytics for BI Access add-on, allow at least 24 hours, plus one sync, for activity to appear.
When you edit the integration, you can change the client ID and client secret. Leave Client secret blank to keep the stored secret, and enter it again if you change the client ID. To connect a different portal, add a new integration.

​
Remediation actions

Oleria can take these actions in Bynder. Each one runs with the security profile of the OAuth app’s assigned user and needs the scopes and permissions listed: If the OAuth app or its assigned user doesn’t have an action’s scopes and permissions, that action isn’t available for the integration. Keep these limits in mind when you use these actions:
  • Oleria reads the user, group, option, or collection before it changes anything. If it’s already in the requested state, Oleria makes no change.
  • After a change, Oleria reads it back. The action succeeds only when Bynder shows the change. If Bynder accepted the change but Oleria can’t see it yet, the action fails and asks you to check the user, group, option, or collection in Bynder. Oleria never sends a second write to undo it.
  • Reverting an action undoes only the change that action made. If someone changed the same user’s security profile after the action, Oleria doesn’t overwrite it.
  • Change a user’s security profile replaces the user’s profile, because a Bynder user holds exactly one profile. Reverting restores the previous profile.
  • Reactivate a user may be refused by Bynder, which allows reactivating a user only 180 days after deactivation. Ask Bynder Customer Support to reactivate a user sooner. Reverting a deactivation can hit the same limit.
  • Delete a user can’t be reverted.
  • Add a user to a group and remove a user from a group work on portal user groups only. Oleria doesn’t change Workflow user group membership.
  • Create a group is reverted by deleting the group, but only while it has no members.
  • Revoke a user’s access to a metaproperty option removes only the user’s own access rights on that option. It never removes a rule that hides assets from the user. If the user also gets access to the option through a group or a security profile, the action fails without changing anything and names that group or profile, because removing the user’s own rights wouldn’t remove the access, and removing the group’s or profile’s rights would remove it for everyone else. Remove the user from that group or change that rule in Bynder. If an option has more access rights than Oleria can read, if an access level the user holds also carries a rule of another type, or if any other user’s, group’s, or profile’s access rights change during the action, the action fails so you can check the option in Bynder.
  • Unpublish a collection removes its public link. Bynder doesn’t allow making a public asset private again, so Oleria can’t unpublish public assets, and it can’t change a Brand Guidelines guide’s visibility.
  • Oleria won’t deactivate, delete, re-profile, or change the group membership or option access of the OAuth app’s assigned user, because that would disconnect the integration or hide content from it.

​
Known limitations

  • Activity needs the Analytics for BI Access add-on. Without it, Oleria doesn’t import activity. Activity is imported about 24 hours after it happens, and Bynder keeps analytics data for 12 months.
  • No last password change or account creation date. Bynder’s API doesn’t report them.
  • MFA from security profiles only. Bynder enforces MFA per security profile, and its API doesn’t document the name of that permission. Oleria treats a profile permission whose name contains “MFA” together with “REQUIRE” or “LOGIN” as requiring MFA, so permissions that only administer MFA, such as resetting it, don’t count. If at least one profile in your portal has such a permission, password users on other profiles are shown as not requiring MFA. If none does, their MFA status is shown as unavailable. Users who sign in with SSO aren’t prompted for Bynder MFA.
  • Only Oleria’s own OAuth app is discovered as a non-human identity. Bynder’s API doesn’t list other OAuth apps, permanent tokens, or AI agents.
  • Collection shares and brand restrictions aren’t visible. Bynder’s API doesn’t report who a collection is shared with, or which brands a user can see.
  • Assets hidden from the integration user. A public asset that a metaproperty rule hides from the integration user can’t be listed, because Bynder applies hide rules to administrators too.
  • Large access lists. If a metaproperty option has more than 1,000 access rights, Oleria may import only some of them. Those options are labelled, and Oleria won’t revoke access on them.
  • Rate limits. Bynder limits API calls per source IP and blocks all calls for five minutes after the limit is reached. Oleria slows its requests to stay under the limit and waits out a block before it retries.
  • Original Bynder domains only. Oleria connects only to .bynder.com and .getbynder.com domains over HTTPS.

​
Contact us

For questions about this integration, contact us at support@oleria.com.