Skip to main content
All CollectionsAuthorizations
Understanding Remote Identities
Understanding Remote Identities

Data source and destination access, permissions, and resources

Openbridge Support avatar
Written by Openbridge Support
Updated over 3 weeks ago

A remote identity reflects a user authorization to a data source (i.e., Facebook, Google, Amazon...) or data destination (i.e., Google BigQuery, Amazon Redshift...).

An authorization to a source or destination is defined by the source or destination, not Openbridge. This means you are defining access levels and permissions in the upstream system, not Openbridge.

Understanding Identities And Authorizations

Authorization defines how we can access a resource. In the case of sources, it is not uncommon for them to redirect a user to their site to authorize access so Openbridge can connect to a source account. As a result, Openbridge does not have insight into the process on the source website where authorizations occur. Our visibility is limited to receiving an authorization token back from the source after it happens successfully.

For example, when authorizing Amazon Advertising, you will be redirected to the Amazon Advertising website to authorize Openbridge. Given that you are on the Amazon website, Openbridge will not have any visibility into the email, password, or user account settings...that were input at Amazon. All Openbridge sees is that Amazon supplied us with an authorization token granting access after the process is completed at Amazon.

Label Your Identities

Openbridge will not know what email, user, or other information was entered on the Amazon site. As a result, we strongly suggest you adequately label your identities to help you identify what data was entered at the source website.

Auto Expiring Authorizations

Some sources auto-expire authorization after a set period. For example, Amazon Selling Partner API will expire an authorization after 12 months unless you take action to renew it manually. See Amazon Selling Partner Expired or Expiring Authorizations. If your source does auto-expirations, please take note of that and plan accordingly.

Scaling Authorizations

A remote identity may be reused across several resources for a data source. This allows you to have a one-to-many association. For example, you may have a Facebook account (user1@foo.com) that acts as a "page manager" across 30 Facebook pages. Openbridge allows you to register this Facebook account as a remote identity.

When activating Facebook as a data source, Openbridge will present you with all the page resources a remote identity can access on Facebook, as defined by Facebook. You can use the remote identity to connect to all 30 Facebook accounts or just 1. 

This capability is dependent on the source system, not Openbridge. Not all sources offer a one-to-many association.

Using Group Emails

For more information on why using group emails simplifies ongoing management activities like authorizations, fixing errors, and dealing with alerts, see

Reauthorizing Expired or Disconnected Authorization

Authorized access to your accounts becomes disconnected from time to time. See Restoring Openbridge authorization to access your data sources and destinations.


Authorizations can expire for several reasons, including password changes, accounts getting locked, someone removing a setting, user access removal, lack of billing/payment at the source, or there is a limited lifespan of an access token. 

While this can be frustrating, it's good to remember that this is normal behavior and is usually the result of a change to keep your account safe and secure by a source system.

When authorizations expire, you must reconnect and authorize us again. Openbridge will email "Authorization Failure" notifications when we detect your account authorization is not working.  It will look something like this:

Proceed through the process again to reconnect our authorization. It is important to note that an authorization token is tightly bound to the original authorized user.

Suppose you are attempting to use an account different from what was originally used for the first authorization. In that case, this will be rejected by the source system when we attempt to reauthorize it.

For example, an Amazon Advertising identity was created with user 1@foo.com. If you attempt to reauthorize the account with user99@foo.com, Amazon, not Openbridge, may reject that request. They will see a mismatch between the original user authorization and a reauthorization attempt.

Important: While Openbridge will attempt to detect authorization errors, different source systems may have different permissions and role structures. It is possible for authorization to pass a validation check, but it fails when requesting a specific resource at a data source because permission was removed or expired. In these cases, Openbridge will have limited visibility into what transpired in the source system, such as permission being accidentally removed. You will need to take action directly in the source system account. For examples of this, see Troubleshooting Amazon Brand Analytics Permissions or Troubleshooting Amazon SP-API Permissions.

Removing Remote Identities

Removing remote identities requires a request to support@openbridge.com. This ensures an identity that may accidentally disconnect your data feeds is not removed. Without a remote identity authorization, any active data flow would stop.

In this case, removing an identity would disrupt the data flow. Depending on the data source, there may be no way to re-request this information upon reactivating the data connection. 

In our Facebook example, if you requested that we remove the identity attached to 30 Facebook accounts, then the authorizations we have to collect data would be removed for all 30 accounts. Data collection would no longer work, which may not have been the original intent of the removal. 

Did this answer your question?