How to interpret non-interactive user sign-ins?

Kiril 

Non-interactive user sign-ins are sign-ins that are performed by a client app or an OS component on behalf of a user. These sign-ins don't require any interaction or authentication factor from the user. For example, authentication and authorization using refresh and access tokens that don't require a user to enter credentials.

Below are some of the examples when non-interactive sign-in gets triggered,

• A client app uses an OAuth 2.0 refresh token to get an access token.
• A client uses an OAuth 2.0 authorization code to get an access token and refresh token.
• A user performs single sign-on (SSO) to a web or Windows app on an Azure AD joined PC.
• A user signs in to a second Microsoft Office app while they have a session on a mobile device using FOCI (Family of Client IDs).

ddasari Kiril 

I think where you're both getting confused (noting that Kiril posted this in 2023 and may not be following it anymore) is that you're thinking both the interactive and non-interactive logs (using the initial screenshots from Kiril for context) relate directly to the user, which is actually not the case.

Let's set some context first.

There's actually two separate "things" logging in here:

1. The user, as per the interactive logins screen;
2. The application (Microsoft App Access Portal, via something called a servicePrincipal), as per the non-interactive logins screenshot.

Next, let's break the whole "authentication" process down into separate "flows":

1. Authentication from the actual person to the Microsoft App Access Portal; which triggers:
2. Authentication from the Microsoft App Access Portal (again, using its servicePrincipal) to whatever the target resource is (the Resource column is not shown in the screenshots)

Now, we have something like this:

The first flow (steps 1 and 2) is the user authentication, which as shown in the interactive logs is failing. This failure is desired and all that actually matters in this particular scenario.

The knock-on effect of the user attempting to log in is that the application then tries to log into the remote resource (aka impersonate) as that user (as shown in steps 3 and 4). This is not the same thing at all as the actual user login shown in steps 1 and 2. To reiterate, it's the app trying to log in, which will likely be successful, but on its own, does not afford the user access to the application.

So, what you're seeing across both logs is absolutely expected and not automatically a security issue.

This particular two-leg authentication process is actually quite common and even applies to sensitive resources such as Azure SQL MI, meaning you will see non-interactive logins succeeding for users you expect not to have access.

The key thing is to pay attention to the application as well as correlating the timestamps across interactive versus non-interactive. If the correlating interactive login has failed then you have nothing to worry about.

Conversely, if for a given user and timestamp of a successful login for the non-interactive log has no matching login attempt (i.e. success or failure) in the interactive, you may need to investigate further (initially by back-tracking in the interactive log for the last attempt from that username to the matching application name).

But for the screenshots in the initial post, everything needed to answer the question is contained across both logs.

As a side note, you will also see non-interactive logins for which there are no interactive matches. (app-only access) These relate to non-interactive processes and you will get a feel for which applications these are expected the more you see the log.

You can read more about delegated (which typically features in both interactive and non-interactive logs) versus app-only (non-interactive log only) access here:

• Overview of permissions and consent in the Microsoft identity platform - Microsoft identity platform | Microsoft Learn

Cheers,

Lain