Skip to content

Authenticate an External Integration to IFS Cloud

Secure integration with external systems is paramount in IFS Cloud. This is why IFS Cloud supports the OAuth2 protocol to facilitate secure connections between your internal systems and external services. This document outlines the available options and special considerations for a smooth and seamless integration experience.

Guide for Integrations

Before you begin, ensure that you understand the authentication requirements of the external service. It may use various authentication methods. As IFS supports the OAuth2 protocol for authentication, make sure to choose an appropriate authentication method depending on the capabilities of the external service.

First, create a new IAM Client. The IAM Client configuration will be based on the chosen Authentication method.

Setting up a Custom IAM Client

A custom IAM Client can be registered for different authentication needs in Solution Manager > Users and Permissions > Identity and Access Manager > IAM Clients page.

Client ID: Unique ID for the client. A Client ID can contain any alphanumeric character and the maximum length should be 20 characters.

Enabled: Indicates whether the client is enabled or not

Type: This is a read only parameter and the value will be Custom Client

Description: A brief description of the client

Public Client: If enabled, the newly created client will be a public client and if disabled it will be a confidential client

Service Accounts: If enabled, a service user will be created in IAM along with the IAM client. This needs to be enabled to use the Client Credential flow. The service account name is auto-generated as service-account- < client_id >

If Create IFS Service User is enabled, an IFS Service User will be created with the service account name as the Directory ID and Client ID as the Identity.

Direct Access Grants: This needs to be enabled to use the Resource Owner Password Credentials Flow

Note: If the client application has a way to securely store a secret, then it should be a Confidential Client and be set up with a client secret. If not, it should be a Public Client. A piece of software is able to securely store a client secret if it has a server-side component that is used to exchange the one-use code for a token. Natively installed apps and single-page browser apps are not able to securely store a client secret and should as such opt for a public client instead. Since public clients do not use client secrets to secure the token endpoint, it is highly recommended to use a standard called Proof Key For Code Exchange or PKCE.

Sample IAM client for authorization code flow

Sample IAM client for client credentials flow

Sample IAM resource owner password credentials flow

Setting up redirect URI

The use of redirect URIs depends more on the actual integration because they are registered to the IFS IAM using Solution Manager when the IAM client is created. If there is application support for OAuth2 then the documentation of that support will describe which redirect URIs will have to be registered. For confidential clients redirect URIs are handled by pointing it to a location on the server side parts of the client application that can consume the one-use code and contact the token endpoint for an access token. For a public client, there may not be a location on the server that can receive the redirection response. If the client is a single page browser app, then it is likely to do something very similar to what a confidential app would have done, meaning to have the redirect URI point to a place in the single page app and then have the client side JavaScript handle the request to the token endpoint. If the application is a natively installed app there are other ways to go about it. The specification regarding how to design OAuth2 for native apps has a section that describes different strategies for handling native apps.

If you are able to use a library to implement support in a native app, this library's documentation will likely say what redirect URIs to use for the library.

Sample 1: A confidential client with web URI as the redirect URI

Sample 2: A public client with a private URI scheme pattern redirect URI which can be used with a native app

Supported Authentication Flows

We support the following Authentication Flows: