SSPR allows the use of one or more verification methods as part of the forgotten password process.

Problem is that they are inconsistent with regards to how well they persist the LDAP profile that was successfully used to match the user's initial input (pre verification) with an object in a configured user store (LDAP profile) 

Scenario: SSPR configured with different LDAP profiles match different tenants

A given identity can exist in multiple tenants (different relationship, student, employee or simply employed at two different companies at same time)

User goes to forgotten password and enters in the form stuff they know like, CN, Surname, Given name.

Since CNs are unique across tenants, SSPR finds just one match and proceeds to verification methods.

Preferred verification method is to send them to a Government IDP (OAUTH2) where they prove who they are in a highly secure manner, and the endpoint returns back an ID that is unique for that person. For simplicity, lets call it social security number.

In each tenant where this person has a relationship (student, employee, whatever) this social security number is registered on the user's account. Same LDAP schema in each tenant, so same attribute name.

SSPR parses out the returned social security number and searches for a user that matches this.

Here is where it gets a bit messy.

SSPR insists on running this search for all defined LDAP profiles, despite the fact that during the initial prompt process, it determined which LDAP profile hosted the target object.

If there are no duplicates, then this just works.

However, in my scenario where different tenants do contain an object with the same social security number, SSPR finds duplicates and throws in the towel.

What is interesting is that if one switches Verification Method to LDAP Attributes and requires that one enter the social security number. Then SSPR remembers which LDAP profile it was using and the search find no duplicates.

What is even more interesting is that if one switches Verification Method to back to OAUTH and throws in a login hint. one can use the macro language to pull up whatever attributes one wants and yet again, it remembers which LDAP profile it was using and which LDAP object to retrieve info from.

From what I can tell is that the detour to an external OAUTH server seems make SSPR forgetful about that aforementioned affinity.

Seems to be similar behaviour in PWM also.

Is this deliberate or a bug?

I suspect this might also be why Bogus User functionality doesn't work with the OAUTH Verification Method. That likely also is reliant on needing some affinity with a LDAP profile on the flipside of the OAUTH call.