項目中有和別的系統對接的部分，別的系統需要單點登錄到我們的系統，本來做好的也測過完全沒有什么問題，今天突然有一個客戶每次登錄的時候都會跳轉到登錄頁（其他人都沒出現這個問題），剛開始懷疑是不是客戶的登錄用戶有問題，但是在別的電腦上這個用戶功能是正常的。然后懷疑是他的瀏覽器問題，但是讓他換了各種瀏覽器用谷歌也是有問題，排除了瀏覽器造成的原因，最后又梳理了一下代碼邏輯感覺是不應該有問題的。沒辦法只好和客戶遠程操作看問題了，然后發現單點登錄所調的登錄接口是成功了的，token也已返回，但是在調業務接口的時候，接口壓根就沒發送請求，直接在前端被攔截了，查看瀏覽器的存儲發現token也是按規則在localstroage里面存着呢。按照原來的理解@delon/auth是會在token沒有存的情況下前端直接把請求攔截掉的，但是這個情況token明顯已經存在了，也不可能取不到。
最后無意間發現客戶本地時間比標准時間快了一個多小時，當時感覺和這個關系不大，但是在同事的建議下還是把客戶電腦上的本地時間校正了一下，然后神奇的事情發生了，單點登錄成功了，最后經過驗證真的是本地時間不正確造成的。問題發現了接着就是解決問題了，因為是本地時間不正確造成的，那應該就是@delon/auth在做token校驗的時候把本地時間和token時效做比較了，通過和后端同事交流知道在做單點登錄的時候接口生成的token確實是有半個小時時效限制的，后端用JWT確實會把token過期時間存儲在token里。然后去ng-alain官網看用戶認證文檔發現了一個時間偏移配置token_exp_offset
通過這個設置來調整時間過期偏移值，最后的解決就是把這個值設置了一個負的很大的值來避免電腦本地時間造成的影響。
另外這個值是有正負的，正向偏移是正數，反向偏移要負數，所以這里要增加token的時效要用負值。
最后總感覺@delon/auth里拿本地時間去做token時效校驗沒有意義。感覺這個也是有點坑，搗鼓了小半天才找到問題解決了問題。