JamstackのAPIと認証

Jamstackアーキテクチャのコアは、「API」（アプリケーションプログラムインターフェイス）にあり、静的なWebサイトに強力な動的関数を提供します。 APIを介して、開発者は複雑さをシフトし、動的機能を静的Webサイトに追加できます。通常、APIにアクセスするには、通常、認証の形で提供されるリクエストの信頼性の検証が必要です（AUTH）は、使用中のサービスと完了するタスクに応じてクライアントまたはサーバー側で実行できます。

さまざまなプロトコルの違いは、APIの異なる認証実装につながります。これらの認証プロトコルと実装の詳細は、APIをJamstackサイトに統合する際に追加の課題を追加します。幸いなことに、これは順不同ではありません。各プロトコルは特定のユースケースにマッピングでき、認証を実装する鍵はこれを理解することです。

これをよりよく説明するために、さまざまなプロトコルとそれらに最適なシナリオに飛び込みましょう。

契約の概要

OAUTH 2.0は、今日の認証に従うという一般的な基準です。 OAUTHは、クライアントとAPIエンドポイントの関係を定義する一連の承認を含む、かなり柔軟な承認フレームワークです。 OAUTHプロセスでは、クライアントアプリケーションは、承認されたエンドポイントからアクセストークンを要求し、そのトークンを使用してAPIエンドポイントのリクエストに署名します。

認可には、許可コード、暗黙的なプロセス、リソース所有者のパスワード、クライアントの資格情報の4つの主要なタイプがあります。それぞれを個別に勉強します。

承認コード認証

すべてのOAuth認証タイプのうち、認証コード認証がおそらく最も一般的です。この承認プロセスは、主にアクセストークンを取得して、ユーザーが許可を明示的に付与した後にAPIリクエストを承認するために使用されます。 2段階のプロセスに従います。

• まず、ユーザーは同意画面（つまり、承認サーバー）に向けられ、個人アカウントとデータにアクセスするためのサービス許可を付与します。
• 許可が得られると、次のステップは、認証サーバーからアクセストークンを取得し、APIエンドポイントのリクエストを認証するために使用できます。

認証コード認証は、他の認証タイプと比較して、ユーザーから明示的な承認を要求するステップを追加することにより、セキュリティの追加レイヤーを追加します。このマルチステップコード交換は、アクセストークンが公開されることはなく、常にアプリケーションと承認サーバーの間の安全なバックエンドチャネルを介して送信されることを意味します。これにより、攻撃者はリクエストを傍受してアクセストークンを簡単に盗むことができません。 GmailやGoogleカレンダーなどのGoogle所有サービスは、この認証コードプロセスを使用して、ユーザーアカウントの個人コンテンツにアクセスします。このワークフローの詳細については、このブログ投稿をご覧ください。詳細をご覧ください。

暗黙の承認

暗黙の承認は承認コード認証に似ていますが、1つの明らかな違いがあります。ユーザー助成金の許可を許可コードを取得し、アクセストークンに交換する代わりに、 URLのスニペット（ハッシュ）部分（つまり、フロントチャネル）をリダイレクトすることですぐにアクセストークンを返します。

承認コードの手順が削減されているため、暗黙的な承認プロセスにはトークン暴露のリスクがあります。トークンはURLに直接埋め込まれているため（およびブラウザの履歴に記録されています）、リダイレクトが傍受されると簡単にアクセスできます。

脆弱性にもかかわらず、暗黙の承認は、単一ページアプリケーションなどのユーザーエージェントベースのクライアントに役立ちます。クライアント側のレンダリングされたアプリケーションでは、アプリケーションコードとストレージに簡単にアクセスできるため、クライアントキーを保護する安全な方法はありません。暗黙のフローは、クライアントのユーザーを認証する迅速かつ簡単な方法をアプリケーションに提供することにより、この問題の論理的なソリューションになります。また、特にクロスドメイン要求をサポートしていないサードパーティの認定サーバーを使用する場合、CORSの問題を解決する効果的な方法でもあります。このアプローチの固有のトークン暴露リスクのため、暗黙のプロセスでのアクセストークンはしばしば一時的であり、更新トークンを発行しないことに注意することが重要です。したがって、このプロセスでは、リクエストごとに特権リソースへのログインが必要になる場合があります。

リソース所有者のパスワード承認

リソース所有者のパスワード承認の場合、リソース所有者はユーザー名とパスワードの資格情報を承認サーバーに送信し、オプションの更新トークンでアクセストークンを送り返します。リソース所有者の資格情報は、クライアントアプリケーションと承認サーバーとの間の承認交換で表示されるため、リソース所有者とクライアントアプリケーションの間に信頼関係がある必要があります。明らかに他の承認タイプほど安全ではありませんが、リソース所有者のパスワード認証は、ファーストパーティクライアントに優れたユーザーエクスペリエンスを提供します。この承認プロセスは、アプリケーションが非常に特権的であるか、デバイスオペレーティングシステムで機能する状況に最適です。通常、この承認プロセスは、他のプロセスが実行不可能な場合に使用されます。

クライアントの資格認証承認

クライアントの資格認証タイプは、クライアントがユーザーコンテキストの外でアクセストークンを取得する必要がある場合に主に使用されます。これは、保護されたリソースへのすべてのアクセスがユーザーからの明示的な許可が付与されることを保証されていない場合、マシン間認証に適用されます。バックエンドで実行されているCLIとサービスは、この承認タイプが役立つインスタンスです。ユーザーログインに依存する代わりに、クライアントIDとキーを渡してトークンを取得し、APIリクエストを認証するために使用できます。

通常、クライアントの資格認証では、アプリケーションが実行されてAPI呼び出しを行うサービスアカウントが作成されます。このようにして、ユーザーは直接関与しておらず、アプリケーションは引き続きリクエストを認証し続けることができます。このワークフローは、特定のユーザーデータではなく、アプリケーションが独自のデータ（分析など）にアクセスしたい場合に非常に一般的です。

結論は

Jamstackサイトは、サードパーティのサービスに依存して複雑な機能を実装するため、セキュリティを維持するために認証ソリューションを慎重に設計することが不可欠です。 Jamstackでデータを交換する主な方法として、APIはその大部分です。 4つの異なるAPIリクエスト認証方法を調べました。それぞれが独自の利点とユーザーエクスペリエンスに影響を与えました。

最初に、これら4つがAPIからデータを要求するために使用される認証の主な形式であると述べました。他にも多くのタイプがあり、oauth.netには非常に良い概要があります。全体として、このウェブサイトは、利用可能な認証の種類だけでなく、OAuthフレームワーク全体も掘り下げられています。

別の方法よりも1つの方法が好きですか？指摘できる使用例はありますか？コメントを共有してください！

以上がJamstackのAPIと認証の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。