目次 Client Credentialsグラントについて Client Credentialsグラントの設定 JWTの生成 トークンリクエストの発行とアクセストークンの取得 APIリクエストの発行 まとめ 本ブログ記事では、前回に続き、Okta Workforce Identity Cloud (以降、Okta WIC) でのOAuth 2.0を使ったAPIの使い方について解説します。 前回の「認可コードグラント」は、ユーザーの認証が必要 (=人の介在が必要) なので、「サーバからOkta WICへAPIでアクセスしたい」という場合には使いづらい方式でした。 本ブログ記事では、OAuth 2.0の中でも「Client Credentials グラント」という、ユーザーの認証を必要としない方式について解説します。 OAuth 2.0では「サーバ」という言葉を用いると混乱が生じる気がするので、以降は「マシン」と呼ぶことにします。 Client Credentials グラントでは、認可コードグラントで必要だった「人による認証」のステップが不要になることとの引き換えに、クライアント (マシン) と認可サーバとの間での「事前の情報共有」にて認証を行う必要があります。 Client Credentials グラントの仕様では、その「事前の情報共有」の方式として、認可サーバで生成した「クライアントID」と「クライアントシークレット」をクライアント (マシン) にあらかじめ設定しておき、クライアントはそれらを認可サーバに送って認証する、という方式も規定されています。 しかし、Okta WICのOAuth 2.0 APIでは、セキュリティ的な観点から「秘密鍵/公開鍵を使ったJSON Web Token (JWT)」を使う方式だけがサポートされており、「クライアント ID」 と「クライアントシークレット」の方式を使うことはできません。 「秘密鍵/公開鍵を使ったJSON Web Token (JWT)」も「事前の情報共有」方式ですが、認可サーバはあらかじめ公開鍵を保持し、クライアント (マシン) は、自身が保持する秘密鍵で署名した情報を認可サーバに送り (=秘密鍵は送らない)、認可サーバは公開鍵を使ってその署名を検証することで認証する、という方式です。 (ちなみにJWTは「ジョット」と読みます。) 以降の解説は、以下のブログ記事の内容を実施済み (理解済み) の前提で進めていきます。 ・はじめてのOkta Workforce Identity Cloud (WIC) トライアル環境の構築 ・はじめてのOkta Workforce Identity Cloud (WIC) [第1回] ユーザーと認証器の関係を紐解く ・はじめてのOkta Workforce Identity Cloud (WIC) [第2回] 多要素認証を紐解く ・はじめてのOkta Workforce Identity Cloud (WIC) [第6回] APIってどうやって使うの? (トークン編) ・はじめてのOkta Workforce Identity Cloud (WIC) [第7回] APIってどうやって使うの? (OAuth 2.0 認可コード編) Client Credentialsグラントについて 設定に入る前に、まずはOAuth 2.0の用語解説と、Client Credentials グラントがどの様な動きをするのかを解説します。 OAuth 2.0の4つの役割 OAuth 2.0には、以下 A, B, C, D の4つの役割が存在します。 A.「リソースオーナー」= リソースの所有者です。Client Credentialsの場合は「マシン」が該当します。 B.「クライアント」= APIを使って、リソースサーバ (Okta WIC) 上のリソースへアクセスするアプリケーションです。Client Credentialsの場合は、これも「マシン」が該当します。 C.「認可サーバ」= クライアント (マシン) の検証を行って、問題なければ「アクセストークン」を発行するサーバです。(=Okta WICです。) Client Credentialsの場合は「認可エンドポイント」は登場せず、「トークンエンドポイント」だけが登場します。 D.「リソースサーバ」= クライアント (マシン) からの、アクセストークンを持ったAPIリクエストを受け取って、それに問題がなければ、要求されたリソースを返すサーバです。(=Okta WICです。) ===== << Tips >> ===== 前回に続き今回においても「Okta WICのAPI」に言及している関係で、「C.認可サーバ」も「D.リソースサーバ」もOkta WICに同居している記載にしていますが、それらは全く異なる役割を担っているので、頭の中では「それぞれ別々に存在している」とお考え頂く方が、OAuthへの理解は深まると思います。 実際、認可サーバはOkta WICを使うけれども、リソースサーバはA社やB社を使う、というケースも多いです。(その場合、Okta.