承上篇

今天來講解一下登入的流程，直接看文件中的圖：

這張圖分成使用者、應用與 LINE 平台，其中，應用則包含前端與後端。

簡單來說，當使用者點擊前端的登入按鈕後，前端會將頁面導向 LINE 的授權端點。在這個授權 url 的 query string 中，會帶上 redirect url（登入完成後 LINE 要導回的地址）、Channel ID（client_id）、以及用於防止 Cross-Site Request Forgery 攻擊的 state（我是用 uuid 來進行生成）。此時使用者若是在 PC 端未登入的情況下，會需要請使用者登入並授權；若是在 Mobile 端已經登入 LINE 的前提下，有可能會觸發 auto login (這部分有機會可以再細說)，會直接獲得授權。

當使用者授權完成後，LINE 會將瀏覽器導回事先設定好的 redirect url，並在 query string 中附帶 authorization code 與剛剛的 state。應用端必須驗證回傳的 state 是否與先前送出的一致，以確認請求沒有遭竄改。比較好的做法是，除了前端檢查外，後端也應再次驗證 state，確保安全性。

接著，將 authorization code 傳給後端後，後端會使用 Channel ID 與 Channel Secret（這是敏感資訊，必須只保存在後端）向 LINE 的伺服器交換 access token 與 id_token。

• access_token：可用來呼叫 LINE 的 API，取得更多使用者資料。
• id_token：一個 JWT 格式的 token，裡面已經包含基本的使用者資訊（如 userId、顯示名稱、email 等）。

最後，後端可以選擇解析 id_token 或呼叫 LINE 的 Profile API，取得使用者的基本資料，再將結果回傳給前端，完成整個登入流程。

在文章的後面，想來寫一點點串接心得：

我之前的專案在串接 LINE Login 時，後端並不會直接將 LINE 回傳的 access token 和 id_token 傳給前端，而是先檢查該用戶是否為首次登入。若是首次登入，則先建立註冊流程；若已經存在，則進行登入流程。無論哪種情況，最後後端都會回傳一組應用本身的登入 token 給前端。

另外，如果我們沒有在授權 url 的 query string 中設置 prompt，就有機會在 Ｍobile 環境觸發 auto login，它會在導向 redirect url 的時候另開頁面，所以在前端在存取 state 的時候，比較不推薦 sessionStorage，而是用 localStorage 為佳，並在驗證之後立即刪除。

蠻喜歡閱讀 LINE 的官方文件，寫得很詳細又清楚，我還發現官方竟然有出一頁文件告訴大家，LINE 的按鈕怎麼刻XDDDD真的好認真好好笑XDDDDD