目次 認可コードグラントについて CSRFを防御するステート (state) 認可コードグラントの設定 PostmanからAPIリクエストを発行 API操作権限の絞り込み 認可コードグラント＋PKCE について 認可コードグラント＋PKCEの設定 本ブログ記事では、前回に続き、Okta Workforce Identity Cloud (以降、Okta WIC) でのAPIの使い方について解説します。 Okta WICのAPI利用には、以下の2つの方法があります。 (1) Okta WICから発行したトークンを使う。 (2) OAuth 2.0 を使う。 前回は (1) をお伝えしたので、ここでは (2) の方法をお伝えします。 OAuth 2.0の場合にも「トークン」という言葉が登場するので、明確に区別するために、(1) を「APIキー」と呼ぶことにします。 前回ご紹介した (1) の方法は、「予めOkta WICから発行した」APIキーを、APIクライアント (Postman) に仕込んでおいて、そのAPIキーでAPIアクセスを行うものでした。 今回ご紹介するOAuth 2.0は、「Okta WICで認証と認可を行ってから発行される」トークン (＝アクセストークン) を使ってAPIアクセスを行う、という点が、APIキーとは大きく異なる点です。 OAuth 2.0には、アクセストークンを発行する方式がいくつか存在するのですが、本ブログ記事では「認可コードグラント」について解説します。 「グラント: grant」は「(権限を) 付与する」というような意味合いを持ちます。 Okta WICの日本語のAdmin Consoleに「付与」と出てきたら「グラント (grant) のことだな」とご理解ください。 APIクライアントには、前回と同様にPostmanを利用したいと思います。 以降の解説は、以下のブログ記事の内容を実施済み (理解済み) の前提で進めていきます。 ・はじめてのOkta Workforce Identity Cloud (WIC) トライアル環境の構築 ・はじめてのOkta Workforce Identity Cloud (WIC) [第1回] ユーザーと認証器の関係を紐解く ・はじめてのOkta Workforce Identity Cloud (WIC) [第2回] 多要素認証を紐解く ・はじめてのOkta Workforce Identity Cloud (WIC) [第6回] APIってどうやって使うの？ (トークン編) ===== << Tips >> ===== 本ブログ記事でご紹介するOAuth 2.0の「認可コードグラント」方式は、ユーザーの介在 (ユーザーの認証) が必須です。 なので、「あれ？サーバからOkta WICにAPIを発行したいんだけど。その場合にはこの方式って使えないのでは？」という疑問が湧くと思います。 回答としては「はい、その通りです。」となります。 OAuth 2.0を使って、サーバから (ユーザーの介在なしで) Okta WICのAPIを利用するには、「Client Credentials グラント」という方式を使う必要があります。 その方式については、別ブログ記事にてご紹介する予定です。 サーバからAPIを発行したいご要件のみをお持ちの方は、本ブログ記事は「OAuth2.0ってこんな動きをするんだな。」というご理解の一助としてご参照ください。 =================== 認可コードグラントについて 設定に入る前に、まずはOAuth 2.0の用語解説と、認可コードグラントがどの様な動きをするのかを解説します。 リソースとは OAuth 2.0では、「リソース」という言葉がでてきます。 リソースとは、APIを使って取得したり、保存したり、変更したりできるデータのことです。 Okta WICの場合、 管理者であれば、ご自身のOkta WICテナントのほぼ全ての設定情報をAPIで操作できるので、「Okta WICテナントの設定や読出しが可能なデータ全体」がリソースという位置付けです。 OAuth 2.0の4つの役割 OAuth 2.0には、以下 A、B、C、D の4つの役割が存在します。 A.「リソースオーナー」＝ リソースの所有者です。クライアント (Postman) に対して、「APIを使って、私のリソースにアクセスしてください。」と、権限を渡す人＝認可する人 (+ Webブラウザ) です。 B.「クライアント」＝ APIを使って、リソースサーバ (Okta WIC) 上のリソースへアクセスするアプリケーションです。(＝Postmanです。) C.「認可サーバ」＝ リソースオーナーの認証を行って、リソースオーナーからリソースへのアクセス許可.