这是OAuth2认证流程里非常常见的需求，完全不用复杂的workaround，利用OAuth2规范本身的特性或者简单的前后端配合就能搞定，给你几个实用的方案：

1. 利用OAuth2标准的state参数传递原地址（推荐） #

Google和GitHub的OAuth2实现都完全支持state参数，这个参数本来是用来防范CSRF攻击的，但规范里并没有限制它只能存CSRF令牌——你可以把CSRF令牌+编码后的原请求URL一起打包进去，OAuth服务会在回调时原封不动地把这个参数传回给你的后端。

具体步骤：

• Angular路由守卫检测到用户未认证时，先把当前要访问的URL（比如/transactions?from=2014&to=2016）做URL编码，然后生成一个随机的CSRF令牌。
• 把这两个信息拼接成一个字符串（比如用JSON序列化后再Base64编码，避免特殊字符），作为state参数传给后端的授权入口接口（比如/api/auth/start?state=xxx）。
• 后端收到请求后，直接把这个state参数附加到Google/GitHub的授权跳转URL上，比如：

  https://accounts.google.com/o/oauth2/v2/auth?client_id=xxx&redirect_uri=xxx&response_type=code&scope=xxx&state=刚才的state值
  

• 用户完成授权后，OAuth服务会回调你的后端接口，同时带回这个state参数。后端解析state，先验证CSRF令牌的有效性（防止攻击），然后取出里面的原请求URL。
• 后端完成token交换后，重定向回Angular的回调页面（比如http://my-domain.com/auth/callback），同时把原URL作为参数传过去，或者存在临时缓存（比如Redis）里用token关联，让前端去取。
• Angular回调页面拿到原URL后，直接跳转到该地址即可。

Spring Security OAuth2已经内置了对state参数的处理逻辑，你只需要自定义AuthorizationRequestResolver来扩展state的生成和解析逻辑，不用从零搭建。

2. 后端用Session暂存原地址（适合服务器端会话场景） #

如果你的Spring Boot应用使用服务器端Session（默认的HttpSession），这个方案会更简单：

• Angular路由守卫跳转到后端授权接口时，把原请求URL作为参数传过去，比如/api/auth/start?original_url=/transactions?from=2014&to=2016。
• 后端收到请求后，把original_url存入当前的匿名Session（Spring Security默认支持匿名用户的Session）。
• 后端正常跳转到OAuth授权页面，用户完成授权后，回调后端接口时，从Session里取出original_url。
• 最后后端重定向回Angular时，把original_url作为参数带上，前端拿到后跳转即可。

⚠️ 注意：如果是分布式部署的后端服务，需要把Session做共享（比如用Redis存储Session），否则多实例情况下可能取不到存在Session里的原URL。

3. 前端本地暂存原地址（适合无状态后端） #

如果你的后端是无状态的（不存Session），可以让前端自己暂存原URL，配合state参数传递标识：

• Angular路由守卫检测到未认证时，生成一个唯一UUID，把原请求URL存入sessionStorage，键就是这个UUID。
• 跳转到后端授权接口时，把这个UUID作为state参数传过去。
• 后端OAuth回调时，把这个UUID作为参数重定向回Angular的回调页面。
• Angular回调页面拿到UUID后，从sessionStorage里取出对应的原URL，然后跳转过去。

这个方案的优点是后端不用存储任何数据，但要注意sessionStorage是标签页隔离的，如果用户在新标签页完成登录，可能取不到原URL；另外要确保UUID的唯一性，避免冲突。

内容的提问来源于stack exchange，提问作者Sniady