Develop auth sessions

Learn how to develop projects to authenticate users and take actions on their behalf.

Before you start this document, the following is recommended:

• Understand core Intuned concepts
• Understand API and recorder generated auth sessions

The development lifecycle of auth sessions is described below:

1. Create an auth session strategy
2. Develop the auth session enabled project
3. Deploy the auth session enabled project
4. Utilize the auth session to act on behalf of users

​

Create an auth session strategy

As discussed in the overview, you must understand the scenario and select the strategy the makes the most sense to you.

​

Develop the auth session enabled project

​

Understanding the auth session capabilities in the IDE

Before developing the project you must understand what capabilities IDE exposes to develop and test auth sessions.

In the Intuned.json settings you will find auth session configuration pane. //screen shot

1. Enable auth sessions toggle, disabled by default and once enabled the project will expect auth sessions to be present for all API calls.
2. Auth session type dropdown, allows you to select your auth session strategy and is set to API generated auth session by default.

Upon enabling auth sessions and selecting the strategy new capabilities will be enabled in the IDE. //screen shot

1. Folder named ‘auth-sessions’ defines the auth workflow. The strategy will determine how much of the auth workflow will need to be defined.
2. Auth sessions dropdown manages auth sessions in IDE, and is only made available when running APIs defined in the api folder.
3. Run settings contains new controls to define auth session behavior when running APIs in the IDE
   • Check/Refresh as part of the API - match deployed behavior:
     This option allows you to emulate production behavior and ensure that the auth session check is made before executing the API, and if the check fails it will attempt to refresh as well. It is recommended to use this to test failures caught in production.
   • Load auth-session and run API - skip check/refresh:
     This option skips the check and refresh behavior that is standard in production. It is recommended to use this as you are developing the project.
   • Reuse session if open:
     This option should be selected if you’ve already authenticated in the browser session and just want to continue from where the browser is currently.

​

API generated auth session

If API generated auth is selected, then auth-sessions folder will following APIs that need to be defined:

• create.ts - needs to contain the end to end automation workflow that can navigate to the target service, enter user’s credentials, resolve any challenges, and complete authentication.
• check.ts - needs to contain a simple workflow that is able to validate that the auth session is valid.
• refresh.ts - needs to contain the workflow required to update or refresh the auth session.

Learn how to create an API generated auth session in the IDE.

​

Recorder generated auth session

If API generated auth is selected, then auth-sessions folder will only contain the following API that need to be defined:

• check.ts - needs to contain a simple workflow that is able to validate that the auth session is valid.

The create.ts API doesn’t need to be defined because the recording experience will prompt the end user to enter their credentials on a streaming browser. Upon completion of the sign in flow the auth session will be captured and the pop up browser will be closed.

The refresh.ts API doesn’t need to be defined because recorder generated auth sessions do not support refreshing expired auth sessions.

Learn how to create a recorder generated auth session in the IDE.