Skip to main content

This is documentation for Caché & Ensemble. See the InterSystems IRIS version of this content.Opens in a new tab

For information on migrating to InterSystems IRISOpens in a new tab, see Why Migrate to InterSystems IRIS?

OAuth 2.0 および OpenID Connect の概要

この章では、OAuth 2.0 承認フレームワークと OpenID Connect の概要を説明します。次の章では、OAuth 2.0 および OpenID Connect に対する Caché のサポートについて説明します。

基本

OAuth 2.0 承認フレームワークを使用すると、サードパーティのアプリケーション (一般にクライアントと呼ばれる) による HTTP サービス (リソース) への限定的なアクセスを可能にすることができます。このアクセス制限により、クライアントが取得できる情報や使用できるサービスが限定されます。承認サーバは承認のやりとりを調整するか、アクセス権を直接付与します。OpenID Connect は、このフレームワークを拡張して認証を追加します。

ロール

OAuth 2.0 フレームワークでは、次の 4 つのロールが定義されています。

  • リソース所有者 — 通常はユーザです。

  • リソース・サーバ — 保護されているデータやサービスをホストするサーバです。

  • クライアント — リソース・サーバへの限定的なアクセスを要求するアプリケーションです。これは、クライアント・サーバ・アプリケーションの場合もあれば、サーバを持たないアプリケーション (JavaScript アプリケーションやモバイル・アプリケーションなど) の場合もあります。

  • 承認サーバ — リソース・サーバへのクライアントのアクセスを可能にするアクセス・トークンの発行を担うサーバです。このサーバは承認サーバと同じアプリケーションにすることも、異なるアプリケーションにすることもできます。

クライアント、リソース・サーバ、承認サーバは事前の準備によって相互に認識します。承認サーバは、通信可能なクライアント・サーバとリソース・サーバを指定したクライアントのレジストリを保持しています。クライアントが登録されると、承認サーバはクライアント IDクライアント秘密鍵を生成します。クライアント秘密鍵は秘密にしておく必要があります。クライアントが承認サーバと通信する方法によっては、クライアント・サーバでクライアント秘密鍵が必要になることもあります。その場合は、クライアント秘密鍵をクライアント・サーバへ安全に伝える必要があります。JavaScript アプリケーションなどの一部のシナリオでは、クライアントはクライアント秘密鍵を保護することができません。このようなシナリオでは、クライアントはクライアント秘密鍵を必要としない方法で承認サーバと通信しなければなりません。

アクセス・トークン

アクセス・トークンには、ユーザやクライアントの ID に関する情報がメタデータと共に格納されます。このメタデータは有効期限、予期される発行者名、予期される対象者、スコープなどで構成されます。

通常、アクセス・トークンの目的は、HTTP 経由で提供されるリソース・サーバの特定のデータやサービスにクライアントがアクセスできるようにすることです。全体的な流れでは、クライアント・アプリケーションが承認サーバにアクセス・トークンを要求します。クライアントは、受け取ったアクセス・トークンをリソース・サーバへの HTTP 要求で使用します。リソース・サーバは、受け取った要求に有効なアクセス・トークンが含まれている場合にのみ、要求された情報を返します。

アクセス・トークンは取り消すこともできます (承認サーバがこの機能をサポートしている場合)。

アクセス・トークンの形態

Caché は、次の 2 種類のアクセス・トークンをサポートしています。

  • JSON Web Token (JWT)。JWT は JSON オブジェクトです。JWT はデジタル署名か暗号化またはその両方を行うことができます。

    JWT の 1 種が ID トークンであり、OpenID Connect に固有のトークンです。

    JWT は署名か暗号化またはその両方を行うことができます。

  • opaque アクセス・トークン (別名:参照トークン)。この形態のアクセス・トークンは、他の場所、具体的には承認サーバに格納されているトークンの識別子です。この識別子は長いランダムな文字列であり、これには推測を困難にするという意図が込められています。

クレーム

アクセス・トークンには、ユーザまたはクライアントの ID の伝達や、トークンの有効期限、予期される発行者名、予期される対象者、スコープなどのメタデータの伝達を行う一連のクレームが含まれています。OpenID Connect Core の仕様ではクレームの標準セットが定義されていますが、その他のクレームも使用できます。

JWT および JWKS

上記のように、JWT は署名か暗号化またはその両方を行うことができます。ほとんど場合、OAuth 2.0 フレームワークの参加者は、この目的で JWKS (JSON Web Key Set) のペアを使用します。JWKS の任意のペアにおいて、一方の JWKS は秘密鍵で、(アルゴリズムあたり) 必要なすべての秘密鍵だけでなく、対称鍵として使用するクライアント秘密鍵も含んでいます。この JWKS は共有されません。他方の JWKS には、対応する公開鍵が含まれていて、公開されて利用できます。

それぞれの参加者は、秘密の JWKS を持っていて、対応する公開の JWKS を他の参加者に提供します。秘密の JWKS の所有者は、その JWKS を使用して、送信 JWT に署名し、受信 JWT を解読します。他の参加者は、以下の図に示すように、対応する公開の JWKS を使用して送信 JWT を暗号化し、受信 JWT の署名を確認します。

generated description: jwks

付与タイプと付与フロー

OAuth 2.0 フレームワークでは、承認サーバが承認の要求を処理する方法が付与タイプによって指定されます。クライアントは、承認サーバへの最初の要求に付与タイプを指定します。OAuth 2.0 仕様には 4 つの付与タイプと、追加のタイプを定義する拡張メカニズムが記載されています。通常、それぞれの付与タイプは異なる全体フローに相当します。

4 つの付与タイプは以下のとおりです。

  • 承認コード — この付与タイプは対応するサーバを持つクライアント・アプリケーションでのみ使用することができます。この付与タイプでは、ユーザがユーザ名とパスワードを入力するログイン・ページが承認サーバによって表示されます。これらの情報はクライアントと共有されることはありません。ユーザ名とパスワードが有効なユーザと一致すると (要求の他の要素が適切な場合)、承認サーバは最初に承認コードを発行し、これをクライアントに返します。クライアントは、この承認コードを使用してアクセス・トークンを取得します。

    承認コードの要求はブラウザに表示され、その応答も同様です。一方、アクセス・トークンの要求はサーバ間のやりとりであり、その応答も同様です。したがって、アクセス・トークンはブラウザに表示されることはありません。

  • 暗黙 — 前述の付与タイプと同様に、承認サーバはログイン・ページを表示しますが、クライアントはユーザの資格情報にアクセスすることはできません。ただし、この暗黙付与タイプでは、クライアントがアクセス・トークンを直接要求して受け取ります。この付与タイプは、JavaScript クライアントやモバイル・アプリケーションなどの純正のクライアント・アプリケーションで役立ちます。

  • リソース所有者のパスワード資格情報 — この付与タイプでは、クライアントがユーザ名とパスワードを入力するようにユーザに要求し、それにより得られた資格情報を使用して承認サーバからアクセス・トークンを取得します。信頼できるアプリケーションだけがこの付与タイプに適しています。

  • クライアント資格情報付与タイプ — この付与タイプではユーザ・コンテキストは存在せず、クライアント・アプリケーションは人の介入なしに処理を行います。クライアントは、クライアント ID とクライアント秘密鍵を使用して承認サーバからアクセス・トークンを取得します。

通常、OAuth 2.0 フレームワークでは、すべての HTTP 要求が SSL/TLS で保護されています。

さらに、クライアントが承認サーバに要求を送信するときは、その要求を認証する必要があります。OAuth 2.0 仕様に、クライアントが要求を認証する方法が記述されています。

スコープ

承認サーバは、クライアントが scope 要求パラメータを使用してアクセス要求のスコープを指定するのを許可します。 次に、承認サーバは scope 応答パラメータを使用して、発行したアクセス・トークンのスコープをクライアントに通知します。

OpenID Connect は OAuth 2.0 承認プロセスの拡張機能です。認証を要求するために、クライアントは承認サーバへの要求に openid スコープ値を組み込みます。承認サーバは、認証に関する情報を ID トークンと呼ばれる JWT で返します。ID トークンには、OpenID Connect Core 仕様に記載されている特定のクレーム・セットが含まれています。

承認サーバのエンドポイント

承認サーバは、さまざまな種類の要求を処理できる、以下の URL またはエンドポイントの一部またはすべてを提供します。

エンドポイント 目的
承認エンドポイント 承認コードを返します (承認コード付与タイプにのみ適用)。
トークン・エンドポイント アクセス・トークンを返します。
Userinfo エンドポイント 認証されたユーザに関するクレームを収めた JSON オブジェクトを返します (OpenID Connect にのみ適用)。
トークン・イントロスペクション・エンドポイント アクセス・トークンを調べて決定したクレームを収めた JSON オブジェクトを返します。
トークン取り消しエンドポイント トークンを取り消します。

関連項目

InterSystems Developer Community では、OAuth 2.0 と OpenID Connect について次の記事を提供しています。

FeedbackOpens in a new tab