はじめてのOkta Workforce Identity Cloud (WIC) [第7回] APIってどうやって使うの？ (OAuth 2.0 認可コード編)
目次
- 認可コードグラントについて
- CSRFを防御するステート (state)
- 認可コードグラントの設定
- PostmanからAPIリクエストを発行
- API操作権限の絞り込み
- 認可コードグラント＋PKCE について
- OAuth 2.0 認可コードグラント＋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.「認可サーバ」＝ リソースオーナーの認証を行って、リソースオーナーからリソースへのアクセス許可 (認可) が得られれば、クライアント (Postman) へ「アクセストークン」を発行するサーバです。(＝Okta WICです。)
認可サーバは、以下2つの役割に分かれています。
C-1.「認可エンドポイント」＝ リソースオーナーの認証を行って、リソースオーナーからリソースへのアクセス許可 (認可) が得られれば、「認可コード」という一時的なチケットのようなものを発行します。
C-2.「トークンエンドポイント」＝ 認可エンドポイントから発行された「認可コード」に加え、 予めクライアント (Postman) に設定しておいた「クライアントID」と「クライアントシークレット」を受け取って、それらに問題がなければ「アクセストークン」を発行します。
D.「リソースサーバ」＝ クライアント (Postman) からの、アクセストークンを持ったAPIリクエストを受け取って、それに問題がなければ、要求されたリソースを返すサーバです。(＝Okta WICです。)
認可コードグラントの流れ
上記の役割を踏まえ、以下の図を用いてOAuth 2.0 認可コードグラントの流れを説明します。
・下図の流れは、Okta WICおよびPostmanに必要な設定は完了している前提です。
・下図の変数名は、日本語で表現しています。(厳密さは欠きますが、分かりやすさを優先して。)
・Postmanの場合、Postmanに埋め込まれたWebブラウザが使われるので、実際の操作では個別のWebブラウザ (Google Chrome等) は利用しません。
(0) リソースオーナー ([email protected]) は、アクセストークンを入手するために、Postmanの「Get New Access Token」ボタンを押します。
(1) 上記(0)によってクライアント (Postman) から送り出された認可リクエストが、リソースオーナーのWebブラウザでリダイレクトされ、認可サーバの認可エンドポイント (https://xxxxx.okta.com/oauth2/v1/authorize) へ送られます。
この認可リクエストは、以下の値を含んでいます。
・「クライアントID ＝ abc1234」: 事前に認可サーバからクライアント用に発行されたIDで、事前にクライアントに設定されている値です。
・「レスポンスタイプ = code」: 認可エンドポイントに対して「認可コードを発行してください。」と伝えています。
・「スコープ = okta.users.read okta.groups.read」: 『「ユーザー情報」と「グループ情報」を取得したいです！』という宣言です。
・「リダイレクトURI = http://localhost:8080/authorization-code/callback」: 下記 (5) の認可レスポンスを受け取る宛先を、認可エンドポイントに伝えています。
リダイレクトURIは攻撃者が偽造しやすい値なので、認可サーバ側にも事前に登録しておき、認可サーバ側で一致するかどうかを確認します。
・「ステート = state-mojiretu」: クロスサイトリクエストフォージェリ (CSRF) 攻撃から守るための値です。これについては後述します。
(2) 認可エンドポイントは、上記 (1) のスコープに問題がない (＝クライアント (Postman) から要求されたスコープのうち、一つでも許可する設定になっている) なら、認証画面にて認証を要求します。
(3) リソースオーナー ([email protected]) は、認証情報 (ID/パスワード等) を入力します。
===== << Tips >> =====
※ OAuth 2.0 の一般的な流れでは、上記 (3) のリソースオーナーの認証の後に、認可エンドポイントからリソースオーナーに対して、『クライアント(Postman) が「ユーザー情報 (=okta.users.read)」と「グループ情報 (=okta.groups.read)」の取得を希望していますが、許可しますか？』という、意思の確認が行われます。
この処理が「認可」に該当するものになりますが、Okta WICのOAuth 2.0 APIの場合には、この意思確認は省略されており、上記 (3) でリソースオーナーが認証することによって、暗黙的に認可されるようになっています。
====================
(4) 認可エンドポイントは、リソースオーナーの認証 (と同時に認可) が成功したら「認可コード」を生成します。
(5) 認可エンドポイントは、「認可コード」と「ステート」を含む認可レスポンスを発行し、リソースオーナーのWebブラウザでリダイレクトされ、上記 (1) のリダイレクトURI (http://localhost:8080/authorization-code/callback) ＝クライアント (Postman) へ送られます。
(6) クライアント (Postman) は、以下の値を持ったトークンリクエストを、認可サーバのトークンエンドポイント (https://xxxxx.okta.com/oauth2/v1/token) に向けて発行します。
・「クライアントID ＝ abc1234」: 事前に認可サーバからクライアント用に発行されたIDで、事前にクライアントに設定されている値です。
・「クライアントシークレット = himitsu-no-mojiretu」: 事前に認可サーバからクライアント用に発行されたシークレット値で、クライアントIDと同様に、事前にクライアントに設定されている値です。
・「グラントタイプ = authorization_code」: トークンエンドポイントに対して、「認可コードグラントの方式でアクセストークンを発行してください。」と伝えています。
・「リダイレクトURI = http://localhost:8080/authorization-code/callback」: もうこの段階以降ではリダイレクト先として利用することはありませんが、セキュリティの観点で、認可サーバに登録されている値と一致するかどうかを認可サーバが確認するために送ります。
・「認可コード」: 上記 (5) で受け取った、「リソースオーナー ([email protected]) の認証 (と同時に認可) が成功したことを示す情報」です。
(7) トークンエンドポイントは、上記 (6) の情報を受け取って、それらが問題ないと判断したら「アクセストークン」を生成します。
(8) トークンエンドポイントは、「アクセストークン」を含むトークンレスポンスをクライアント(Postman) へ送ります。
この (8) までのステップで、クライアント (Postman) は「アクセストークン」を受け取ることができたので、一区切りです。
以降は、クライアント (Postman) から「アクセストークンを含んだAPIリクエスト」をリソースサーバへ送ることで、Okta WICからユーザーやグループの情報を得ることが可能になります。(クライアントと認可サーバのスコープ値次第で、APIを使った設定 (ユーザーやグループの追加や削除等) も可能になります。)
以下、一例です。
(9) クライアント (Postman) は、リソースサーバに対して、グループ情報を得るためのURL (https://xxxxx.okta.com/api/v1/groups) へ、アクセストークンを含むAPIリクエストを送ります。
(10) リソースサーバは、アクセストークンを評価し、スコープ値に「okta.groups.read」が存在しているので問題ない (＝リソースオーナーの認可が得られている) と判断して、グループ情報を返答します。
CSRFを防御するステート (state)
認可リクエスト内に「ステート (state)」という値が存在しています。
この値によって、クロスサイトリクエストフォージェリ (CSRF) という攻撃を防ぐことができます。
(CSRF攻撃がどのようなものなのかについては、IPA様の記事がご参考になるかと思います。)
CSRF攻撃が成立する流れ ＝ ステートがない場合
まず、ステートが存在しなかったらどうなってしまうのかを解説します。
PostmanとOkta WICだとイメージしにくいので、解説には以下の架空のサイトを用います。
・(Postmanの代わりに) ファイルをアップロード保存できる機能を持つWebサイト (goodweb.shop)
・(Okta WICの代わりに) 実際のファイルの保存先であり、認可サーバも兼ねたサイト (storager.xyz)
(a) 「スコープ」では、 read (読み出し) に加え、write (書き込み) も要求しています。
(b)「ステート」が存在しない状態を想定します。
(c) 攻撃者である[email protected] (以降、Waruo) は、自身のアカウントで正当なユーザーとしてgoodweb.shopにアクセスします。
Waruoは正当なユーザーなので、Waruoの認可コードが生成されます (上図 (4) ) 。
(d) Waruoは、上図 (5) の認可レスポンスがリダイレクトされる前に、何らかの方法で止めます。
(e) 被害者である[email protected] (以降、Zsaku) は、すでにgoodweb.shopにアクセスしている状態でした。
(f) Waruoはメール等を使って、上図(5)のリダイレクト後のLinkをZsakuに送ります。
そして、残念ながらZsakuは、そのLinkをクリックしてしまいました。
その結果、Zsakuのブラウザでありながら、Waruoとして上図 (8) までの処理が完了してしまいます ＝ Waruoのアクセストークンが発行されてしまいます。
(g) Zsakuは、ブラウザを再起動することなく、goodweb.shopサイトでファイルを保存しました。
(h) ファイルの保存はできましたが、Waruoのリソースに保存してしまいました ＝ 情報漏洩です。
CSRF攻撃が失敗する流れ ＝ ステートがある場合
ステートが存在することで、上記のCSRF攻撃を防ぐことができます。
ポイントは『「ステート」と「セッションCookie」を紐づける』という点です。
以下は、「CSRF攻撃が成立する流れ ＝ ステートがない場合」とは異なるポイントだけ解説します。
(b) クライアント (goodweb.shop) は、「ステート」と「セッションCookie (W)」を紐付けて覚えておきます。
(f) Waruoはメール等を使って、上図(5)のリダイレクト後のLinkをZsakuに送ります。
そして、残念ながらZsakuは、そのLinkをクリックしてしまいました。
しかし、WaruoとZsakuのブラウザは異なるので、Zsakuのブラウザは、上図(1)〜(5)の「セッションCookie (W)」とは異なる値 ＝「セッションCookie (Z)」で、goodweb.shopにアクセスします。
(g) クライアント (goodweb.shop) は、到着した「ステート」と「セッションCookie (Z)」 の組合せが、記憶していたものと異なる (＝「セッションCookie (W)」ではない) ことが分かります。
この判定によって、クライアントはこれをCSRF攻撃であると判断し、後続処理は行わないことで、この攻撃を防御します。
認可コードグラントの設定
それでは、上記の流れを実現する設定を行いましょう。
Okta WICのAPI用アプリケーションの設定
Okta WICがOAuth 2.0 APIリクエストを受け取るためには、アプリケーションの設定が必要です。
「アプリケーション」→「アプリケーション」→「アプリ統合を作成」をクリックします。
「OIDC - OpenID Connect」を選択後、「Webアプリケーション」を選択して「次へ」をクリックします。
「アプリ統合名」に任意の値を入力してください。(ここでは「Okta User-based API」としました。)
付与タイプ (Grant Type) は、デフォルトで「認可コード」が選択されています。
この画面の下部の「割り当て」→「アクセス制御」では、「今はグループの割り当てをスキップ」を選択します。(後ほど、このアプリに個別にユーザー ([email protected]) を割り当てます。)
「保存」をクリックします。
「一般」タブで、「クライアントID」と「クライアントシークレット」のコピーボタンをクリックしてコピーし、一時的にどこか (メモ帳アプリなど) に保管してください。
これらの値は、後のPostmanの設定に使います。
(「追加の検証としてPKCEを要求」は現時点ではOFFであること確認してください。後の章で有効にします。)
加えて、スクロールダウンして表示される「サインインリダイレクトURI」もコピーして、一時的に保管してください。
この値も、後のPostmanの設定に使います。
「割り当て」タブで、ユーザーを割り当てます。
OAuth 2.0の4つの役割でいうところの「リソースオーナー」です。
本ブログ記事では「[email protected]」を割り当てました。
「Okta APIのスコープ」タブをクリックします。
「Okta APIのスコープ」では、APIで操作できる範囲をどうするのか (情報の読み出しだけなのか、設定変更もできるようにするのか、等) を決めます。
ここでは、クライアントに対して「グループとユーザーの情報提供だけを許可する」＝「設定変更は許可しない」という要件を想定して、その設定を行います。
「okta.groups.read」と「okta.users.read」横にある「✔付与」をクリックして、以下のように「取り消す」の状態にしてください。
リソースオーナー ([email protected]) が、グループ情報や自分以外のユーザー情報をAPIで取得するには、「管理者ロール」で権限を割り当てる必要があります。
「ディレクトリ」→「ユーザー」で表示された画面で「[email protected]」をクリックします。
「管理者ロール」タブ→「個人の管理者権限を追加」をクリックします。
ここでは暫定的に、全ての管理者操作が実行できる「スーパー管理者」を「[email protected]」に割り当てます。
(理由: 後の動作確認の際に、権限の影響で情報が取得できないとAPIが正しく動作しているのかが分かりずらいため、ここでは一時的に、広範囲の情報が取得できるような権限にしておきます。)
Postmanの設定
では、Postmanの設定に移りましょう。
ここでは、前回のブログ記事で行ったPostmanの設定は実施済みの前提で進めます。
Postmanの画面の右上にある四角いアイコンをクリックして表示される値を編集しておきます。
前回の設定で使った「apikey」は不要なので、空の状態にしてください。
前回同様、「url」にはOkta WIC Orgのドメインを、「userId」には登録済みのユーザーを一つ入れて、「Save」してください。(APIリクエスト発行時に、ここに設定した値が使われます。)
本ブログ記事のOkta WIC環境では「[email protected]」が登録済みですので、「userId」には、そのユーザーを指定しています。
「Collections」→「Groups (Okta API)」を選択して表示された右画面の「Authorization」タブをクリックします。
「Auth Type」で「OAuth 2.0」を選択します。
「Configure New Token」までスクロールダウンして、下記の画像内の解説の通り設定します。
設定ができたら、一番下にある「Get New Access Token」をクリックします。
Okta WICの認証画面が表示されますので、リソースオーナー ([email protected]) で認証を行います。
このユーザーが利用できる認証方式を選択してください。
認証が完了すると、下記画面に遷移します。カウントダウンを待つか、「Proceed」をクリックします。
「アクセストークン」が取得できました。
「Use Token」をクリックします。
「Current Token」の下の「Token」に、今取得した「アクセストークン」が設定されます。
PostmanからAPIリクエストを発行
アクセストークンが取得できたので、PostmanからAPIリクエストを発行してみましょう。
例として、Okta WICに設定されているグループの一覧を取得してみたいと思います。
先ほどアクセストークンの取得を行った「Groups (Okta API) 」の下の「List Groups」を選択して表示された右側画面で「Authorization」タブをクリックします。
Auth Typeで「Inherit auth from parent」を選択してください。
「Headers」タブでは、念の為、Authorizationヘッダを外しておいてください。
右上の「Send」をクリックすることでAPIリクエストが発行され、Okta WICに設定されているグループ情報の一覧が取得できると思います。
少なくとも、デフォルトで設定されている「Everyone」グループは取得できるはずです。
次に「Users (Okta API)」も操作してみましょう。
「Users (Okta API) 」を選択して表示された右側画面の「Authorization」タブをクリックします。
「Current Token」の下の「Token」で、取得済みのアクセストークン (本ブログ記事では「Okta_API」) を選択します。
「Users (Okta API) 」の下の「Get User」で表示された右側画面の「Headers」タブで、念の為、「Authorization」ヘッダを外しておいてください。
「Authorization」タブをクリックします。
Auth Typeで「Inherit auth from parent」を選択してください。
「Send」をクリックすることで、事前にPostmanの「userId」に設定しておいたユーザー ([email protected]) の情報が得られるはずです。
API操作権限の絞り込み
Okta WICのOAuth 2.0 API用のアプリケーション＝「Okta User-based API」の設定で、スコープを「okta.users.read」と 「okta.groups.read」に限定しているので、APIクライアントは、グループ情報とユーザー情報の参照しかできません。
よって、スコープ設定だけでも、ある程度の絞り込みはできています。
とはいうものの、リソースオーナー ([email protected]) の管理者ロールに「スーパー管理者」を割り当てたので、全てのグループとユーザーの情報 ＝ このリソースオーナーとは直接関係ない範囲の情報まで全て取得できてしまう状態にあります。
「それでよい。そうしたい。」という場合もあると思いますが、一方でこのリソースオーナーには、「okta.users.read」と 「okta.groups.read」で参照できる範囲の中でも、さらに限定した情報だけ取得できるように制限したい、という場合もあると思います。
その後者のご要件は、リソースオーナーの「管理者ロール」で権限を絞り込むことで実現できます。
例として、前回のブログ記事と同様に、このリソースオーナー ([email protected]) は「ユーザー情報が参照できるだけ」というような権限に設定してみようと思います。
「ディレクトリ」→「ユーザー」で表示された画面で「[email protected]」をクリックします。
「管理者ロール」タブ→「個人の割り当てを編集」をクリックします。
前回のブログ記事で設定したロール＝「view_users」と、リソースセット＝「users_resource」を適用して、「スーパー管理者」ロールを削除し、「変更を保存」をクリックします。
Postmanの操作画面に戻って、再び「Groups (Okta API)」の下の「List Groups」を選択して、右上の「Send」をクリックしてみてください。
リソースオーナー ([email protected]) には、グループを参照する権限を付与していないので、このAPI操作では情報を得ることができないはずです。
次に再び「Users (Okta API)」の下の「Get User」を選択して、右上の「Send」をクリックしてみてください。
このAPI操作はユーザー情報の参照なので、権限が付与されてますから、以前に確認した内容と同じ結果が得られるはずです。
認可コードグラント＋PKCE について
認可コードグラントには、認可コードを横取りする攻撃を防御する目的で、PKCE (Proof Key for Code Exchange) という機能が追加できるようになっています。
PKCEは「ピクシー」と読みます。
既述の「認可コードグラント (＝PKCEなし)」の場合、もし、端末内に悪意あるアプリが仕込まれていると、認可コードをそのアプリに横取りされてしまう危険があります。
認可コード横取り攻撃が成立する流れ ＝ PKCEがない場合
まず、PKCEが設定されていなかったらどうなってしまうのかを解説します。
認可コード横取り攻撃は、スマートフォンのネイティブアプリで発生しやすいので、この攻撃がイメージしやすいように、解説にはPostmanとOkta WICを以下に置き換えます。
・(Postmanの代わりに) スマートフォンの、写真を保存できるアプリ (以降、写真アプリ)
・(Okta WICの代わりに) 写真の保存先であり、認可サーバも兼ねたサイト (storager.xyz)
写真アプリは、カスタムURLスキームに「photoapp://」を使っています。
カスタムURLスキームは、ブラウザなどの他のアプリからこの写真アプリを起動したいとき向けに、URLの先頭部分に指定されている値です。
厄介なのが、このカスタムURLスキームはアプリ毎にユニークにすることが必須になっておらず、他のアプリで同じものを使っても良いことになっている点です。
それを悪用して、悪いアプリは写真アプリと同じ「photoapp://」を使うことで、上図(5)の認可レスポンスを受けたブラウザが悪いアプリを起動してしまう、ということがあり得るのです。
その結果、悪いアプリが認可コードを横取りできてしまいます。
この攻撃を防ぐ機能が、PKCEです。
OAuth 2.0 認可コードグラント＋PKCEの流れ
以下の図で、PKCEの流れを説明します。
(a) クライアント (写真アプリ) は、「code_verifier = YYYY」というランダムな文字列を生成して、「SHA256」でハッシュします。それが「code_challenge=XXXX」です。
(b) クライアント (写真アプリ) は、認可エンドポイントに『「code_challenge = XXXX」は、SHA-256でハッシュされた値ですよ』と伝えるために、(1)の認可リクエストで「code_challenge = XXXX」と共に「code_challenge_method = S256」も送ります。
(c) それを受け取った認可エンドポイントは、それらを一旦そのまま保存しておきます。
(d) クライアント (写真アプリ) は、(6)のトークンリクエストを送る際に、「code_verifier = YYYY」を加えてトークンエンドポイントに送ります。
(e) トークンエンドポイントでは、上記(d)で受け取った「code_verifier = YYYY」をSHA256でハッシュ計算した結果が、(c)で保存しておいた「code_challenge = XXXX」と一致するかどうかを検証し、一致すれば問題なしと判断して、(7)以降の処理を行います。
この振る舞いによって、下図のように、認可コードを横取りする攻撃を防御します。
(d) 悪いアプリは、写真アプリのcode_verifierの値を知らないので、code_verifierは付けないで送るか、適当な値で送るかしかありません。
ここでは、悪いアプリは「code_verifier = WARUI」として送ったものとします。
(e) トークンエンドポイントは、悪いアプリが生成した (d) の「code_verifier = WARUI」をSHA256でハッシュ計算した結果と、認可エンドポイントが (c) で受け取った「code_challenge = XXXX」とが一致しないので、(8) でエラーを返します。(＝アクセストークンを発行しません。)
OAuth 2.0 認可コードグラント＋PKCEの設定
それでは、上記の流れを実現する設定を行いましょう。
Okta WICのAPI用アプリケーションの設定
Okta WICでPKCEを有効にする設定は、とてもシンプルです。
「アプリケーション」→「アプリケーション」で表示されたOAuth2.0 API用のアプリ (本ブログ記事では「Okta User-based API」) を選択します。
「一般」タブの「クライアントの資格情報」で「編集」をクリックして、「追加の検証としてPKCEを要求」を有効にします。これだけです。
Postmanの設定
PostmanでPKCEを有効にする設定も、とてもシンプルです。
「Collections」→「Groups (Okta API)」を選択して表示された右画面の「Authorization」タブをクリックします。
「Configure New Token」までスクロールダウンして、Grant typeで「Authorization Code (With PKCE)」を選択してください。
「Code Challenge Method」と「Code Verifier」が追加で表示されますが、これらはデフォルトのままでOKです。
既述の「認可コードグラントの設定」の章で設定した値も、そのままでOKです。
設定ができたら、一番下にある「Get New Access Token」をクリックします。
「認可コードグラント」の場合と同様に、アクセストークンが取得できると思います。
以降、表面上の動作は「認可コードグラント＋PKCE」の場合も「認可コードグラント」の場合と差はありませんが、念のため、「認可コードグラント」と同様の動作確認を実施してみてください。
[参考]:
Test the Okta REST APIs with Postman
まとめ
本ブログ記事では、OAuth 2.0の認可コードグラントを使った場合のOkta WIC APIの使い方についてご紹介しました。
認可コードグラントは、例えば、何らかのWebアプリケーションを作成された場合に、そのアプリの利用者に、Okta WICに登録された利用者の情報を提供したり、利用者の設定 (例えば住所や電話番号等) を自ら変更してもらったり、というようなときにご利用いただけるかと思います。
また、本ブログ記事の通り、Okta WICトライアル環境とフリーで利用できるPostmanがあれば、一般的に広く利用されている認可コードグラントの動きを体感できるので、OAuth 2.0の理解を深めるための教材的な位置付けとしても一役買ってくれると思います。
OAuth 2.0で、人の介入を不要とする＝サーバから直接Okta WICのAPIを操作する「Client Credentialsグラント」方式については、別記事でご紹介しようと思います。
==========
Okta WICでは、認証の強化だけに留まらず、管理者が行うユーザーの登録/変更/削除に関わる業務の自動化や、人事管理システムや既設ディレクトリなどとの柔軟な連携も可能です。
Oktaでは、これらの機能を体感頂くことができる「Okta Essentials」トレーニングをご用意しています。(日本語でのトレーニングもご用意しています。)
このトレーニングは全体像を体系的にご理解頂ける内容となっていますので、是非ともご活用ください。
Follow 岸本 卓也
