d大您好:
剛剛搜尋看JWT範例，真的不知道如何應用(第一次接觸)，我再查查看
我的想法如下，這樣不知道有沒有問題或那裡有誤 謝謝

mayyola

這樣不知道有沒有問題或那裡有誤

基本上應該不會到 "誤"

只有好不好 方不方便而已

有的時候也可能實際 run 才會發現哪裡不好才改

我的想法如下

1 . 表單A完成, 同時也指定那些人須簽核然後寫到同一個資料表

e.g.
{
    title: '......',
    content: '.......',
    signer: [
        {
            name: '...',
            reply: '',
            time: '',
            status: '0',
        },
        {
            name: '...',
            reply: '',
            time: '',
            status: '0',
        },        
    ],
    status: '0',
    accessCode: 'eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c',
}

2 .
將網址依序發給簽屬者

e.g. http://127.0.0.1?code=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

簽屬者進入網址須通過認證(e.g. 登入)

(可以把接下來要簽的人帳號簽在 jwt 的 payload 裡

這樣登入時就能檢查是不是該他簽)

3 .
簽完送出後

檢查此公文是否全部簽完(e.g. signer 全部的 status 為 1)

簽完就...簽完

沒簽完就繼續上面的操作

每次簽完更新 accessCode

依此類推

至於你想要有那些資料就看你

jwt 最大的用意是不容易偽造

裡面可以放一些非機敏資料

e.g. 下一個簽核者帳號

JWT的安全性不會比session好喔。
JWT上面除了第3段簽名是有經過加密，其他攜帶的資訊都是base64...
下一個簽核者帳號應該要把他當機敏資料，放在資料庫內，萬一把你JWT第2段解碼後，改掉，然後系統撰寫者又沒注意到這部分，只檢查JWT token是否相符，但是下一個簽核者是靠明碼JSON傳送...

froce大

第三段部分的簽名

不是以 jwt header + jwt payload + secret來簽的嗎

自己改內容而簽名沒變的話

後端驗證不會過吧

還是我對 jwt 有什麼誤會了XD

不過應該也不會完全以 jwt 來當作驗證的依據就是

不是以 jwt header + jwt payload + secret來簽的嗎

是，但是你的playload包含了「下個簽核者」這個可能會變動的欄位啊。
JWT的應用情景適合在你的playload為「一登入就固定下來」的狀況。
你想想，今天你的JWT token本來還沒過期，然後因為有時候使用者要改「下個簽核者」（簽文加會也很正常啊），那你的token要不要改？改了你又用spa，瀏覽器基本上不刷新，會不會造成token原本沒過期，你得讓使用者強制更新token，或是沿用舊token，然後因為下個簽核者不同，造成你欄位出錯的狀況，這些很容易就被忽略掉，而且通常改動一下，就很難改。

https://medium.com/mr-efacani-teatime/%E6%B7%BA%E8%AB%87jwt%E7%9A%84%E5%AE%89%E5%85%A8%E6%80%A7%E8%88%87%E9%81%A9%E7%94%A8%E6%83%85%E5%A2%83-301b5491b60e

最近在寫一個專案，就是打算做完全的前後端分離SPA（順便練VUE.js），並試用JWT。
發現最佔我心力的是認證機制，需要很小心的去設計後端DRF（django rest framework）的資料庫權限，本來依靠session去判斷身份的功能都不能用，原本可以輕易達成使用者和管理者的js lib在後端輸出不同的結果，都不能用，前端其實可以輕鬆的得到原本管理者使用的lib，除非你真的對這種認證機制的不可靠有相當的理解，要不然很難設計出具有良好安全性的系統。

例如：C的表單要給A跟B簽核，而B除了寫上自己的資料後同時也偽造了A的簽核。
為了避免這類狀況，好像還是得靠 session 跟資料庫紀錄狀態。

F大跟h大說的jwt 應用我沒接觸過，不知到要應用在哪？我的想法是每個簽核者都要登入系統，每筆簽核單都在資料庫下個簽核的是誰..簽核者登入後用session(“name”)去列出要簽核的單子，簽核者可以依依點選看內容並簽核，不知這種方式是否可行，謝謝

playload包含了「下個簽核者」這個可能會變動的欄位啊

froce大

我大概了解你的看法了

不過我預設 jwt 在這的場景

大概就類似公文識別ID的用途

大概就是

User 透過連結存取

後端驗證是否為合法 token

以 token 搜尋 database 取得此筆公文的相關資訊

進行接下來的操作(到此處 jwt token 就沒用途了)

所以我才沒有提什麼 jwt blacklist 之類的東西

因為我只是把它當成 公文ID 使用

真正該誰簽或者相關的東西

都還是以我一開始說的那個 database 為主

就算 User 丟一個過期的 token 過來

驗證會過

但 database 會找不到此筆公文

(因為原本的 token 可能因已經簽完或者加簽等操作變更 token)

不過這倒也提醒我就是

jwt 當公文識別ID可能不太好(e.g. 日後想查詢此公文之類的)

最近在寫一個專案，就是打算做完全的前後端分離SPA...

改用 jwt 真的會讓以前很簡單的東西變得有點麻煩

e.g.

• 想要 user pending 超過 30 分鐘就登出

• 限制單一登入

等等..

沒辦法像以前用 session 那麼直覺簡單

淺水員大

例如：C的表單要給A跟B簽核..

你好像誤會了XD

這些東西都不會放在 jwt 裡啦XD

應該是說

真正的紀錄都還是在 database 裡

mayyola

你可能需要先把流程完整的列出來

然後考慮到有可能發生的情況

e.g.

如何知道開啟此公文的就是接下來要簽的人

那個階段可能會加簽

有沒有可能有代簽的情況

如果公文退回要如何處理 等...

把這些情況與解決方法列出來後

再轉以 coding 的方式表現與思考會比較有幫助且有效率

jwt 只是個工具而已

不熟或者不想用其實也沒差XD

我就是覺得你搞不定JWT才寫上面那些的，D大的話我相信他絕對有能力搞定，我才不會提醒他。XD

基本上你說的ok，但我見到公家機關的公文系統，他的流程設定是由主辦人一開始設定的，剩下的有需要的再去進行改會、加會等工作。
這部分要看使用者實際需求才能作，如果要設計到這麼正式，你目前的設計就行不通。

真正的公文系統在流程這部分才是最難搞的。

想要 user pending 超過 30 分鐘就登出

這簡單啊，反正你取資料都要用JWT，過時就登出就好。
麻煩的反而是你想要長時間不過期。（用雙token做refresh的狀況）

限制單一登入

你還是可以和session並用。
或是在第一次用帳號密碼登入的時候把登入ip做JWT的playload，然後驗證時檢查。當然這不是非常安全的方法，但聊勝於無啦。

我剛剛找了幾個有關jwt的文，user跟password登入後跟資料庫認證，再將部分資料與公文ID經過jwt產生加密的連結，寫入資料庫..D大的想法是這樣對嗎?

mayyola

我剛剛找了幾個有關jwt的文，user跟password登入後跟資料庫認證

呃

如果你不是做前後端分離的話

那就先把 jwt 放一邊

乖乖用 session 做吧

會比較單純

不太需要糾結在 jwt 上

再將部分資料與公文ID經過jwt產生加密的連結

嚴格來說

jwt 不算加密

就像 froce 大說的

他前兩個部分只是 base64

...（用雙token做refresh的狀況）

refresh token 的作法好像蠻常見的

不過這樣一來

就勢必會需要 blacklist 來讓舊的 token 提早失效

然後考慮到多個 request 併發的情況

e.g. 短時間發 10 request, 可能在第一個 request 時

剛好觸發 refresh 的條件然後 refresh token

但是這 10 個送到後端的 token

都是同一個

如果只是 refresh 完後讓舊的 token 失效

可能會造成後面的 request 都變得不合法

這時會需要一個 expire time

讓進入 blacklist 的 token

短時間之內還有效

JWT只是簽名而已，不是加密。

然後考慮到多個 request 併發的情況
e.g. 短時間發 10 request, 可能在第一個 request 時
剛好觸發 refresh 的條件然後 refresh token
但是這 10 個送到後端的 token...

沒有這麼頻繁的refresh操作啦。
你在要CRUD前做一次refresh就行了。
像我目前寫的專案，就是用vuex存refresh的action，每次要CRUD前確保access token是有效的，然後再一次做複數的POST/PUT

this.$store.dispatch("refresh")

let put = edited.filter(p => p.url)
        .map( p => {
          this.$http
            .put(p.url)
            .set("Authorization", 'Bearer '+ this.$store.state.accessToken)
            .send(p)
            .then( success => {
              ...
            }, error => {
              ...
            })
        })

refresh：

superagent.post(baseURL + "/api-token-refresh/")
          .send({
            refresh: state.refreshToken
          })

access和refresh token的關係是，假設access 5分鐘過期，refresh 1天過期。
然後我每5分鐘就post refresh token，返回新的access token，供認證。
要不然就是不管他什麼時候過期，反正要CRUD跟後端要資源都更新一次。

有興趣可以研究一下simplejwt這個DRF套件：
https://github.com/davesque/django-rest-framework-simplejwt

他說明寫得很簡單，但光是認證要整合AD我就爬了好久的原始碼，後來才發現他把auth相關的backend都關掉了...Orz