OAuth2の基本

OAuth2とは

OAuth 2.0 は、認可パーミッションとトークンメカニズムを核とする認可プロトコルです。
これにより、第三者にユーザー名とパスワードを直接与えるのではなく、第三者にアクセストークンを発行することで、第三者がユーザーに代わってユーザーのデータにアクセスできるようになります。
これは主に Web API インターフェースを保護するために使用され、第三者は認可とアクセストークンを取得した後にのみ API にアクセスできます。
これにより、セキュリティリスクを増大させることなく、サードパーティソフトウェアがユーザーに代わってデータに安全にアクセスできるようになります。
一般的な認証プロセスには、ユーザーのログイン、ユーザーの認証、認証コードの発行、サードパーティによるアクセストークンの認証コードの交換、およびサードパーティによるアクセストークンを使用したデータの取得が含まれます。
OAuth 2.0 は、WeChat を使用した他のアプリへのログイン、WeChat アプレットの使用など、多くのシナリオで使用されます。
認証コード許可は、OAuth 2.0 の最も完全で安全な認証方法です。
OAuth 2.0 の中心的な考え方はさまざまなシナリオに適用でき、ユーザーエクスペリエンスを向上させながら通信のセキュリティを確保します。

認証コードの要件

OAuth2.0 では、アクセストークンは高度な機密性が必要であり、ブラウザーに直接公開することはできません。認証コードを使用しない場合、アクセストークンを取得するときにバックエンド経由でのみ通信でき、ユーザーとクライアントの間に「接続」を確立できません。
認証コードを使用すると 2 つのリダイレクトを実現できるため、セキュリティが確保されるだけでなく、ユーザーエクスペリエンスも向上します。最初のリダイレクトは認証コードを取得するために使用され、2 番目のリダイレクトはユーザーとクライアント間の接続を再確立するために使用されます。
一時的な認証情報として、認証コードはフロントエンドで公開できますが、アクセストークンはバックエンドでのみ転送できます。これにより、通信セキュリティの要件を満たすだけでなく、スムーズなユーザーエクスペリエンスも実現します。
認可コードは、認可コードを取得する間接通信とアクセストークンを取得する直接通信の組み合わせを実現し、OAuth2.0の4つの役割の相互作用を完璧に整理します。
認証コード許可の考え方は他のシナリオにも移植でき、たとえば、WeChat ミニプログラムでも同様のプロセスが使用されます。
一般に、認可コードメカニズムにより、認可コードパーミッションタイプは OAuth2.0 で最も完全で安全な認可プロセスになります。

作業過程

認可サービスのワークフローは次のように要約できます。

認可サービスはアクセストークンの発行を担当し、OAuth 2.0 の中核となります。
その作業は、認証コードの発行とアクセストークンの発行の 2 つの部分に分けることができます。
認可コードの発行には、基本情報の確認、権限範囲の確認、認可ページの生成などの準備作業が必要です。
ユーザーが認可された後、引き続き許可スコープの検証、認可コードの生成とバインド、コールバックアドレスのリダイレクトを行います。
アクセストークンを発行するには、サードパーティソフトウェア情報の検証、認可コードの検証、アクセストークンの生成、および情報のバインドが必要です。
同時に、リフレッシュトークンが生成され、期限切れ後にアクセストークンを再取得するために使用されます。
リフレッシュトークンを使用するには、情報を確認し、アクセストークンを再生成する必要があります。
最小権限の原則を確実にするために、プロセス全体を通じて権限の範囲を検証する必要があります。
認可サービスにより複雑さが取り除かれ、サードパーティソフトウェアが OAuth 2.0 にアクセスしやすくなります。

JWTトークン

JWT トークンに関して、次の重要なポイントを要約できます。

JWT は、HEADER、PAYLOAD、SIGNATURE を含む構造化トークン形式です。
HEADERはヘッダー情報、PAYLOADはデータ本体、SIGNATUREは署名を表します。
JWT では、データベースや RPC クエリを必要とせずに、トークンにユーザー認証情報を含めることができます。
JWT を使用すると、トークンの内部検査を実装でき、保護されたリソースは JWT を直接解析できます。
JWT の利点は、ストレージの代わりにコンピューティングを行うこと、暗号化を強制すること、システムの可用性を高めることです。
JWT の欠点は、使用中にトークンのステータスを変更できないことと、キー管理のサポートが必要なことです。
トークンには、自然有効期限、リフレッシュトークンの使用、およびアクティブな失効という 3 つのライフサイクルがあります。
サードパーティソフトウェアにとって、トークンは不透明なままであるため、コアサービスはトークンに注意を払う必要があります。
JWT は、状態に依存せずに情報を安全に送信する必要があるシナリオに適しています。

OAuth 2 に安全かつ迅速にアクセスする方法

OAuth 2.0 にアクセスするサードパーティソフトウェアと保護されたリソースサービスに関しては、次の点を要約できます。

サードパーティソフトウェアは、登録情報、ブート認証、アクセストークンの使用、およびリフレッシュトークンの使用に注意を払う必要があります。
認可を起動するとき、ユーザーは認可のために認可サービスにリダイレクトされる必要があります。
アクセストークンを使用する場合は、URI クエリパラメーターやリクエストヘッダーフィールドではなく、フォームパラメーターとしてアクセストークンを送信することをお勧めします。
リフレッシュトークンを使用する場合は、頻繁な再認可を避けるため、アクセストークンの有効期限に注意する必要があります。
保護されたリソースサービスでは、アクセストークンを検証し、アクセス許可の範囲に注意を払う必要があります。一般的に使用されるアクセス許可には、さまざまな操作、データ、ユーザーに対応するさまざまなアクセス許可が含まれます。
API ゲートウェイを使用して権限の検証を均一に処理し、リソースサービスごとにこのロジックが重複するのを避けることができます。
サードパーティソフトウェアはトークンの取得と使用を処理し、リソースサービスはトークンの検証とアクセス許可制御を処理します。
どちらも自分の責任に集中するだけでよく、OAuth 2.0 の複雑なプロセスをすべて扱う必要はありません。

OAuth3 認証タイプ

OAuth 2.0 では、次の 4 つの認証タイプが定義されています。

認可コードグラント

認証コードの一時認証情報を通じてアクセストークンを取得します。これは、最も完全なプロセスと最高のセキュリティを備えています。

暗黙的な許可

アクセストークンはフロントエンド通信で直接返され、認証コードは必要ありません。純粋なフロントエンドアプリケーションに適しています。

リソース所有者のパスワード認証情報の付与

ユーザー名とパスワードを使用してアクセストークンを直接取得します。信頼性の高い公式ソフトウェアに最適です。

クライアント資格情報の付与

クライアントは、ユーザーの参加なしに、app_id と app_secret を通じて直接アクセストークンを取得します。公開データへのアクセスに適しています。

これら 4 つの認証タイプの主な違いは、アクセストークンの取得方法です。認可タイプを選択するときは、アプリケーションのシナリオとセキュリティ要件に基づいて比較検討し、よりセキュリティの高い認可コード権限タイプを優先する必要があります。

OAuth2.0 の 4 つの認可タイプについて、重要な点をまとめると次のようになります。

認証コード許可タイプは、最も完全なプロセスと最高のセキュリティを備えた認証方法です。
リソース所有者の認証情報ライセンスは公式ソフトウェアで利用でき、ユーザー名とパスワードを使用してトークンを取得します。
クライアント資格情報のアクセス許可は、app_id と app_secret を使用してトークンを取得することにより、公開データを取得するために使用されます。
暗黙的なアクセス許可は純粋なブラウザ側アプリケーションに適しており、フロントエンドでアクセストークンを直接返します。
認証タイプを選択する際は、認証コードライセンスを優先し、実際のシナリオに基づいて最適なタイプを選択してください。
4 つの認可タイプの最大の違いは、アクセストークンの取得方法です。
すべてのタイプは、実際のシナリオでの認証の問題を解決するように設計されており、特定の状況に基づいて選択する必要があります。
ブラウザ以外の環境では、クライアントの資格情報のアクセス許可またはリソース所有者の資格情報のアクセス許可を考慮してください。
セキュリティ優先の原則に従って、最適な認証タイプを選択してください。