回答編集履歴
6
ｗ
test
CHANGED
|
@@ -3,7 +3,7 @@
|
|
|
3
3
|
はい。サーバとクライアントの間でトークンをやりとりする**タイミング**における危険性は、保存・交換手段が同じ手法であるとすれば、理論的には同等といえます。
|
|
4
4
|
|
|
5
5
|
ただし長期と短期を組み合わせることで、
|
|
6
|
-
+ 同一のトークンを継続して使い続ける場合の
|
|
6
|
+
+ 同一のアクセストークンを継続して使い続ける場合の危険を減らし、
|
|
7
7
|
+ 一方でアクセストークン更新時の通信経路・ユーザ認証周辺のコストを減らせる
|
|
8
8
|
というトレードオフ（リスクパフォーマンスの良さ）が、リフレッシュトークン/アクセストークンの思想です。
|
|
9
9
|
|
5
ｗ
test
CHANGED
|
@@ -29,6 +29,6 @@
|
|
|
29
29
|
|
|
30
30
|
> リフレッシュトークンの運用方法についてはどのように実装すれば良いのでしょうか？
|
|
31
31
|
「HttpOnly属性は、JavaScriptからのアクセスを制限し、XSS攻撃によるトークンの盗難リスクを低減させるだけです。中間者攻撃のリスクを低減するため、HttpOnly属性だけでなくSecure属性も付けましょう」というのが教科書的な回答になるかと思います。
|
|
32
|
+
（「Secure属性」をお調べになれば、どういうことかお分かりになるかと思います）
|
|
32
33
|
|
|
33
34
|
|
|
34
|
-
|
4
ｓ
test
CHANGED
|
@@ -14,8 +14,6 @@
|
|
|
14
14
|
|
|
15
15
|
|
|
16
16
|
```
|
|
17
|
-
掛け算で、面積で物事を見ましょう。1次元の世界の住人は、2次元の世界を理解できません。
|
|
18
|
-
|
|
19
17
|
Totalリスク ＝ [やりとり1回のタイミングにおけるリスク] × [やりとりの回数] × [更新間隔]
|
|
20
18
|
|
|
21
19
|
パフォーマンスを考慮して、Totalリスク を同等にしたい。
|
3
ｗ
test
CHANGED
|
@@ -16,7 +16,16 @@
|
|
|
16
16
|
```
|
|
17
17
|
掛け算で、面積で物事を見ましょう。1次元の世界の住人は、2次元の世界を理解できません。
|
|
18
18
|
|
|
19
|
-
Totalリスク ＝ [やりとり1回のタイミングにおけるリスク] × [やりとりの回数]
|
|
19
|
+
Totalリスク ＝ [やりとり1回のタイミングにおけるリスク] × [やりとりの回数] × [更新間隔]
|
|
20
|
+
|
|
21
|
+
パフォーマンスを考慮して、Totalリスク を同等にしたい。
|
|
22
|
+
→[やりとり1回のタイミングにおけるリスク]が同じならば、
|
|
23
|
+
やり取りの回数が多いものは、更新間隔を狭め
|
|
24
|
+
やり取りの回数が少ないものは、更新間隔を広げる。
|
|
25
|
+
|
|
26
|
+
（もちろん、やり取りの回数が少ないものの更新間隔を、やり取りの回数が多いものと同じに設定すれば、TOTALリスクの合計は小さくできるが、それだと別のメリットが失われることになる）
|
|
27
|
+
|
|
28
|
+
|
|
20
29
|
```
|
|
21
30
|
|
|
22
31
|
|
2
ｗ
test
CHANGED
|
@@ -7,7 +7,7 @@
|
|
|
7
7
|
+ 一方でアクセストークン更新時の通信経路・ユーザ認証周辺のコストを減らせる
|
|
8
8
|
というトレードオフ（リスクパフォーマンスの良さ）が、リフレッシュトークン/アクセストークンの思想です。
|
|
9
9
|
|
|
10
|
-
繰り返しになりますが、仮にアクセストークンと同じ手段を使用してやりとりする（例：CookieにhttpOnly属性をつけて保存）という前提であれば、リフレッシュトークンをやりとりする**タイミング**でのリスクは、アクセストークンをやりとりするタイミングにおけるリスクと同等です。
|
|
10
|
+
繰り返しになりますが、仮にアクセストークンと同じ手段を使用してやりとりする（例：CookieにhttpOnly属性をつけて保存）という前提であれば、リフレッシュトークンをやりとりする**タイミング**でのリスクは、アクセストークンをやりとりするタイミングにおけるリスクと理論的には同等です。
|
|
11
11
|
|
|
12
12
|
しかしこれは上記のメリットとの**トレードオフ**です。リフレッシュトークンはアクセストークンに比べて、やり取りするタイミングの**回数**が相対的に少ないため、有効期限は相対的に長期に設定しても問題ない、という設計上の判断です。
|
|
13
13
|
|
1
え
test
CHANGED
|
@@ -7,9 +7,17 @@
|
|
|
7
7
|
+ 一方でアクセストークン更新時の通信経路・ユーザ認証周辺のコストを減らせる
|
|
8
8
|
というトレードオフ（リスクパフォーマンスの良さ）が、リフレッシュトークン/アクセストークンの思想です。
|
|
9
9
|
|
|
10
|
-
繰り返しになりますが、
|
|
10
|
+
繰り返しになりますが、仮にアクセストークンと同じ手段を使用してやりとりする（例：CookieにhttpOnly属性をつけて保存）という前提であれば、リフレッシュトークンをやりとりする**タイミング**でのリスクは、アクセストークンをやりとりするタイミングにおけるリスクと同等です。
|
|
11
11
|
|
|
12
12
|
しかしこれは上記のメリットとの**トレードオフ**です。リフレッシュトークンはアクセストークンに比べて、やり取りするタイミングの**回数**が相対的に少ないため、有効期限は相対的に長期に設定しても問題ない、という設計上の判断です。
|
|
13
|
+
|
|
14
|
+
|
|
15
|
+
|
|
16
|
+
```
|
|
17
|
+
掛け算で、面積で物事を見ましょう。1次元の世界の住人は、2次元の世界を理解できません。
|
|
18
|
+
|
|
19
|
+
Totalリスク ＝ [やりとり1回のタイミングにおけるリスク] × [やりとりの回数]
|
|
20
|
+
```
|
|
13
21
|
|
|
14
22
|
|
|
15
23
|
> リフレッシュトークンの運用方法についてはどのように実装すれば良いのでしょうか？
|