私は OAuth 1.0a プロバイダーを実装し、標準の 3-legged 認証を使用して正常に認証できる OAuth クライアントを持っています。
OAuth はサーバー上の REST API を保護しており、それを使用するモバイル アプリがあります。
私のモバイル アプリには、エンド ユーザーがプライベート アカウントにログインする前でもアクセスできる機能 (エンドポイント) がいくつかあります。
一部のユーザーは、アカウントを作成せずにパブリック機能を使用したい場合さえあります。
「パブリック」エンドポイントと「プライベート・ツー・ユーザー」エンドポイントの両方を OAuth で保護したいと考えています。
したがって、次の方法で OAuth を使用する方法だと思います (ただし、間違っている可能性があります... 非常に間違っています)。
モバイル アプリは、アプリが初めて起動されるとすぐに、最初に 2-legged 認証を行います。そうすれば、モバイル アプリは "2-legged" トークンを取得します。モバイル アプリは、このトークンを使用してパブリック エンドポイントにアクセスします。
ユーザーがアプリケーションへのログインを要求すると、モバイル アプリは 3-legged 認証を実行し、「3-legged トークン」を取得します。これ以降、アプリは以前の 2-legged トークンを忘れ、3-legged トークンを使用してパブリック エンドポイントとプライベート エンドポイントの両方にアクセスします。
1) 最初の質問。それは理にかなっていますか？それを行う別の良い方法はありますか？
今私の問題は次のとおりです。モバイルアプリが2-leggedを使用して認証するかどうかを私（サーバープロバイダー）はどのように知ることができますか? プロバイダーとして、ユーザーが入力するログインフォームにクライアントをリダイレクトするか (3-legged の場合)、または既に承認されたリクエストを発行するかを決定するために、そのことを知る必要があると思います。トークン (2-legged の場合) をアクセス トークン (3-legged の場合) と交換できるようにします。
これを行うための私のアイデアは、クライアントに 2 つのコンシューマー キーを提供することでした。私はプロバイダーとして、受け取ったコンシューマー キーに基づいて提供するフローを認識します。
2) 2 番目 (そして最後の質問)。これは賢明ですか？それを実装するより良い方法はありますか？
クライアント (消費者) が空のアクセス トークンを送信できるようにするだけで 2-legged を実装している人を見てきました。代わりに、その方法はありますか？
ありがとう。