<iframe src="https://www.googletagmanager.com/ns.html?id=GTM-M74D8PB" height="0" width="0" style="display:none;visibility:hidden">
Loading
Skip to NavigationSkip to Main Content
How to Properly Identify Inactive Users Using Okta Workflows for IdP or SP Initiated Login
Workflows
Overview

Okta updates the Last Login field for the Okta Dashboard application only if the user logs into the Okta Dashboard. If the user only performs Service Provider (SP) -initiated logins to other applications, the Okta Dashboard Last Login field is not updated.

Applies To
  • Okta core
  • Okta Workflows
Cause

The Last Login field for Okta Dashboard application is only updated upon User Login to Okta Dashboard application.

Solution

If a user logs into Okta via an Identity Provider (IdP)-initiated event, the Last Login gets updated because the user is logging in to the Okta Dashboard application. Modify the "Identify Inactive Okta Users" template, and this will work properly.

Solution SP-Initiation

  1. If a user logs in via SP-Initiated events, the Last Login for the Okta Dashboard application does not get updated. Build a process that looks in the System log to find authentication events and update a custom attribute (for example).

  2. Then, either modify the "Identify Inactive Okta Users" template PARENT to use the custom attribute to only pass users whose custom attribute is older than (x) or create a workflow to process inactive users.


Example parent flow to update custom attribute (retrieves events from yesterday for user.session.start (IdP login) or user.authentication.sso (SP-initiated) and STREAMS the system log events to a helper flow):

EXAMPLE PARENT FLOW


Example helper flowupdate custom attribute (updates a custom attribute based on the published event date/time):

EXAMPLE HELPER FLOW

 

Related References

Loading
How to Properly Identify Inactive Users Using Okta Workflows for IdP or SP Initiated Login