How Does the Identity Propagation Authentication Method Work?

Authentication methods that use identity propagation pass the identity of the logged in user to the service for authentication.

To use identity propagation, the service must be able to understand the IDCS identity token coming from Visual Builder and extract the user (or subject) from it. Visual Builder supports JWT tokens issued by IDCS procured using OAuth 2.0-user assertion flows.

Tokens are a way of encoding the calling user identity into a string according to different specifications, like SAML or the JWT format. For example, if the user is John.Doe, the corresponding JWT token takes the format <header.body.signature> and looks like this:

Description of auth-jwt-token.png follows

Description of the illustration auth-jwt-token.png

Decoding the body of the token reveals details about the user identity and possibly the resources to which that user is allowed access. The signature part is encrypted by the authority that authenticated the user, and can be easily verified by using the authority's public key. A valid user's identity is encoded into the token so services (namely REST APIs) that receive this token can consider the user as authenticated. This token is usually passed to REST services by passing it as a "Bearer <token>" in the Authorization header.

Here are the authentication methods that use identity propagation:

Authentication method Description

Authentication method	Description
Oracle Cloud Account	Select this method to communicate with Oracle Cloud Applications services. When you select this method, the user must sign in with the credentials of a valid account in the Oracle Identity Cloud Service (IDCS) associated with Visual Builder. The user's identity is converted into a user assertion, then into an IDCS-issued JWT token for the scope that is equivalent to the base URL of the service being called. For example, if the service's URL is `https://fa.oraclecloud.com/myservice`, the token is created for the scope of `https://fa.oraclecloud.com`.
OAuth 2.0 User Assertion	Select this method to call an external system's services that can be represented as a resource app with a particular scope in Oracle Identity Cloud Service (IDCS). This also requires the user to sign with a valid Oracle Identity Cloud Service user account. As with Oracle Cloud Account authentication, the user's identity is first converted into an assertion, then into an IDCS-issued JWT token for the configured scope. The difference is that with this method you can specify your own scope, rather than using the service's URL.
Delegate Authentication	This method was previously called Propagate Current User Identity. With this method, the service connection doesn't have its own authentication, but delegates the authentication to the web (or mobile) app that is calling it. The following apply: A web app can only use the Oracle Cloud Account option for its security (set with web app > Settings > Security). When the service is called from a web app, by default, Oracle Cloud Account authentication applies. The user's identity is converted into an assertion, then into an IDCS-issued JWT token. If the web app has the "Enable implicit grant for Service Connections" option enabled, the resulting JWT token is procured by an OAuth 2.0 implicit grant flow instead of through an assertion. If the service is called from the Service Tester (from the Service Connection's Test tab), the identity of the user that's logged into Visual Builder is converted into a token and passed to the service. This is similar to what is done with Oracle Cloud Account authentication. Since the actual authentication used at runtime depends on the calling web app's security settings, it is only recommended for use with web apps that use OAuth-based implicit grant authentication.

Oracle Cloud Account

Select this method to communicate with Oracle Cloud Applications services. When you select this method, the user must sign in with the credentials of a valid account in the Oracle Identity Cloud Service (IDCS) associated with Visual Builder. The user's identity is converted into a user assertion, then into an IDCS-issued JWT token for the scope that is equivalent to the base URL of the service being called. For example, if the service's URL is https://fa.oraclecloud.com/myservice, the token is created for the scope of https://fa.oraclecloud.com.

OAuth 2.0 User Assertion

Select this method to call an external system's services that can be represented as a resource app with a particular scope in Oracle Identity Cloud Service (IDCS). This also requires the user to sign with a valid Oracle Identity Cloud Service user account. As with Oracle Cloud Account authentication, the user's identity is first converted into an assertion, then into an IDCS-issued JWT token for the configured scope. The difference is that with this method you can specify your own scope, rather than using the service's URL.

Delegate Authentication

This method was previously called Propagate Current User Identity.

With this method, the service connection doesn't have its own authentication, but delegates the authentication to the web (or mobile) app that is calling it. The following apply:

A web app can only use the Oracle Cloud Account option for its security (set with web app > Settings > Security). When the service is called from a web app, by default, Oracle Cloud Account authentication applies. The user's identity is converted into an assertion, then into an IDCS-issued JWT token. If the web app has the "Enable implicit grant for Service Connections" option enabled, the resulting JWT token is procured by an OAuth 2.0 implicit grant flow instead of through an assertion.
If the service is called from the Service Tester (from the Service Connection's Test tab), the identity of the user that's logged into Visual Builder is converted into a token and passed to the service. This is similar to what is done with Oracle Cloud Account authentication.

Since the actual authentication used at runtime depends on the calling web app's security settings, it is only recommended for use with web apps that use OAuth-based implicit grant authentication.