五一期間在flomo官網(wǎng)的擴(kuò)展中心看到了這個(gè)Raycast to flomo，對(duì)mac上的效率工具有了點(diǎn)了解，我直接基本都沒有用過Mac自帶的spotlight。。。
我好奇的不是竟然可以用這種方式發(fā)送到flomo，畢竟官網(wǎng)API擺在那，調(diào)一下也很簡(jiǎn)單，我驚奇的是Raycast跟Mac系統(tǒng)的風(fēng)格比較搭配，看上去不錯(cuò)，就去Raycast的官網(wǎng)看了一下。
緣起
看了下Raycast的API文檔，妥妥的對(duì)前端開發(fā)及其友好啊，大贊！
文檔擼了一遍之后，我看到自己感興趣的Auth部分。
用官網(wǎng)的demo試了試twitter的oauth pkce登錄流程，很順暢，瞬間有了一種想給道招網(wǎng)也安排上，雖然本站基本只有我一個(gè)人會(huì)登錄，很多年前我就把注冊(cè)功能給禁用了，這次準(zhǔn)備開放了。
自己順便了解了一下PKCE流程
上圖來自auth0.com
原來PKCE是為了優(yōu)化現(xiàn)在流行的SPA應(yīng)用token驗(yàn)證流程的。
OAuth2.0
先回顧下OAuth2.0流程：
在獲取token的時(shí)候需要提供如下信息：
- code
- redirect_url
- client_id, client secret
第二項(xiàng)和第三項(xiàng)其實(shí)是用來對(duì)通過code獲取token的client的合法性進(jìn)行驗(yàn)證。其中最核心的應(yīng)該是client secret。通過它可以解決如下問題：
對(duì)獲取token的client進(jìn)行合法性驗(yàn)證。secret是在Authorization Server上注冊(cè)client的時(shí)候設(shè)置的，只有client自己知道，因此可以對(duì)client進(jìn)行驗(yàn)證。
這樣的話，即使code因?yàn)槟撤N原因泄露了，沒有secret也無法獲取到token。從而提升了安全性。在傳統(tǒng)的Web應(yīng)用中，token的獲取是發(fā)生在后端，因此secret也是保存在后端。這樣是可行的。但是對(duì)于現(xiàn)在比較流行的SPA應(yīng)用，token的獲取是發(fā)生在瀏覽器端，是一個(gè)公開的環(huán)境。這個(gè)方法就不可行了，因?yàn)閟ecret不可能保存在一個(gè)公開的環(huán)境中。
PKCE
PKCE主要是通過在授權(quán)的過程中增加了code_challenge和code_verifier兩個(gè)元素來對(duì)整個(gè)流程進(jìn)行驗(yàn)證，防止code被第三方截取的情況。具體流程如下：
這里面最核心的其實(shí)就是在authorize請(qǐng)求中增加了code_challenge參數(shù)，在token請(qǐng)求中增加了code_verifier參數(shù)。這兩個(gè)參數(shù)最終都是依賴于一個(gè)client生成的隨機(jī)字符串。
- codeverifier：一個(gè)Client端生成的隨機(jī)字符串（由字母，數(shù)字，- ，. ， ，~ 組成）
- code_challenge：由code_verifier生成的字符串。 生成算法為：BASE64URL-ENCODE(SHA256(ASCII(code_verifier)))。
過程解析：
- 在申請(qǐng)授權(quán)時(shí)（authorize請(qǐng)求）,client將code_challenge傳給authorization server.(這個(gè)過程中code_verifier在網(wǎng)絡(luò)中不會(huì)被暴露，因?yàn)閷?duì)其進(jìn)行了hash)。
- authorization server生成授權(quán)碼后，會(huì)將code_challenge保存起來，并與授權(quán)碼關(guān)聯(lián)。
- 在通過授權(quán)碼獲取token的過程中，client會(huì)將code_verifier傳給authorization server
- authorization server會(huì)將code_verifier按照第一步相同算法計(jì)算得到新的code_challenge
- authorization server將第四步計(jì)算得來的code_challenge與第一步中的原始code_challenge進(jìn)行比較，如果相同則認(rèn)為申請(qǐng)授權(quán)的源與用code獲取token的源為同一來源。（即code沒有被第三方截取而冒用）
客戶端一般用oide-provider來對(duì)接PKCE。
參考文章
- Authorization Code Flow with Proof Key for Code Exchange (PKCE)
- 基于Identity Server4的OAuth 2.0授權(quán)總結(jié)（4）- PKCE in Authorization Code mode
