Protecting Native Applications using Adaptive Access

IBM Security Adaptive Access can be used to protect web applications that are developed natively (i.e. where the complete user experience is managed by the application). Using Adaptive access, you can quickly secure your native application against attackers, introducing MFA as required, without increasing friction for the bulk of your users.

If your web or mobile application supports either OIDC or SAML federated single sign on, see Adaptive Access - Single Sign On

In this flow, the Adaptive access context/risk collection capabilities and entire authentication experience is performed by your application in conjunction with the Adaptive Access SDKs. This is most common for scenarios where the application is used in isolation of a common authentication point (central IdP). This can be essential in CIAM use cases, or for bespoke core business applications which require a highly tuned user experience.

To get started see the Onboarding-Native-Apps section.

Lets understand the different entities which are involved when deploying a native application. There are three to be aware of:

• IBM Security verify
• The application server
• The client application

Each of these fulfils a specific role when implementing Adaptive access for native applications. The following diagram shows the relationship between the entities.

IBM Security Verify

IBM Security Verify(ISV) is the engine which provides the Adaptive access capability which is built on standard OAuth 2.0 / OpenID Connect principals.

When deploying a native application, the application server will contact ISV in order to obtain an access token for the application to use. This access token will only be issued once all policy requirements configured on the application are fulfilled, which may require multi-factor-authentication to be performed based on the risk assessment provided by the Adaptive access capability.

In this scenario, interaction with ISV is purely API driven, with the developer integrating their application server with the provided APIs to enrich their authentication capabilities.

For more information on calling ISV APIs to asses policy see the Knowledge Centre topics.

The Application Server

The application server in this scenario hosts the application logic which the end user is trying to consume. This scenario allows the application server to offload many traditional authentication requirements to ISV, instead consuming the standards based API mentioned. These APIs allow the application to establish a user session, prompt for additional authentication. By using the ISV APIs the application no longer has to manage:

• A user repository
     - ISV Cloud-directory is used as the backing store
• Audit of login events
     - Records of authentication are provided by the ISV reports
• Implementation of multi factor methods
     - There are off the shelf APIs for achieving basic and advanced authentication scenarios such as email one time password or modern and frictionless FIDO2

When deploying an application using this API for adaptive authentication, the IBM Proxy SDK for Adaptive Access can be used to simplify and streamline integration with the ISV APIs.

The Client Application

The client application has a session established with its application server and it is this session which is being protected and enriched using ISV Adaptive access. In order to do this, an adaptive SDK needs to be deployed into the client application. This SDK assists with session management, and integrates with the login and authentication flows of the application.

The Browser SDK is available here

---

Understanding the architecture

The above helps us understand the different entities within a deployment of ISV Adaptive access for native applications. Lets reiterate:

1. The native application which interacts with the user
   - Embeds the Adaptive SDK for Web
   - Wishes to call APIs with an access_token either from the application, or using a session from the application server
      - This access token is validated by the resource server using OAuth token introspection
   - Does not call ISV directly
2. The application server which the app operates with
   - Is the OIDC client which is registered with IBM Security Verify
      - It is issued a client_id and client_secret
   - Hosts the application which the end user is using
   - Calls ISV APIs to get an access token for the native application to use
   - Hosts APIs which are secured using OAuth 2.0 bearer token usage
     - The ISV token introspection endpoint is used to make authorization decisions.
3. IBM Security Verify
   - Provides authentication, authorization, MFA and audit capabilities using a standards driven API.
   - Used to onboard the application
      - Issues a client_id and client_secret
   - Issues access and refresh tokens to the application server
   - Is where access policy is authored

Where to next?

• Onboard an application
• Follow the steps on deploying a native application