質問: 初めて質問させていただきます。 独学でWebサービス開発に取り組んでいて、いわゆるベストプラクティスがわからず苦戦することが多い状況です。 ヒントでも事例でもいいので、アドバイスをいただければと思います。 よろしくお願いします! ### 前提・実現したいこと Ruby on Rails 5でWebアプリケーションを開発しようと思っています。 今後、サブドメインでいくつかのサービスを展開したいと考えています。 (AAA.mydomain.com, BBB.mydomain.com, CCC.mydomain.comのようにしたい。各サービスもRailsで開発しようと考えています) それぞれのサービスは内容が離れていて、一つのWebアプリケーション(一つのRailsプロジェクト)には開発のしやすさの観点からもしたくはないです。 ### 自分で考えている方法 ユーザー認証を行うためのWebサービスを一つ作り、そこでユーザー管理をまとめて行う。 【構成】 ・認証用サービス(mydomain.com): ユーザー登録を受け付け、他のサービスからの認証に応答する(OAuthプロバイダを実装する? mydomain.comに対してクッキーでセッション情報を持たせて、他サービスが参照できれば問題なし?) ・サービスA(AAA.mydomain.com): mydomain.comで認証ができていなければ、mydomain.comにリダイレクトして認証を行う ・サービスB,C:サービスAと同じ動作で認証を行う ### 質問内容 上記の内容を実現したい場合、私が考えている方法がベストでしょうか。 勉強不足で語句を正確に使えていないかもしれません。 よろしくお願いいたします。 ### 補足 * サーバーはAWS上のEC2に構築しようと考えています * DNSの設定も、サブドメインをロードバランサーに転送する設定程度は難なく組めます * Twitter,Facebookなどの他サービスでの認証は今回は考えていません * 現状、Ruby on Railsしか使えません。他言語、他フレームワークでの実装は今回は考えていません。
回答: 認証をOpenID Connectでやるのか、SAMLでやるのか、独自に実装するのかという検討もあるかと思いますが、概ね問題ないのではないでしょうか。 認証提供範囲が独自ドメインのサブドメインのみということであれば、共通ログイン後にcookieでチケットを発行して、各サービスでチケットから認可を判断するという形での対応でも可能だと思います。 cookie情報のみから判断しようとすると、cookieはどうしても改ざんのリスクがあるため、認証サービス側で認証結果を秘密鍵を用いて暗号化し、各サービスは公開鍵で復号、正当性の確認をする等の流れが良いのではないかと思います。 どちらも自分のサービスであれば鍵は共通鍵でも良いかもしれませんが、将来的にサービス数が増えた場合に安全に鍵を配布する手間を考えると、各サービスサーバが定期的に公開鍵をとりにいく形が漏れもなくよいと考えます。 また、鍵ペアは複数登録できるようにしておくことが望ましいです。 秘密鍵の交換を計画した場合に鍵の並行運用ができないと、鍵を差し替えたタイミングで認証済みのチケットが一斉に失効してしまうからです。 もちろん、cookie内のデータ構造を変更したり、何らかのインシデントが発生して必要になったり等で一斉失効を意図的に実施するケースはありえます。 長々と書いていて質問者の方の意図とずれた内容かもしれませんが、何か参考になれば幸いです。