五一期間在flomo官網的擴展中心看到了這個Raycast to flomo，對mac上的效率工具有了點了解，我直接基本都沒有用過Mac自帶的spotlight。。。

我好奇的不是竟然可以用這種方式發送到flomo，畢竟官網API擺在那，調一下也很簡單，我驚奇的是Raycast跟Mac系統的風格比較搭配，看上去不錯，就去Raycast的官網看了一下。

緣起

看了下Raycast的API文檔，妥妥的對前端開發及其友好啊，大贊！

文檔擼了一遍之后，我看到自己感興趣的Auth部分。

用官網的demo試了試twitter的oauth pkce登錄流程，很順暢，瞬間有了一種想給道招網也安排上，雖然本站基本只有我一個人會登錄，很多年前我就把注冊功能給禁用了，這次準備開放了。

自己順便了解了一下PKCE流程

上圖來自auth0.com

原來PKCE是為了優化現在流行的SPA應用token驗證流程的。

OAuth2.0

先回顧下OAuth2.0流程：

在獲取token的時候需要提供如下信息：

code
redirect_url
client_id, client secret

第二項和第三項其實是用來對通過code獲取token的client的合法性進行驗證。其中最核心的應該是client secret。通過它可以解決如下問題：

對獲取token的client進行合法性驗證。secret是在Authorization Server上注冊client的時候設置的，只有client自己知道，因此可以對client進行驗證。

這樣的話，即使code因為某種原因泄露了，沒有secret也無法獲取到token。從而提升了安全性。在傳統的Web應用中，token的獲取是發生在后端，因此secret也是保存在后端。這樣是可行的。但是對于現在比較流行的SPA應用，token的獲取是發生在瀏覽器端，是一個公開的環境。這個方法就不可行了，因為secret不可能保存在一個公開的環境中。

PKCE

PKCE主要是通過在授權的過程中增加了code_challenge和code_verifier兩個元素來對整個流程進行驗證，防止code被第三方截取的情況。具體流程如下：

這里面最核心的其實就是在authorize請求中增加了code_challenge參數，在token請求中增加了code_verifier參數。這兩個參數最終都是依賴于一個client生成的隨機字符串。

codeverifier：一個Client端生成的隨機字符串（由字母，數字，- ，. ，，~ 組成）
code_challenge：由code_verifier生成的字符串。生成算法為：BASE64URL-ENCODE(SHA256(ASCII(code_verifier)))。

過程解析：

在申請授權時（authorize請求）,client將code_challenge傳給authorization server.(這個過程中code_verifier在網絡中不會被暴露，因為對其進行了hash)。
authorization server生成授權碼后，會將code_challenge保存起來，并與授權碼關聯。
在通過授權碼獲取token的過程中，client會將code_verifier傳給authorization server
authorization server會將code_verifier按照第一步相同算法計算得到新的code_challenge
authorization server將第四步計算得來的code_challenge與第一步中的原始code_challenge進行比較，如果相同則認為申請授權的源與用code獲取token的源為同一來源。（即code沒有被第三方截取而冒用）

客戶端一般用oide-provider來對接PKCE。