Adaptive SDK

Introduction

IBM Security Verify 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 for Single Sign On.

In this flow, the Adaptive access context/risk collection capabilities and entire authentication experience is performed by your application using the IBM Security Verify AdaptiveSDK. 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 On-boarding a native application.

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.

Components

IBM Security Verify

IBM Security Verify 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 IBM Security Verify 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 IBM Security Verify 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 IBM Security Verify APIs to assess 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 IBM Security Verify, instead consuming the standards based API mentioned. These APIs allow the application to establish a user session, prompt for additional authentication. By using the IBM Security Verify APIs the application no longer has to manage:

A user repository

• IBM Security Verify Cloud Directory is used as the backing store

Audit of login events

• Records of authentication are provided by the IBM Security Verify 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 Adaptive Proxy SDK can be used to simplify and streamline integration with the IBM Security Verify APIs. It is also available for inclusion in NodeJS projects via npm.

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 IBM Security Verify Adaptive access. In order to do this, the Adaptive SDK needs to be deployed into the client application.

The Adaptive Browser SDK assists with session management, and integrates with the login and authentication flows of the application. It is also available for inclusion in NodeJS projects via npm.

Understanding the architecture

The above helps us understand the different entities within a deployment of IBM Security Verify Adaptive access for native applications. Let's reiterate:

1. The native application which interacts with the user
   • Embeds the Adaptive Browser SDK
   • 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 IBM Security Verify 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 IBM Security Verify 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 IBM Security Verify 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