Adding a Confidential Application

Enter a name for the confidential application. You can enter up to 125 characters.

For applications with lengthy names, the application name appears truncated in the My Apps page. Consider keeping application names as short as possible.

Enter a description for the confidential application. You can enter up to 250 characters.

Click the close (X) in the Application icon window to delete the default Application icon and then add your own icon for the application. This icon appears next to the name of the application on the My Apps page and the Applications page.

Enter the URL (HTTP or HTTPS) where the user is redirected after a successful login. This value is also known as the SAML RelayState parameter. HTTPS format is suggested. Only use HTTP for testing purposes.

For Enterprise applications, the application URL is the URL that you want users to use to access your enterprise application. Use the host name and port number of the App Gateway. If you have multiple instances of App Gateway, then use the host name and port number of the load balancer.

In the Custom sign-in URL field, specify a custom sign-in URL. However, if you're using a default login page provided by IAM, then leave this field blank.

In the Custom sign-out URL field, specify a custom sign-out URL. However, if you're using a default login page provided by IAM, then leave this field blank.

This is an optional field. Enter the error page URL to which a user has to be redirected, if there's a failure. If not specified, the tenant-specific Error page URL is used. If both the error URLs aren't configured, then the error is redirected to the IAM Error Page (/ui/v1/error).

When a user tries to use social authentication (ex: Google, Facebook, and so on) for logging into IAM, the callback URL must be configured in the Custom Error URL field. Social providers need this callback URL to call IAM and send the response back after social authentication. The provided callback URL is used to verify whether the user exists or not (if this is a first-time social login), and display an error if the social authentication has failed. This is the URL where the callback is sent with social registration user details, if a successful logged-in social user account doesn't exist in IAM.

This is an optional field. Enter the URL that IAM can redirect to after linking of a user between social providers and IAM is complete.

When you create a custom app using IAM custom SDK and integrate with IAM Social Login, the custom app needs to have the Linking callback URL which can be redirected after linking of the user between social provider and IAM is complete.

Select the checkbox if you want the confidential application to be listed for users on their My Apps pages. In this case, you need to configure the application as a resource server.

When you select the Display in My Apps checkbox in applications, the app is then visible in the My Apps page, but selecting this checkbox doesn't enable or disable SSO to the app.

The flag to enable or disable SSO comes from the app template.

Select the checkbox if you want end users to be able to request access to the app from their My Apps page by clicking Add Access. If self-service isn't enabled, users won't see the Add Access button.

For Confidential apps: Enforce grants as authorization

For Enterprise apps: User must be granted this app

If you want IAM to control access to the application based on grants to users and groups, select this option. If you clear this option, any authenticated user has access to the application.

Define how long (in seconds) the access token associated with your confidential application remains valid.

Select this checkbox if you want to use the refresh token that you obtain when using the Resource Owner, Authorization Code, or Assertion grant types.

Define how long (in seconds) the refresh token, which is returned with your access token and is associated with your confidential application, remains valid.

Enter the primary recipient where the access token of your confidential application is processed.

Enter the secondary recipients where the access token of your confidential application is processed, and click Add. The secondary recipient appears in Secondary audience column, and the Protected column allows you to know whether the secondary audience is protected or not.

To specify which parts of other applications that you want your application to access, add those scopes to your confidential application.

Applications must interact securely with external partner or confidential applications. Also, applications from one Oracle Cloud service must interact securely with applications in another Oracle Cloud service. Each application has application scopes that determine which of its resources are available to other applications.

Use when the authorization scope is limited to the protected resources under the control of the client or to the protected resources registered with the authorization server.

The client presents its own credentials to obtain an access token. This access token is either associated with the client's own resources, and not a particular resource owner, or is associated with a resource owner for whom the client is otherwise authorized to act

Use when you want to use an existing trust relationship expressed as an assertion and without a direct user approval step at the authorization server.

The client requests an access token by providing a user JSON web token (JWT) assertion or a third-party user JWT assertion and client credentials. A JWT assertion is a package of information that facilitates the sharing of identity and security information across security domains.

Use when you want to use an existing trust relationship expressed as a SAML2 assertion and without a direct user approval step at the authorization server.

The client requests an access token by providing a user SAML2 assertion or a third-party user SAML2 assertion and client credentials. A SAML2 assertion is a package of information that facilitates the sharing of identity and security information across security domains.

Select this grant type when you want to obtain an authorization code by using an authorization server as an intermediary between the client application and resource owner.

An authorization code is returned to the client through a browser redirect after the resource owner gives consent to the authorization server. The client then exchanges the authorization code for an access (and often a refresh) token. Resource owner credentials are never exposed to the client.

If the application can't keep client credentials confidential for use in authenticating with the authorization server, then select this checkbox. For example, your application is implemented in a web browser using a scripting language such as JavaScript. An access token is returned to the client through a browser redirect in response to the resource owner authorization request (rather than an intermediate authorization).

Select the Device Code grant type if the client doesn't have the capability to receive requests from the OAuth Authorization Server, for example, it can't act as an HTTP server such as game consoles, streaming media players, digital picture frames, and others.

In this flow, the client obtains the user code, device code, and verification URL. The user then accesses the verification URL in a separate browser to approve the access request. Only then can the client obtain the access token using the device code.

Select the TLS Client Authentication grant type to use the client certificate to authenticate with the client. If a token request comes with an X.509 client certificate and the requested client is configured with the TLS Client Authentication grant type, the OAuth service uses the Client_ID in the request to identify the client and validate the client certificate with the certificate in the client configuration. The client is successfully authenticated only if the two values match.

For added security, before enabling the TLS Client Authentication grant type, enable and configure OCSP validation and import a trusted partner certificate.

Select this checkbox if you want to use HTTP URLs for the Redirect URL, Logout URL, or Post logout redirect URL fields. For example, if you're sending requests internally, want a non-encrypted communication, or want to be backward-compatible with OAuth 1.0, then you can use an HTTP URL.

Also, select this checkbox when you're developing or testing your application and you might not have configured SSL. This option isn't recommended for production deployments.

Enter the application URL where the user is redirected after authentication.

Note: Provide an absolute URL. Relative URLs aren't supported.

Enter the URL where you want to redirect the user after logging out of the application.

Enter the URL where the user is redirected after logging out of the confidential application.

Select the client type. The available client types are Trusted and Confidential. Choose Trusted if the client can generate self-signed user assertions. Then, to import your signing certificate that the client uses to sign its self-signed assertion, click Import certificate.

Select one of the content encryption algorithms.

If enabled, this attribute overwrites the Require consent attribute for all the scopes configured for the application, and then no scope will require consent.

Select one of the following options to allow a client application to access authorized resources:

• All – Access any resource within a domain (All). See Accessing All Resources.

• Specific – Access only those resources where an explicit association between the client and the resource (Specific) exists. See Accessing Resources With Specific Scopes.

Note: The option to define an authorized resource is available to only Confidential applications. Trust scope can't be defined for Mobile applications.

If you want your application to access APIs from other applications, then check Add resources in the Token issuance policy section. Then, in the Add scope window, select the applications that your application references.

Note: You can delete scopes by clicking the x icon next to the scope. However, you can't delete scopes that are protected.

Check Add app roles. In the Add app roles window, select the application roles that you want to assign to this application. This enables your application to access the REST APIs that each of the assigned application roles can access.

For example, select Identity Domain Administrator from the list. All REST API tasks available to the identity domain administrator will be accessible to your application.

You can delete the application roles by selecting the application role and then clicking Remove.

Note: You can't delete protected application roles.