私が行ったすべての調査から、APIキーは(oAuthの使用下で)アクセストークンよりも安全性が低く、監視目的でのみ使用する必要があることがわかりました。
しかし、私が理解したことから、サーバーは両方を生成します。したがって、同じ難しいアルゴリズムを使用してアクセストークンを作成したり、APIキーを作成したりすると、それらは類似したものにならないのではないでしょうか。例は見つけられなかったので、それらをよりよく理解するのに役立ちます。
いくつかの参照: https://cloud.google.com/endpoints/docs/when-why-api-keyhttps://zapier.com/engineering/apikey-oauth -jwt /
APIキーは意図的に公開されています。これらは認証メカニズムではなく、承認メカニズムです(これはリンクに記載されています)。 生成であるかどうかは関係ありませんが、処理であるかどうかは関係ありません。つまり、「このキーを持つ人は誰でも入力できます」です。
したがって、認証する必要があり、認証する必要がない場合は、APIキーを使用します。接続を認証するには、認証トークンを使用します。これは処理で保護されていますです。言い換えれば、「ここにあなたがこの時間に入るためのあなたのユニークなキーがあります」です。
RESTフルアプリケーションの一般的なAPIキーは、通常、アプリケーションレイヤープロトコルメッセージング(順序、構文、データユニット)に関する理由により、OAuth JWT(JSON Webトークン)によって提供されるアクセス制御よりも安全性が大幅に低下します特定の暗号化アルゴリズム、モード、および/またはキーサイズの使用のみから生じる保護とは対照的に、保護(またはその欠如)。ただし、APIキー文字列ジェネレーターがOAuthアクセストークン文字列ジェネレーターよりも予測可能であったとしても、私は驚かないでしょう。 APIキーは、HTTP[〜#〜] get [〜#〜]クエリパラメータとして送信されることが多く、ここではGoogleで示されているように、HTTPリクエストの最初の行にあります。 Maps JavaScript API:
<script async defer src="https://maps.googleapis.com/maps/api/js key=YOUR_API_KEY&callback=initMap" type="text/javascript"></script>
APIキー文字列がHTTP[〜#〜] get [〜#〜]クエリパラメータとして渡されているため、多くの中間Webサーバー(プロキシを含む)、およびJavaScriptやActionScriptなどのクライアント側スクリプト言語を備えたブラウザーが、APIキーへの読み取りおよび/または書き込みアクセスを取得するのが容易になります。これを[〜#〜] put [〜#〜]や[などの他のタイプのHTTPアクションと比較してください〜#〜] post [〜#〜]ここで、クエリパラメータは前述のテクノロジーからより厳密に隠されています。ほとんどすべてのWebサーバーソフトウェアは、src属性値をscriptに書き込みます上記のタグをaccess_logおよび/またはerror_logファイルにAPIキーを含めて、クエリパラメータ変数の値はCGI(Common Gateway Interface)環境変数の一部であるため:SCRIPT_PATHおよびQUERY_STRING。詳細は CWE-598 を参照してください。
一方、OAuthアクセストークンは、セッションごとに生成されます。安全な認証プロバイダーによってアクセストークンが付与されることは、プロバイダーが、要求しているユーザーに要求された特権が与えられているという証明を受け取るまで発生しません。そのような証明は、資格情報(つまり、対応するユーザー名とパスワードのペア)の知識によって確立される場合があります。それ以外の場合、アクセス制御はより制限され、アクセストークンは特定のアプリ/サイト/ API内の特権の小さなサブセットにのみ提供されますサブコンポーネント、操作の領域、制御範囲など。最終的にエンドユーザーに付与されるアクセス許可は、システム管理者が望むのと同じくらいきめ細かくすることができます。アクセストークンは、一定の時間が経過すると期限切れになるようにプログラムされており、さまざまなユーザー/グループ、特権/機能などの間で任意のアクセス制御を提供できることに注意してください。
たとえば、アクセストークンは、HTTPリクエストヘッダーのAuthorizationフィールドのURLの外に転送されることがよくあります。場合によっては、カスタム認証フレームワークの実装により、HttpOnly、SecureおよびSameSiteフラグが有効-またはなどのカスタムHTTPリクエストヘッダーとしてX-Auth-TokenとしてOracleのCloud Storage SaaSに対して公開されているドキュメント: OracleのCloud Storage Service API :
HTTPリクエストヘッダーとCookie値がWebブラウザー/サーバーソフトウェアによってログに記録されることは非常にまれです。 CORS(Cross Origin Resource Sharing)のため、プログラムによるアクセスも困難です。これに比べて、HTTP GETパラメータとして渡されたAPIキーは、DOM(Document Object Model)からクライアント側のJavaScriptで抽出できます。
これらの理由により、OAuthなどの認証フレームワークからアクセストークンを取得するために必要な複雑さは、APIキーの使用状況を記録するために必要な複雑さよりもはるかに高くなります。さらに、認証および承認フレームワークの堅牢性により、アクセストークンをHTTPプロトコル内にカプセル化して、トークンの表示や改ざんがかなり困難になるようにすることができます。