oAuthとoAuth 2がアクセストークンを持っているのはなぜですか？
ユーザーがプロバイダーに保存するデータにアクセスするためのサードパーティアプリのシステムを実装しようとしています。個別の読み取り/書き込みなどを備えた堅牢なアクセス制御システムがあります。ユーザーが公開したデータの各「ストリーム」のレベル。当社のウェブサイト内では、これらのアクセスレベルは、どのユーザーが別のユーザーのストリームでどのアクションを実行しようとしているかに応じて、すでに実施されています。
今度は、サードパーティのアプリがoAuth2互換の方法で同じことを行えるようにする時が来ました。現在、プロバイダーアプリデータベース内のサードパーティアプリは、ユーザーID、正規URLなどを持つ通常のユーザーとして表されています。したがって、このユーザーIDはアプリのclient_idになります。
私の質問は、なぜoAuthにトークンがあるのですか、それは（スコープなど）を持つ（user_id、client_id）レコードにマップされる本質的に不透明な文字列です）？
アプリは単純にclient_idをAPIキーとして識別し、サーバー間のリクエストに対して対称シークレットでリクエストに署名できませんか？これらの署名された要求と応答は、要求が許可されたときにユーザーがオンラインであるという追加の要件がある場合、必要に応じてユーザーエージェントを介して中継できます。
プロバイダーは（user_id、client_id）のアクセスレコードをすでに格納しているため、クライアントアプリからのリクエストを承認するか拒否するかがわかります。クライアントアプリが追加のトークンを保存して吐き出す必要があるのはなぜですか？
これまでに思いついた唯一のことは、クライアントアプリの対称シークレットへの不正アクセスが発生した場合のセキュリティを強化することです。そして、この方法では、攻撃が取得できるトークンに制限されます（追加の資格情報としてトークンが必要になるため）。サーバー側では、誰かが対称の秘密を取得した場合、おそらくデータベースの資格情報も取得するようです。だから、これはそれほどプラスではありません。
他に理由はありますか？それとも単なるセキュリティシアターだったのでしょうか？
これは、誰かがクライアントアプリの対称シークレットに不正アクセスした場合のセキュリティを強化するためかもしれません。
それが正当な理由の1つです。存続期間の長い共有シークレットの代わりに、存続期間の短いアクセストークンを送信することで、攻撃対象領域を減らします。
他に理由はありますか？
OAuthはいくつかの役割を定義します。多くの場合、リソースは、認証や承認を処理する同じサーバーに存在しません。アクセストークンは、あるサービスによって生成され、実際には誰が何に対して権限を持っているかについて何も知らない別のサービスによって消費される可能性があります。リソースサーバーは、どのユーザーがどのリソースにアクセスできるかを知らない場合がありますが、承認サーバーから有効なアクセストークンが与えられると、アクセスを許可するかどうかを決定できます。
建物内（または国境）のアクセス制御について考えてください。入口の警備員は、許可されたすべての人のリストを持っているとは限らず、あなたに会ったことがない場合もあります。しかし、制限区域の有効なアクセスカード（または国の例ではパスポート）を彼に見せれば、彼はあなたを許可することになっていることがわかります。
これにはいくつかの欠点もあります。アクセスが取り消されたが、アクセスカードを保持できる場合は、たとえあなたがもうやるべきではない場合でも、あなたはまだ中に入るでしょう。これは、アクセスカードに有効期限を設定することで対処できます。これが、アクセストークンの有効期間が通常短いため、盗まれたとしても、長期間使用できないためです。