回答編集履歴
4
説明補足
test
CHANGED
|
@@ -54,4 +54,8 @@
|
|
|
54
54
|
|
|
55
55
|
|
|
56
56
|
|
|
57
|
+
JWTが一般の実装でpasetoではありませんが、実装すべき最小限のコードと解説記事へのリンクがあります参考に。
|
|
58
|
+
|
|
59
|
+
|
|
60
|
+
|
|
57
61
|
[https://github.com/miguelabate/jwt-go-mabate](https://github.com/miguelabate/jwt-go-mabate)
|
3
実装例の紹介
test
CHANGED
|
@@ -47,3 +47,11 @@
|
|
|
47
47
|
- トークンのリフレッシュする判断や要求もフロント側実装の責務が一般的です。
|
|
48
48
|
|
|
49
49
|
- つまり、JWT認証の話をする時、フロント側実装もセットで考える必要があります。
|
|
50
|
+
|
|
51
|
+
|
|
52
|
+
|
|
53
|
+
## たまたま上記を実装してみた人がいたので追記
|
|
54
|
+
|
|
55
|
+
|
|
56
|
+
|
|
57
|
+
[https://github.com/miguelabate/jwt-go-mabate](https://github.com/miguelabate/jwt-go-mabate)
|
2
補足追記
test
CHANGED
|
@@ -12,7 +12,9 @@
|
|
|
12
12
|
|
|
13
13
|
ざっくりした流れは以下の４点。
|
|
14
14
|
|
|
15
|
+
（以下のフローはHTTPS通信で第三者に漏洩しない状態であることが必須条件です。）
|
|
16
|
+
|
|
15
|
-
1. ユーザーIDに紐づけて生成したトークンをクライアント（フロント）に送り、
|
|
17
|
+
1. ログイン時、ユーザーIDに紐づけて生成したトークンをクライアント（フロント）に送り、
|
|
16
18
|
|
|
17
19
|
2. クライアントはそのトークンを保存しておき、API呼び出しのヘッダにトークンを載せてアクセス。
|
|
18
20
|
|
1
タイプミス修正
test
CHANGED
|
@@ -10,6 +10,18 @@
|
|
|
10
10
|
|
|
11
11
|
|
|
12
12
|
|
|
13
|
+
ざっくりした流れは以下の４点。
|
|
14
|
+
|
|
15
|
+
1. ユーザーIDに紐づけて生成したトークンをクライアント（フロント）に送り、
|
|
16
|
+
|
|
17
|
+
2. クライアントはそのトークンを保存しておき、API呼び出しのヘッダにトークンを載せてアクセス。
|
|
18
|
+
|
|
19
|
+
3. サーバーはヘッダにあるトークンが本物かどうかを検証する。
|
|
20
|
+
|
|
21
|
+
4. 有効なトークンでリフレッシュAPIに要求が来たら有効期限をのばしたトークンを生成し直してクライアントに返す。
|
|
22
|
+
|
|
23
|
+
|
|
24
|
+
|
|
13
25
|
現状上げていただいた実装についてアドバイスできることは以下の様な内容です。
|
|
14
26
|
|
|
15
27
|
|
|
@@ -18,15 +30,15 @@
|
|
|
18
30
|
|
|
19
31
|
- userCreate処理はHTTPハンドラとして実装しないで独立した処理にしてサインアップ処理で使う様にしましょう。
|
|
20
32
|
|
|
21
|
-
- その上でログインHTTPハンドラを実装しましょう
|
|
33
|
+
- その上でログインとトークンリフレッシュ用のHTTPハンドラを実装しましょう
|
|
22
34
|
|
|
23
35
|
- DBに保存するのはトークンそのものではなく、プライベートキーにしましょう。（そうしないと2度と正しいトークンを生成できませんのでリフレッシュもできません）
|
|
24
36
|
|
|
25
|
-
- APIで認証情報を検証するには、サインアップ処理でクライアントに返したトークンがAPIリクエストヘッダーのAuthorizationヘッダに載ってるものを「Authorization: Bearer v2.public.eyJkYXRhIjoidGhpcyBpcyBhIHNpZ25lZCBtZXNzYWdlIiwiZXhwIjoiMjAxOC0wMy0xMlQxOTowODo1NCswMTowMCJ9Ojv0uXlUNXSFhR88KXb568LheLRdeGy2oILR3uyOM_-b7r7i_fX8aljFYUiF-MRr5IRHMBcWPtM0fmn9SOd6Aw.c29tZSBmb290ZXI」のようなBearer以降の文字列をp
|
|
37
|
+
- APIで認証情報を検証するには、サインアップ処理でクライアントに返したトークンがAPIリクエストヘッダーのAuthorizationヘッダに載ってるものを「Authorization: Bearer v2.public.eyJkYXRhIjoidGhpcyBpcyBhIHNpZ25lZCBtZXNzYWdlIiwiZXhwIjoiMjAxOC0wMy0xMlQxOTowODo1NCswMTowMCJ9Ojv0uXlUNXSFhR88KXb568LheLRdeGy2oILR3uyOM_-b7r7i_fX8aljFYUiF-MRr5IRHMBcWPtM0fmn9SOd6Aw.c29tZSBmb290ZXI」のようなBearer以降の文字列をpaseto.Verifyに引き渡すと検証できます。
|
|
26
38
|
|
|
27
39
|
|
|
28
40
|
|
|
29
|
-
- サインアップの際
|
|
41
|
+
- サインアップの際の生成トークンを保存するのは基本フロント側実装の責務です。
|
|
30
42
|
|
|
31
43
|
- Authorizationヘッダにトークンを載せるのはフロント側実装の責務です。
|
|
32
44
|
|