フォーラムでいくつかのリソースを検索しました。
シングル サインオン/トークン ベースの認証プロセスの実装に関するアイデアを飛び交っています。大まかに、要件は次のようになります。
- ユーザー Web アプリ / モバイル アプリ / モバイル Web など
- システム 1: ユーザー情報とログイン情報、トークンの生成、およびいくつかのサービスの提供 (例:
getUserData) - システム 2: ユーザー固有のデータを管理する外部関係者
- システム 3: システム 2 のようなさらに別の外部パーティ
- ユーザーはシステム 1 で 1 回サインインするだけで、システム 2 およびシステム 3 と通信できます。
銀行、または Mint.com のようなものを考えてみてください。初期設定後、ユーザーは Mint を介して一度サインインすることができ、その後、銀行 (および場合によっては複数の銀行機関) にアクセスできます。したがって、1 回のサインインでさまざまなシステムにアクセスできます。ただし、私の場合、Mint.com が行っているのは読み取り専用アクセスだけではありません。
私の最初の考えは大まかに次のようになります。
User Sign In ----> System 1, login verification generate token for itself (call it token1)
System 1 ---> generate token and pass it to System 2 (call it token2)
System 1 ---> generate token and pass it to System 3 (call it token3)
System 1 ---> return [token1, token2, token3]
ここから、ユーザー (つまり、アプリやサイトなど) は、通信に使用できる 3 つのトークンを持ちます。ユーザーがアクションを実行する必要がある場合、またはシステム 1 からデータを取得する必要がある場合、システム 2 およびシステム 3 ではリクエストとともに token1 が渡されます。
このアプローチは理にかなっていますか？
もちろん、これにはセキュリティ上の懸念があります-トークンが途中で盗まれ、そのトークンを持つ誰かがそのトークンが対象とするシステムでアクションを実行できる場合-明らかに、これは銀行システムなどにとって悪いことです.
システムは、トークンを実際に提供するリクエスト送信者が、トークンが生成された正当なユーザーであることをどのように確認しますか?
1つの考えは、2番目の認証レベルです。ユーザーがリクエストを行うたびに、リクエスト内のトークンと一緒に特別なコード (銀行カードの PIN など) を入力する必要がありますが、これは面倒ではありませんか? 要求ごとに、ユーザーは PIN を入力する必要があります。
ご意見やご感想をお待ちしております。
編集： 私はすでにOAuthを見てきました...私の理解が進む限り、トークンを生成し、OAuthプロバイダー自体でそれを使用できるようにするOAuthプロバイダーを実装する必要があります。つまり、OAuthプロバイダーはシステムです# 1 - しかし、システム 2 と 3 がその OAuth トークンも受け入れるようにするにはどうすればよいですか? または、OAuth を誤解している可能性があります。
また、OAuth の使用が私が望む方法 (システム 1、システム 2、システム 3 など) で機能する場合でも、疑問が残ります。外部の悪意のある人物がそのトークンにアクセスした場合はどうなるでしょうか? トークンを使用している人が承認された当事者であることを確認するにはどうすればよいですか?