What is changing for Cirrus Gateway Customers
Why is Cirrus Identity making this change
When does this change have to be completed
What will Customer end-users see or experience
How does a Customer determine if they are impacted
What support will Cirrus Identity provide for this change
Why is migrating LinkedIn from SP-Specific API Key to Shared API Key special
How do Customers make this change
Navigating to the SP-Specific Gateway Configuration
Navigation to Gateway Configuration for Cirrus Proxy tenants
Navigation to Gateway Configuration for directly configured SAML Service Providers (SPs)
What if I have multiple SP-Specific API Key configurations using the same key and secret
Adding Authorized Redirect URIs to providers
Cirrus Identity is deprecating SP-Specific API Key Cirrus Gateway configurations in favor of the Cirrus Gateway Shared API Key method for configuring personal login providers.
Shared (Gateway) API Keys are a newer implementation pattern that fully cover and extend capabilities of the older 'SP-specific' implementation pattern.
Having two different ways to configure Gateway API keys has proven cumbersome for customers, and so we are phasing out the legacy method.
Cirrus Identity aims to phase out SP-Specific API Key Cirrus Gateway configurations by the end of June 2026. Cirrus Identity will be providing migration support to customers with the deprecated pattern.
If implemented as recommended, this change will not affect end users. Customers using the ORCID provider may experience a new consent request.
NOTE - Customers should consult with Cirrus Identity Support before making any configuration changes for the LinkedIn Provider. See “Why is migrating LinkedIn from SP-Specific API Key to Shared API Key special” for details.
While Cirrus Identity recommends copying the existing SP-Specific API Key configurations to Shared API Keys where possible (see “How do Customers make this change”), if customers choose to create new Shared API Keys for Amazon, Apple, Google, or Microsoft, customers may experience a new consent request from the provider.
By April 1, 2026, Cirrus Identity will be reaching out to customers that have existing SP-Specific API Key Cirrus Gateway configurations. In the meantime, customers can review their current Cirrus Gateway provider configurations at the individual service provider level.
NOTE - Customers should consult with Cirrus Identity Support before making any configuration changes for the LinkedIn Provider. See “Why is migrating LinkedIn from SP-Specific API Key to Shared API Key special” for details.
If the API Setup Option is set to “SP-Specific API Key”, you should make preparations to change. The following is an example of a Cirrus Gateway Google provider configured with an SP-Specific API Key:
The nature of personal login provider integrations means Customers must put “hands on keyboards” for this migration. However, Cirrus Identity will be actively providing additional, targeted support to assist Customers by:
To safely migrate LinkedIn from an SP-Specific API Key to a Shared API Key, you MUST copy the existing key and secret from the SP-Specific API Key configuration into a Shared API Key. You must update the LinkedIn defined application with the additional redirect URL of the Shared API Key. See “Adding Authorized Redirect URIs to providers” for more information.
Whereas the majority of the Cirrus Gateway providers (Amazon, Apple, Google, Microsoft, and ORCID) have an internal identifier that is invariant, LinkedIn does not. The internal identifier provided by LinkedIn is pairwise defined with the application key. Migrating any of the others can be done by creating a new integration for the Shared Key, but this will not work for LinkedIn. Creating a new integration for the Shared Key would change the internal identifier returned when an end-user signs on. A changed identifier will likely result in a broken application access experience.
Cirrus Identity recommends copying the existing SP-Specific API Key configurations for Amazon, Apple, Google, LinkedIn, and Microsoft providers to Shared API Keys. Customers MUST use this method for LinkedIn (See “Why is migrating LinkedIn from SP-Specific API Key to Shared API Key special”). For the limited number of customers using the ORCID provider, you must create a new key – ORCID does not support the ability to define multiple redirect URIs which is a necessary capability for migration.
For Amazon, Apple, Google, LinkedIn, and Microsoft provider, repeat the following steps for each SP-Specific API Key:
Step 1 - Verify you can access the application configuration in the provider developer console corresponding to the SP-Specific API Key being migrated. Links to each provider's developer console are presented in the instructions to the right of either the SP-Specific API Key or Shared API Key configuration screens.
Step 2 - Navigate to the Cirrus Gateway provider for the Service Provider (SP) with the SP-Specific API Key configuration – see “Navigating to the SP-Specific Gateway Configuration” for details. DO NOT change the setting for “API Setup Option” at this time – we will come back and change that once we have the Shared API Key established. Record the existing values for the “API Key” and “API Secret”. Temporarily recording them into an open text editing application can be an effective method to accomplish this. While the API Key and API Secret have been grayed out for security reasons, the following screen shot for an SP-Specific API Key Google provider integration indicates where to find the relevant information.
Step 3 - Navigate to the Organization's Shared API Key page and create a new Shared API Key for the provider you are migrating from Step 2. The following is an example of creating a new Shared Key for the Google provider:
Step 4 - Copy values for the “API Key” and “API Secret” record during Step 2 into the respective fields of the new Shared API Key. There is also a field called “Account Name” that can be used to document the account holder for the application setup in the provider developer console – while optional Cirrus Identity recommends filling this in. Save the new key
Step 5 - Copy the value for the redirect URI from the instructions provided on the right of the Shared API Key configuration. This value must be added to the list of authorized redirect URIs for the provider’s application configuration maintained in the provider’s developer console (the application you validated access to in Step 1). The following screenshot shows the details of Steps 4 and 5 related to configuring the new Google provider Shared Key:
Step 6 - Once the provider’s application configuration has been updated, you are ready to switch the Service Provider to use the new Shared API Key. Return to the Cirrus Gateway provider for the Service Provider (SP) with the SP-Specific API Key configuration (as in Step 2). Toggle the “API Setup Option” Shared API Key and pick the Shared API Key created in Steps 3, 4, and 5 from the drop down. Save the change. After waiting 5 minutes for changes to propagate, you may use the “Test Login” option in the lower right to verify the provider is working as expected.
If the “Test Login” fails for some reason, the change can be reversed by toggling the configuration back to SP-Specific API Key. The existing configuration should remain. The most common issue that will cause a new key to fail is an improperly entered or unsaved redirect URL in the provider developer console.
NOTE - Customers cannot create new keys for the LinkedIn Provider. See “Why is migrating LinkedIn from SP-Specific API Key to Shared API Key special” for details.
If customers have a compelling reason to create new keys for Amazon, Apple, Google, or Microsoft, they may choose to do so. While this will result in the same internal identifier being returned from the provider, this migration path may result in the end-user experiencing a new provider consent request. Customers should follow the Cirrus Gateway documentation for instructions on how to create new keys.
Navigating to the SP-Specific Gateway Configuration in the Cirrus Console has two paths depending if you are using Cirrus Gateway with Cirrus Proxy, or if you are using a legacy integration directly configured to a SAML Service Provider (SP). Navigation for both methods are outlined below:
Navigate to the Cirrus Proxy tenant SP configuration by either selecting the Cirrus Proxy tenant from the menu above the dashboard presented when you sign on, or by selecting it from the list of Proxies on the dashboard.
Both routes will take you to the Proxy Details configuration. Select “Discovery Service”.
Once you reach the Discovery Service, select “Gateway Service” from the menu on the left.
Navigate to the Gateway configuration for directly integrated SPs, by either selecting the SP from the menu above the dashboard presented when you sign on, or by selecting it from the list of SPs at the bottom of the dashboard.
Both routes will take you to the SP configuration page with an option for “Discovery Service” in the left menu.
NOTE - Customers must pay particular attention to LinkedIn keys configured on multiple Service providers. Intermingling of key values for LinkedIn is not supported. See “Why is migrating LinkedIn from SP-Specific API Key to Shared API Key special” for details.
If a customer has previously set up multiple SP-Specific API Keys with the same values for a provider, only one Shared API Key needs to be configured (see How do Customers make this change). All of the service providers using the same value can be migrated to the same Shared API Key. This simplification can be a positive outcome of moving to the use of Shared API Keys. The following screen shot shows where the Shared API Key configuration reports the different service providers that are using the specific Shared API Key:
This section outlines the authorizing of additional redirect URIs (a more general name for URL) for each of the personal login providers. In each case, the setup is performed in each provider’s developer console.
To authorize an additional redirect URI, go to the Login with Amazon Console. At the listing of existing Amazon Configurations, select the one corresponding to your provider configuration. Using the configuration popup menu on the right, select Web Settings. Click the “Edit” button and this will allow you to add additional redirect URIs.
To authorize an additional redirect URI, go to the Apple Developer Console. Navigate to “Certificates, Ids & Profiles”. Select the “Identifiers” option and then list the “Service IDs” using the pulldown on the right side of the screen. Select the Service ID that corresponds to your provider configuration. Press the “Configure” button to the right of the “Sign In with Apple” service. To authorize an additional redirect URI, click the blue plus sign to the right of “Website URLs”.
To authorize an additional redirect URI, go to the Google Cloud Console. Select the project from the upper nav bar that corresponds to your provider configuration. Select “Clients” from the left menu and then select from the list of OAuth 2.0 Client IDs. You can then add the additional redirect URI.
To authorize an additional redirect URI, go to the LinkedIn Developer Console. On the My apps page, select the app that corresponds to your provider configuration. Select “Auth” from the top navigation bar. You can add additional redirect URIs in the OAuth 2.0 settings.
To authorize an additional redirect URI, go to the Azure Portal. Navigate to Entra ID, and then App registrations. Select the application that corresponds to your provider configuration. Under Manage, select “Authentication” from the left navigation menu. You can add additional redirect URIs from the page that displays.
ORCID doesn’t support multiple redirect URIs for the same key and secret. Cirrus recommends always configuring ORCID as a Shared API Key.
© Copyright Cirrus Identity, Inc.