Auth Sessions

​

Introduction

Auth sessions in Intuned allow you to add authentication to any browser automation task. This includes creating authenticated scrapers, automated RPA processes, or building authenticated integrations when APIs are not available.

Intuned’s auth sessions come with features that handle common authentication challenges, such as: securing credentials, solving challenges, proxy support, and more!

​

Use cases

​

Auth session types

Intuned offers two types of auth sessions. Its important to understand the differences between the two types to pick the right one for your use case.

​

Credentials-based auth Sessions

These auth sessions are created when users provide credentials to run a browser automation code that completes the authentication workflow. The credentials are also stored and when the session expires Intuned will attempt to re-authenticate with the saved credentials. From a developer point of view, the developer needs to write the authentication code but everything else is handled by Intuned. The auth session will continue to be active as long as the credentials are valid. This should be the default choice for using auth sessions in Intuned.

Unique characteristics:

• Requires providing credentials to create the auth session
• Requires Intuned to persist the credentials
• Allows for longer-lasting sessions, as they can be refreshed programmatically
• Developer needs to write the authentication code

​

Recorder-based auth sessions

Recorder-based auth sessions are created by asking the user to authenticate on a browser and then capturing the authenticated session (cookies, sessions, local storage). Recorder-based auth session allows sharing access without providing credentials. The developer has to provide some info about how the authentication works on the targeted website and Intuned will handle the rest. Creating an auth session here requires the user to be present and to authenticate to a browser session. The auth session will expire when the user’s session on the targeted website expires. When the session expires, the user must be present to re-authenticate. This type should be used when the user is not comfortable sharing their credentials or with services that have a long session time - a typical example here is LinkedIn auth.

Unique characteristics:

• Does not require users to share their credentials
• Does not require Intuned to persist the credentials
• Has a session lifetime that is dependent on the target service and typically bound to the user’s original session duration
• Developer needs to provide some info about how the authentication works on the targeted website (start url, auth final url)

​

Common features

Credentials-based and recorder-based auth sessions share the common key features including:

• lifecycle management via API or UI
• proxy support: ensure actions are coming from the same IP
• monitoring support
• Jobs and Queues support

​

Picking the right auth session type to use

Prior to starting with auth sessions, you must decide on which type you want to use for your use case, some useful questions to ask yourself:

• Are you authenticating into a target services to complete actions on behalf of your users?
• Are you authenticating into a target service on behalf of your own company to automate back-office tasks?
• Are your users comfortable sharing their credentials to access the target service?
• How frequently would your users require actions to be completed on their behalf on the target service? Are they daily/weekly scheduled tasks or on demand tasks?
• How long can you stay signed in to the target service before being prompted to enter your credentials again?
• Does the target service prompt for two factor authentication when requests are coming from a new device or new location or new browser? Do you need to use proxies with Auth Sessions?

To determine which auth session to use you can refer to the flow chart below:

​

Auth session lifecycle

One of the important aspects of dealing with auth sessions is understanding the session lifecycle: when the session has expired and recovering from that. Intuned asks developers to implement a check function (inside a check.ts file) this function should return a boolean (true/false) that indicates if the session is still valid or not. This function is called before executing any authenticated action (API). If the function returns false, Intuned will attempt to re-authenticate the session using the saved credentials (for Credentials-based auth sessions) or mark the session as expired (for Recorder-based auth sessions).

​

Credentials-based auth sessions lifecycle

• When created, the session is marked as active.
• Before executing any API call, the check.ts function is called. If the function returns false, Intuned will attempt to re-authenticate the session using the saved credentials. This is done by calling the refresh.ts API using the saved credentials.
• If the refresh.ts API fails, the session is marked as expired. Any further APIs that use this session will fail with 401 status code.
• The session state can be checked using the get session API.
• The session can be updated using the update session API - this API requires the credentials to be passed in the body - for more info check: update auth session - Start, update auth session - resume and update auth session - result.
• Any Job or Queue that uses the auth session will be paused when the auth session is marked as expired.

​

Recorder-based auth sessions lifecycle

• When created, the session is marked as active.
• Before executing any API call, the check.ts function is called. If the function returns false, the session is marked as expired.
• The session state can be checked using the get session API.
• The session can be updated - however, this process requires the user to be present to re-authenticate.
• Any Job or Queue that uses the auth session will be paused when the auth session is marked as expired.

​

Managing auth sessions

Auth sessions can be managed via the Intuned UI or via the API.

• The UI provides a simple way to create, update, and delete auth sessions. This is typically used when you are building an authenticated scraper or doing back-office automation with a limited set of auth sessions.

• The API provides a way to manage auth sessions programmatically. This is typically used when you are building an integration that has no APIs and you want to automate actions on behalf of your users (you need to provide credentials). Building a LinkedIn integration is a good example here. For API docs, you can look at the Auth Sessions API reference.

​

Learn more