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

Before you start this document, the following is recommended:

Creating an auth session

To create an auth session the following must be prepared:

  • [Required] Access to user credentials, ether it is stored or the user is present
  • [Optional] Proxy to the location you wish to have the user authenticate from

Intuned supports two methods to create an auth session Intuned Client APIs and Intuned Portal.

Intuned Client APIs is generally recommended to be used in production. Especially when you are building a custom user experience to allow your users to capture and manage their auth sessions within your service.

Learn how to create auth sessions using APIs:

Intuned Portal is generally recommended to be used in testing. It can also be used if you’re automating back-office tasks.

Learn how to create auth sessions using Intuned Portal:

Utilizing auth Sessions

Calling an API in an project with auth sessions enabled requires an auth session to be present. Prior to executing any APIs, Intuned will check if the auth session is valid by attempting to call the auth-sessions/check API that is defined in the project.

After creating an auth session, it must be included in input payload of the direct API calls. If jobs or queues are being configured on an project with auth sessions enabled then the configuration must include auth session as well.

Learn how to utilize auth sessions:

Managing auth session

Proxies

An auth session can be configured with a proxy to ensure all actions are showing up from the same IP address. Proxies are not required to use auth sessions but is commonly used if the target service has forces two factor authentication when detecting different user behavior.

Once an auth session is configured with a proxy all API calls with this auth session will be routed via the proxy so if the proxy fails the API calls will fail as well. If there are failures in the proxy, you can update the proxy configured on an auth session.

Auth session states

An auth session may fall into one of the following states:

  • Ready - Upon successful creation an auth session remains in this state until it no longer valid.
  • Expired - Auth session reaches this state once the auth session check fails. To fix an expired auth session you can simply update the auth session.

The state diagrams below show the state for auth sessions:

Updating auth sessions

Once an auth session has been created, it should serve as the only auth session instance for that user/service pairing. For example is Sam created an auth session for Service A with the id sam-sA-sessionthen this auth session should be maintained and updated by you. This means that you must update and maintain the auth session for the duration you need it.

Learn how to update auth sessions