For regulatory reasons, we require users to eSign certain data correction use cases. To ensure strong authentication, we primarily use OIDC parameters such as max_age=0 and prompt=login. While this generally works well, we’ve encountered a corner case.
In scenarios where an impersonation attempt occurs, the application correctly detects the mismatch between the originally authenticated user and the user attempting to eSign. However, there’s an unintended side effect: after the impersonation attempt, Okta updates the SSO browser session with the impersonating user’s identity, effectively hijacking the original session. This causes the application to lose context, and the SSO session along with the ID/Access tokens fall out of sync.
Question:
Is there a better way to isolate the eSignature flow to ensure that the original authenticated session remains intact—even in the event of an impersonation attempt?
As a workaround, we are currently forcefully logging out the user to clear the hijacked session cookies.
Appreciate any ideas or suggestions you might have.
What you are describing is expected behavior. If you use the same browser with an authorization request against the same IdP tenant, the existing session is replaced. This is not just an Okta thing, this is almost every Web app since 1993. Normally you wouldn’t be able to re-authenticate and override the existing session as the user is already logged in, but your use of OIDC parameters may allow that to happen. This applies to trying to do it in an iframe too, because same-origin cookies will be shared.
Can you describe more about the eSignature flow for me and maybe I can see any potential solutions that could help you? The most important thing, is why do you have to re-authenticate the user for the eSignature. Why isn’t it the same user?
The primary purpose of eSignature functionality stems from the requirements outlined in Electronic Clinical Records, 21 CFR Part 11, which mandates that any amendments to original records must be electronically signed. When a clinical user modifies or updates data, they are already logged into the application. During the eSignature process, the app performs a forced re-authentication to verify the user’s identity. If the identity matches, the amendment is marked as complete.
However, consider a scenario where the user possesses a second set of credentials and attempts to impersonate another identity solely for the eSignature. In such cases, our goal is to fail only the eSignature step, display a failure message to the user, and allow them to continue using the application with their original session.
This process assumes the user is the same individual who initiated the session. Yet, there’s a slight possibility—either due to selecting the wrong credentials from a credential manager or intentionally using another set—that the identity verification fails. In such cases, we want to preserve the original session context without disrupting the user’s workflow.
Currently, as a protective measure, the application logs the user out upon detecting an impersonation attempt, effectively terminating the session. It would be ideal to explore alternative approaches that maintain session integrity without forcing a logout.
Gotcha. I am assuming that you are not requiring MFA, but I would strongly encourage it and I’ll start there and work backward.
If you require MFA then you want to use acr_values and trigger a request from the application for step-up authorization for the signature. You can tie this to a expiration time, like five minutes. Their Okta session will revert, and they need to repeat the process again for another signature. Performing step-up will meet the authentication requirements for ECR. Here is a link to a document that describes it: https://developer.okta.com/blog/2023/03/08/step-up-auth.
Regardless of MFA, you must follow what I am about to describe anyway because a user could be forced to log in again if their Okta session:
You have taken some steps on the correct path. To satisfy ECR without MFA you must force a new login. A new login will always result in a new Okta session. But that also means that you have a new identity token returning to the application.
In the application authorization callback handler, you need to check the new id token against the current user session. If it is the same user, proceed. If it is a different user, dump the context for the current user and create a new context for the new user. Personally, I would delete and create a new user session for the application with the new identity just to be safer, no data leakage. Then dump the user at the application landing page forgetting about any flows in progress. They are the ones who made the mistake, they must start over. If they are a legitimate user, they will figure it out. Probably they will assume their session expired.
DO NOT tell them why they are starting over. If the application session was hijacked (that is a security problem on your side), telling them why you are doing this reveals information about how your application works and gives the bad folks a foothold for building an exploit.
Indeed, MFA is out scoped for eSignature alone, but for federated users, auth policies on their respective IdPs will apply, Okta cannot influence much.
telling them why you are doing this reveals information about how your application works and gives the bad folks a foothold for building an exploit.