Add a Confidential Application

You can use Oracle Identity Cloud Service to add a confidential application. Confidential applications run on a protected server.

  1. In the Identity Cloud Service console, expand the Navigation Drawer, and then click Applications.
  2. Click Add.
  3. In the Add Application page, click Confidential Application.
  4. In the Add Confidential Application wizard's Details page, in the App Details Section, use the following table to configure application details and the display settings.
    Option Description
    Name

    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 your application names as short as possible.

    Description

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

    Application Icon

    Click Upload to add an icon that represents the application. This icon appears next to the name of the application on the My Apps page and the Applications page.

    Application URL

    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. HTTP should only be used for testing purposes.

    Custom Login URL

    In the Custom Login URL field, specify a custom login URL. However, if you are using a default login page provided by Oracle Identity Cloud Service, then leave this field blank.

    Custom Logout URL

    In the Custom Logout URL field, specify a custom logout URL. However, if you are using a default login page provided by Oracle Identity Cloud Service, then leave this field blank.

    Custom Error URL

    This is an optional field. Enter the error page URL to which a user has to be redirected, in case of a failure. If not specified, the tenant specific Error page URL will be used. If both the error URLs are not configured, then the error will be redirected to the Oracle Identity Cloud Service Error Page (/ui/v1/error).

    When a user tries to use social authentication (ex: Google, Facebook, and so on) for logging into Oracle Identity Cloud Service, the callback URL must be configured in the Custom Error URL field. Social providers need this callback URL to call Oracle Identity Cloud Service and send the response back after social authentication. The provided callback URL is used to verify whether the user exists or not (in the case of 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 does not exist in Oracle Identity Cloud Service.

    Linking callback URL

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

    When you create a custom app using Oracle Identity Cloud Service custom SDK and integrate with Oracle Identity Cloud Service 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 Oracle Identity Cloud Service is complete.

    Tags

    Click Add Tag to add tags to your confidential applications to organize and identify them. See Adding Tags to an Application.

    Display in My Apps

    Select the check box 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 check box in applications, the app is then visible in the My Apps page, but selecting this check box doesn’t enable or disable SSO to the app.

    The flag to enable or disable SSO comes from the app template. Use the Oracle Identity Cloud Service REST APIs to update this flag. You cannot set the SSO flag from the UI. See REST API for Oracle Identity Cloud Service.

    User can request access

    Select the check box 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 is not enabled, users won’t see the Add Access button.

  5. At the top of the Add Confidential Application wizard's Details page, click Next.

    A confirmation message indicates that the application has been added in a deactivated state.

  6. On the Add Confidential Application wizard's Client page:
    • To skip configuring authorization for your application at this time:
      1. Click Skip for later.
      2. Continue with step 7 below.
    • To configure authorization information for your application now:
      1. Click Configure this application as a client now.
      2. In the Authorization and Token Issuance Policy sections that open, use the following table to fill in the information.
    Option Description
    Resource Owner Use when the resource owner has a trust relationship with the confidential application, such as a computer operating system or a highly privileged application, because the confidential application must discard the password after using it to obtain the access token.
    Client Credentials

    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

    JWT Assertion

    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.

    SAML2 Assertion

    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.

    Refresh Token Select this grant type when you want a refresh token supplied by the authorization server, and then use it to obtain a new access token. Refresh tokens are used when the current access token becomes invalid or expires and don’t requiring the resource owner to reauthenticate.
    Authorization Code

    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.

    Implicit

    If the application can't keep client credentials confidential for use in authenticating with the authorization server, then select this check box. 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).

    Device Code

    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 cannot 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.

    TLS Client Authentication

    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.

    Optional For added security, before enabling the TLS Client Authentication grant type, enable and configure OCSP validation and import a trusted partner certificate. See Enable X.509 Certificate Authentication and Import a Trusted Partner Certificate.

    Allow non-HTTPS URLs

    Select this check box if you want to use HTTP URLs for the Redirect URL, Logout URL, or Post Logout Redirect URL fields. For example, if you are 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 check box when you are developing or testing your application and you may not have configured SSL. This option is provided as a convenience and is not recommended for production deployments.

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

    Note:

    Provide an absolute URL. Relative URLs are not supported.
    Logout URL

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

    Post Logout Redirect URL

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

    Client Type

    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.

    Allowed Operations
    • Select the Introspect check box if you want to allow access to a token introspection end point for your application.

      If the confidential application can't keep client credentials confidential for use in authenticating with the authorization server, then select this check box. For example, your confidential 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 code).

    • Select the On behalf Of check box if you want to ensure that access privileges can be generated from the user's privileges alone. This allows the client application to access endpoints to which the user has access, even if the client application by itself would not normally have access.

    ID Token Encryption Algorithm

    Choose one of the available content encryption algorithms so that id tokens passed through third parties, such as browsers, are encrypted.

    The default is none.
    • You can also set the parameter from /App endpoint by passing idTokenEncAlgo with the appropriate algorithm.
    • You can set this parameter for confidential and enterprise applications. (You cannot set it for mobile applications.)
    Bypass Consent

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

    Allowed Client IP Address
    Prerequisites:
    Set one of the following options for the allowed client IP address.
    • Anywhere - The token request is allowed from anywhere. There is no perimeter.
    • In one or more of these network perimeters - Select the network perimeters so that a token request is only allowed from them.
    Authorized Resources

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

    Note:

    The option to define an authorized resource is available to only confidential applications. Mobile applications don't have the option to define a trust scope.

    See Account Trust Scope for additional scope information as well as request and response examples for use with the Oracle Identity Cloud Service REST APIs.

    Tags

    Note:

    Tags are available only when you select the Tagged option. It remains hidden for the other two Authorized Resource options.

    Click Tagged to enable your confidential application to access tags from other applications. See Adding Tags to an Application.

    Resources

    If you want your application to access APIs from other applications, then click Add in the Token Issuance Policy section of the Add Confidential Application page. 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.
    Grant the client access to Identity Cloud Service Admin APIs

    Click Add to enable your confidential application to access Oracle Identity Cloud Service APIs.

    In the Add App Role 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 clicking the x icon for the row of the required application role.

    Note:

    You can’t delete protected application roles.

    See Apps/App Roles endpoint for a complete list of which endpoints each application role can access.

  7. Click Next.
  8. On the Add Confidential Application wizard’s Resources page:
    • To specify that no resources of your confidential application will be protected by OAuth 2.0, or to protect them at a later time:
      1. Click Skip for later.
      2. Continue with step 9 below.
    • To protect resources for your application now, and to make the application visible on the My Apps page:
      1. Click Configure this application as a resource server now.
      2. Use the following table to fill in the information in the Configure application APIs that need to be OAuth protected section that opens.
    Option Description
    Access Token Expiration

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

    Is Refresh Token Allowed

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

    Refresh Token Expiration

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

    Primary Audience

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

    Secondary Audiences

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

    Add (Allowed Scopes)

    To specify which parts of other applications that you want your application to access, click this button to 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.

  9. Click Next.
  10. On the Add Confidential Application wizard’s Web Tier Policy page, click Next.
  11. On the Add Confidential Application wizard’s Authorization page, if you want Oracle Identity Cloud Service to control access to the application based on grants to users and groups, select the Enforce Grants as Authorization check box.
    • Selected: Users can access the application only if you assign or grant access.
    • Unselected: Any authenticated user has access to the application.
  12. Click Finish.
    The application has been added in a deactivated state.
  13. Record the Client ID and Client Secret that appear in the Application Added dialog box.
    To integrate with your confidential application, use this ID and secret as part of your connection settings. The Client ID and Client Secret are equivalent to a credential (for example, an ID and password) that your application uses to communicate with Oracle Identity Cloud Service.
  14. Click Close.

    The new application’s details page is displayed.

  15. At the top of the page, to the right of the application name, click Activate.
  16. In the Activate Application? dialog box, click Activate Application.