回答編集履歴

2

誤字の修正

2017/10/04 00:06

投稿

退会済みユーザー
test CHANGED
@@ -10,12 +10,14 @@
10
10
 
11
11
  どちらも自分のサービスであれば鍵は共通鍵でも良いかもしれませんが、将来的にサービス数が増えた場合に安全に鍵を配布する手間を考えると、各サービスサーバが定期的に公開鍵をとりにいく形が漏れもなくよいと考えます。
12
12
 
13
+
14
+
13
15
  また、鍵ペアは複数登録できるようにしておくことが望ましいです。
14
16
 
15
- 秘密鍵の交換を計画した場合に鍵の行運用ができないと、鍵を差し替えたタイミングで認証済みのチケットが一斉に失効してしまうからです。
17
+ 秘密鍵の交換を計画した場合に鍵の行運用ができないと、鍵を差し替えたタイミングで認証済みのチケットが一斉に失効してしまうからです。
16
18
 
17
19
  もちろん、cookie内のデータ構造を変更したり、何らかのインシデントが発生して必要になったり等で一斉失効を意図的に実施するケースはありえます。
18
20
 
19
21
 
20
22
 
21
- 長々と書いていて質問者の方の意図とずれた内容かもしれませんが、何か参考になれば幸いです。
23
+ 長々と書いていて質問者の方の意図とずれた内容かもしれませんが、何か参考になれば幸いです。

1

cookieでの認可時の注意を追記

2017/10/04 00:06

投稿

退会済みユーザー
test CHANGED
@@ -3,3 +3,19 @@
3
3
 
4
4
 
5
5
  認証提供範囲が独自ドメインのサブドメインのみということであれば、共通ログイン後にcookieでチケットを発行して、各サービスでチケットから認可を判断するという形での対応でも可能だと思います。
6
+
7
+
8
+
9
+ cookie情報のみから判断しようとすると、cookieはどうしても改ざんのリスクがあるため、認証サービス側で認証結果を秘密鍵を用いて暗号化し、各サービスは公開鍵で復号、正当性の確認をする等の流れが良いのではないかと思います。
10
+
11
+ どちらも自分のサービスであれば鍵は共通鍵でも良いかもしれませんが、将来的にサービス数が増えた場合に安全に鍵を配布する手間を考えると、各サービスサーバが定期的に公開鍵をとりにいく形が漏れもなくよいと考えます。
12
+
13
+ また、鍵ペアは複数登録できるようにしておくことが望ましいです。
14
+
15
+ 秘密鍵の交換を計画した場合に鍵の平行運用ができないと、鍵を差し替えたタイミングで認証済みのチケットが一斉に失効してしまうからです。
16
+
17
+ もちろん、cookie内のデータ構造を変更したり、何らかのインシデントが発生して必要になったり等で一斉失効を意図的に実施するケースはありえます。
18
+
19
+
20
+
21
+ 長々と書いていて質問者の方の意図とはずれた内容かもしれませんが、何か参考になれば幸いです。