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