Register FutureFeed.co with Azure AD
Register FutureFeed.co with Azure AD; see Microsoft's Quickstart: Register an application with the Microsoft identity platform.
If you have more than one Azure AD directory, please make sure you are in the right directory when you register the FutureFeed.co application.
During registration, configure the following settings:
- Supported Account Types: Allow users from external organizations (like other Azure AD directories) to choose the appropriate multi-tenant option. Multi-tenant options include accounts in any organization directory (Azure AD directory - multi-tenant).
- Redirect URI: Select a URI type of Web, and enter the callback URL for FutureFeed.co (https://okta.futurefeed.co/oauth2/v1/authorize/callback)
In this process, Microsoft generates an Application (client) ID for the FutureFeed.co application; you can find this on the app's Overview screen. Make a note of this value. This value and the client secret below will need to be sent to FutureFeed to complete the configuration.
Create a Client Secret
To create a client secret, see Microsoft's Quickstart: Configure a client application to access web APIs - Add Credentials to your web application.
Once generated, make a note of this value.
If you configure an expiring secret, record the expiration date; you will need to renew the key before that day to avoid a service interruption.
To add permissions, see Microsoft's Quickstart: Configure a client application to access web APIs - Add permissions to access web APIs.
While configuring permissions, you will need to configure the following permissions for the Microsoft Graph API as Delegated Permissions
- Users > User.Read - So FutureFeed.co can sign in users and read the signed-in users' profiles.
- Directory > Directory.Read.All - FutureFeed.co can read directory data on the signed-in user's behalf.
Send the Application ID and Client Secret to FutureFeed
FutureFeed needs some information from your FutureFeed.co application registration. We need these values:
- Microsoft Azure AD Domain (<company-name.com>)
- Client ID (Application ID in Azure AD)
- Client Secret
The Client ID (Application ID) and Client Secret require careful handling. To send these values to FutureFeed, please make sure and encrypt the values before sending them. An easy way to encrypt them is to add them to a simple text file and then encrypt the file with a password. In two separate encrypted emails, send the encrypted file and the password to email@example.com.
Additional information to send to FutureFeed:
- The hostname for the user's email addresses. This is the part between the @ sign and the .com/.org/.gov, etc. user@<email host name>.com, for example.
- Business unit name. For example, <parent company> - <business unit name>. If there is none, just the company name is OK.
Once FutureFeed has the configuration completed on our end, we will notify you that it's completed. You can move on to testing the connection and access to the application through your current federated identities.
Here are some troubleshooting tips in case you run into issues:
- I registered the FutureFeed.co application with Azure AD, but when I go back to my Azure Active Directory App registrations, I can't see the application.
- You may have accidentally registered the FutureFeed.co app in the wrong Azure AD directory (or have not created an Azure AD directory before registering your app). It's likely easiest to re-register FutureFeed.co app in Azure AD. Make sure you are in the correct directory when you register the app. If you need to create an Azure AD directory, follow Microsoft's Quickstart: Create a new tenant in Azure Active Directory - Create a new tenant
- When users try to log in, we receive the following error message: "invalid_request; failed to obtain an access token."
- The most likely reason for this error is an invalid or expired Azure AD Client secret. To resolve this, generate a new Client secret for your app in Azure AD, then update the Client Secret with FutureFeed.co.
Signing Key Rollover in Azure AD
The identity provider uses signing keys to sign the authentication token it issues and is used by the customer application (FutureFeed.co in this case) to validate the authenticity of the generated token.
For security purposes, Azure AD's signing key rolls periodically. If this happens, you don't need to do anything. FutureFeed.co will use the new key automatically.