Let's say you have a website A, of which you control the login + navigation across protected pages of A via PHP Session cookies. For thus maximum security, these cookies are all secure, httponly, and use samesite equal to Strict, and are limited to the domain of A, hence also "host-only".
If a user who's logged in now confirms a payment while on A, some banks / payment services will automatically redirect that user to execute a subsequent / multi-factor authentication on page B of the concerned service. After the client responded to that additional authentication, no matter if yes or no, the system normally redirects the client back to A.
What I'm wondering now is concerning security. Using the above-mentioned session cookie settings, the redirects to B and back to A would obviously cause that the client would lose the session, and get signed out after being redirected on A.
This can be avoided by setting the SameSite attribute of the session cookie to Lax in the server configs. However, what if I wanted to keep it to Strict?
The solution I came to think of, but no clue on how to implement this in PHP:
The session cookie configs on the server define the Strict value for the sameSite attribute, as I want that to be the case, in general. When the payment is confirmed on A, the function which handles that confirmation on the server-side, so before the redirect to B, changes that samesite value of the session cookie to Lax. Then, on the page which B redirects to, at the very beginning, I reset that value back to Strict.
Is something like this possible in PHP? Or would you rather consider sth like creating an entirely new session cookie having Lax, copy your $_SESSION data into it, and then take up that $_SESSION data back after the redirect, into the cookie you're using for the sessions on A using sameSite="Strict"?
Or any other, better-suited solution?
As far as I know payment providers usually require some kind of signed transaction token passed in the GET request. Such token is being sent back in the GET together with the redirections.
In such a case assign the session data to such a transaction token generated in the site A, send the token with the redirection to the the site B and restore the session data when the token is received with the redirect from site B.
The token must be signed, so site A and B must be sure that it originates from the site A.
This requires additional controls in place to prevent session hijack by someone who is in a possession of such token: some kind of additional session validation must be in place for example browser fingerprinting.
In such case there's no need to get the same session cookie.