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