EDIT - Two answers below.
You could embed another ID in the link which tracks back to the original Session ID.
Is the requirement that the email link, when clicked launches in the same browser or can it be on a different browser? What if it's on a different machine? For example, what if I reset the password from my phone, then move over to my computer or tablet, click on the link in the email and set up a new password? I might do this if I want to use the password store on my computer even though I started on my phone. From an ease of use perspective, it seems that the password link in the email and not the session ID from the original browser is important.
Furthermore, if the "Forgot Password" link was clicked by an attacker trying to gain entry and you force the Session ID to be the same, then the real user who receives the reset password link might experience a DOS depending upon how your system works. Certainly, the legitimate user can't reset her own password with the link provided because the Session ID originating the "Forgot Password" request resides in the attackers browser.
As application developer, you should be able to do one of the following:
- Recognize a second session started from the password reset link as legitimate and let it go through.
- Process the reset link and set it back to the first session ID.
However, I really think #2 is ill-advised given that an attacker might be clicking on the Forgot Password Link. I think your best bet is to use the second session.
Incidentally, the most paranoid systems I've seen force a re-login once the password has been reset. That is, you click "Forgot Password", get the email, click on the link, reset the password, then you're presented with a fresh login page which requires you to enter your username and new password (instead of quietly being logged in as a consequence of the password reset).
Second Answer - clarification in Question Comments
It looks like you're concerned with the OWASP article referenced. In this case, the article recommends doing one continuous session for a password reset and use an Alternate or Out Of Band (OOB) Channel to increase the likelihood you're speaking with the legitimate user. In this case, the user initiates the password reset process, answers security questions correctly, is locked out of the account, an OOB PIN code is sent via SMS or email (note, not a reset link), user enters correct PIN code, then new password may be entered.
This wasn't what the original question contained. In this case, a password reset link is not to be sent and only a PIN code to be viewed with an email reader and entered in the same password reset session flow. Jumping to a new Session ID (even if possible) ought to be seen as an attack or system bug and rejected.