Sometimes your APIs are protected by different Authorization Servers. For example, all your APIs from Salesforce are protected by the Salesforce Authorization Server which require Connected Apps to allow you to use them.
Other examples exist in the wild, Google, Box, ...
The goal of Application Identity Federation is to allow you to hide this complexity from your application developers.
You can set up a trust relationship between CYM-Identity and the External Authorization Server and then leverage CYM-Identity as the only Authorization Server for your applications
The trust relationship implies that your organization owns the data of the user under protection by the External Authorization Server.
For example, a customer's personal contacts protected by Google will never be elligible for this flow. You need explicit consent of the customer before accessing that information.
Dynamic Client Registration use case.
CYM-Identity exposes an endpoint where external applications & users can register new clients.
Since CYM-Identity exposes this endpoint as an apexrest service hosted by Salesforce, it's under the protection of the Salesforce Authorization Server, which requires a connected app, a user, a profile, ...
external auth server flowHere are the steps of the flow
- The Application will make an authorization request to a CYM-Identity Realm with a specific resource parameter. The resource is protected by the community External Authorization Server
- Assuming that the user provides her consent, CYM-Identity will request to the External Authorization Server an accesstoken for the (Application, User, Scope) combination using the _Application Identity Federation flow. The External Authorization Server can grant or reject the request. In case of successful grant, it'll return an access_token to the Realm.
- The Realm will register the access_token for (Application, User, Scope, Resource) combination and will return it to the application.
- The application can therefore make an authenticated request to the Salesforce Community to create a client. The apexrest endpoint is able to authenticate the (Application, User, Scope) combination.
- After successfully creating the new client, it returns the response to the application.
The flow may seem a familiar to those of you who have use named credentials before. It's a generalization of the process. While named credentials consider your Salesforce Organization as one client, the Application Identity Federation flow allows you to provide the same capabilities to each one of the clients you have onboarded
Requirements
External Authorization Server
This flow starts by defining the External Authorization Server
Resource Server
Each authorization server can protect multiple Resource Servers. You can create as many resource servers as you need and assign the external_auth_server value
Protected Resource
Each resource server can host multiple protected resources. You can create as many protected resources as you need and assign the appropriate scopes for each.
External Client
The next step is to register a client with the External Authorization Server and get the details (client_id, client_secret, private_key, ...)
In your application detail, you can assign the external client to your application, which will allow it to start requesting access to protected resources protected by the External Auth Server.