我們有一個應用程序發送包含深層鏈接的電子郵件，並使用OAuth2。當用戶已經「登錄」（有一個有效的訪問令牌）時，深度鏈接可以正常工作，但當令牌過期/沒有時，則會斷開。原因是因爲應用程序接收到具有特定深度URL的請求，向auth服務器發出一個請求，並向其自身提供一個重定向URL（它是主頁面，而不是原始請求中的深層鏈接，即我們曾經爲應用程序配置過的重定向URL），並且登錄順利，auth服務器執行重定向，應用程序顯示主頁面，並且原始深層鏈接請求被遺忘。可能很重要的一點是，所有這些都發生在單個瀏覽器窗口/選項卡中（要求不打開其他選項卡或使用彈出窗口）。由於重定向導致與OAuth2的深層鏈接丟失
我有一個想法，使用（濫用？）'狀態'請求參數，auth服務器需要在重定向中使用verbatim，它會包含信息（如應用程序內的鏈接），允許應用程序顯示所需的頁面。我不確定'狀態'參數是否應該像這樣使用，它似乎是爲CSRF預防而設計的，而不是像這樣的定製邏輯。
另一個可行的選擇是基於這樣一個事實，即服務器與完全重定向URL不匹配配置的URL，只是檢查它是否配置了前綴（因爲OAuth2規範沒有強制要求，它表示完全匹配應該完成）。因此，由於我們的重定向網址是深層鏈接，並且配置的網址是其前綴，因此確實有效。但是，當服務器決定匹配完整的URL時，這種行爲將會中斷（並且它是用Spring Security編寫的，並且很容易改變這種行爲，只需使用與lib：https://github.com/spring-projects/spring-security-oauth/blob/ec215f79f4f73f8bb5d4b8a3ff9abe15b3335866/spring-security-oauth2/src/main/java/org/springframework/security/oauth2/provider/endpoint/ExactMatchRedirectResolver.java一起提供的不同匹配器類）。我想用一些更安全的方式，即不與OAuth2對抗的方式。
有沒有更好的方式來做到這一點？