Autonomous AI Databaseのデータベース・ツールが、外部アイデンティティ・プロバイダーによるユーザー認証に対応しました。 Oracle IAMを外部アイデンティティ・プロバイダーとした設定手順を、記事「
Autonomous AI Databaseのデータベース・ツールを外部認証する - Oracle IAM編」にて紹介しています。
本記事では、Microsoft Entra IDを外部アイデンティティ・プロバイダーとした設定手順を紹介します。
Using Oracle Autonomous AI Database Serverless
Use External Authentication with Database ToolsDBMS_CLOUD_FUNCTION_ADMIN Package
Microsoft Entra IDでのアプリケーション作成手順などは、以前に公開している以下の記事とほぼ同じです。ただし、データベース・ツールおよびAPEXに限れば、アクセス・トークンのバージョンをv2にする必要はありません。また、カスタム要求upnの追加およびスコープの設定がなくても、ユーザー認証はできました。
記事:
SQLclのMCPサーバーのデータベース接続をMicrosoft Entra IDのOAuth2で認証する
Autonomous AI Databaseの作成
Always FreeのAutonomous AI Databaseを作成します。
データベース名はSALESADB、ワークロード・タイプはレイクハウス、データベースのバージョンは19cです。
手元の作業ディレクトリは、salesadb_oracleiamの代わりにsalesadb_entraidとします。
作業ディレクトリを環境変数TNS_ADMINに設定し、SQLclでAutonomous AI Databaseに接続できる環境を作ります。
salesadb-entraid % sql admin@salesadb_low
SQLcl: 火 7月 14 11:52:46 2026のリリース26.1 Production
Copyright (c) 1982, 2026, Oracle. All rights reserved.
パスワード (**********?) ****************
Last Successful login time: 火 7月 14 2026 11:52:52 +09:00
接続先:
Oracle Database 19c Enterprise Edition Release 19.0.0.0.0 - Production
Version 19.32.0.1.0
SQL> exit
Oracle Database 19c Enterprise Edition Release 19.0.0.0.0 - Production
Version 19.32.0.1.0から切断されました
salesadb-entraid %
作成したAutonomous AI Databaseのパブリック・アクセスURLのホスト部は、Entra IDにアプリケーションを登録する際に使用するリダイレクトURIのホスト部になります。
リダイレクトURIは以下の形式です。
https://[パブリック・アクセスURLのホスト部]/adb/auth/v1/connect/azure_ad/callback
Microsoft Entra IDの構成
Azureのコンソールから
Microsoft Entra IDのページを開きます。
アプリケーションの
名前は
SALESADBとします。
サポートされているアカウントの種類に、
シングルテナントのみ - 規定のディレクトリを選択します。
リダイレクトURIとして
Webを選択し、先ほど説明した
リダイレクトURIを設定します。
https://[パブリック・アクセスURLのホスト部]/adb/auth/v1/connect/azure_ad/callback
アプリケーション
SALESADBが作成されます。
APIの公開を開きます。
アプリケーションIDのURIを追加します。
追加のリンクをクリックします。
アプリケーションIDのURIとして、デフォルト値の
api://アプリケーションIDが表示されます。
デフォルトから変更せず、そのまま保存をクリックします。
続けて
Scopeの追加を実施します。
SQLclで使用できるアクセス・トークンを発行するには、スコープの指定が必要です。データベース・ツールおよびAPEXへの接続では、必ずしも必要ではありません。
スコープ名は
session:scope:connectとしています。スコープ名は自由に設定できます。
同意できるのはだれですか?として
管理者とユーザーを選択します。
管理者の同意の表示名、
管理者の同意の説明に、
Connect to SALESADBを入力します。
状態を
有効にして、
スコープの追加をクリックします。
以上で、
アプリの公開に
アプリケーションID URLと
スコープが登録できました。
アプリロールを開き、
アプリロールの作成をクリックします。
この作業で作成する
アプリロールを、Oracle Databaseのデータベース・ユーザーに
AZURE_ROLEとして割り当てることにより、Entra IDでユーザー認証ができるようになります。(この他にAZURE_USERをデータベース・ユーザーに割り当てる方法もあります)。
表示名は
Role for Database Toolsとします。
許可されたメンバーの種類は
両方(ユーザー/グループ+アプリケーション)を選択します。
値に
DBTOOLS_ROLEを設定します。Oracle Databaseが
AZURE_ROLEとして認識するのは、この
DBTOOLS_ROLEです。
説明は
Role for Database Tools、
このアプリロールを有効にしますか?に
チェックを入れます。
以上で
適用をクリックします。
アプリロールDBTOOLS_ROLEが作成されます。
アプリケーション
SALESADBにEntra IDのユーザーを割り当てます。割り当てるユーザーに、作成したアプリロール
DBTOOLS_ROLEを割り当てます。
ユーザーの割り当ては、
エンタープライズアプリケーションに移動して実施します。
概要の
ローカルディレクトリでのマネージドアプリケーションにある、
SALESADBのリンクをクリックします。
ユーザーとグループの割り当てを開きます。
ユーザーまたはグループの追加をクリックします。
ユーザーの選択されていませんをクリックし、割り当てるユーザーを選択します。
割り当てるユーザーを選択し、
選択をクリックします。
ロールはRole for Database Tools(値はDBTOOLS_ROLE)が選択されています。
割り当てをクリックします。
エンタープライズアプリケーション
SALESADBに、アプリロール
DBTOOLS_ROLEを持つユーザーが割り当てられました。
ここで割り当てられたユーザーで、データベース接続のユーザー認証が行われます。
エンタープライズアプリケーションの画面からアプリケーション
SALESADBに戻り、
管理の
APIのアクセス許可を開きます。
アクセス許可の追加をクリックします。
所属する組織で使用しているAPIを開き、
SALESADBを探して
選択します。
アプリケーションの許可を選択します。
選択できるアクセス許可としてアプリロール
DBTOOLS_ROLEが表示されます。この
DBTOOLS_ROLEをチェックして、
アクセス許可の追加をクリックします。
アクセス許可の追加を再度クリックし、先ほどと同様に
所属する組織で使用しているAPIを開き、
SALESADBを選択します。
今度は
委任されたアクセス許可を選択します。アクセス許可として表示された
session:scope:connectをチェックして、
アクセス許可の追加を実行します。
以上でアクセス許可の設定ができました。
Entra IDのアクセストークンを
v2に変更します。
マニュフェストを開きます。
"api"の下に属性
"requestedAccessTokenVersion"があります。この値を
2に変更します。
"requestedAccessTokenVersion": 2,
変更後、保存します。
SQLclでのデータベース接続では、ユーザーの識別子となるクレーム(要求)として
upnを使用します。
トークン構成を開き、
オプションの要求の追加をクリックします。
トークンの種類に
アクセスを選択し、
要求に含まれる
upnを
チェックします。これはOAuth2.0のアクセストークンにクレーム(要求)としてupnを追加する、という作業です。
以上で
追加をクリックします。
Microsoft Graph profileのアクセス許可を有効にしますをチェックして、追加します。
属性upnに設定される値を調整します。要求upnの3点メニューをクリックし、編集を実行します。
UPNの編集画面で、外部認証済みをはい、ハッシュ記号の置換をはいに設定します。
必ずしも必要ではないようですが、念の為同様の操作を行い、
IDトークンについてもクレームとして
upnを
追加します。
外部認証済みや
ハッシュ記号の置換も同様に編集します。
クライアントシークレットを作成します。
証明書とシークレットを開き、新しいクライアントシークレットをクリックします。
説明にsecret、有効期限に推奨:180日(6ヶ月)を選択し、追加をクリックします。
シークレットが作成されました。
以上でMicrosoft Entra IDでの作業は完了です。
Microsoft Entra IDによる外部認証を有効にします。
アプリケーションSALESADBの概要を開き、外部認証を有効にするにあたって必要な値を取得します。
SALESADBに管理者ユーザーADMINで接続します。接続にはSQLclを使用します。
salesadb-entraid % sql admin@salesadb_low
SQLcl: 火 7月 14 14:17:59 2026のリリース26.1 Production
Copyright (c) 1982, 2026, Oracle. All rights reserved.
パスワード (**********?) ****************
Last Successful login time: 火 7月 14 2026 14:18:07 +09:00
接続先:
Oracle Database 19c Enterprise Edition Release 19.0.0.0.0 - Production
Version 19.32.0.1.0
SQL>
Microsoft Entra IDによる外部認証を有効にします。それぞれの引数の値は、Entra IDの画面から取得した値に置き換えます。
BEGIN
DBMS_CLOUD_ADMIN.ENABLE_EXTERNAL_AUTHENTICATION(
type => 'AZURE_AD',
params => JSON_OBJECT(
'tenant_id' VALUE 'tenant-id',
'application_id' VALUE 'application-id',
'application_id_uri' VALUE 'application-id-uri'),
force => TRUE
);
END;
/
SQL> BEGIN
2 DBMS_CLOUD_ADMIN.ENABLE_EXTERNAL_AUTHENTICATION(
3 type => 'AZURE_AD',
4 params => JSON_OBJECT(
5 'tenant_id' VALUE '3940511e-****-****-****-********2758',
6 'application_id' VALUE '7a368d40-****-****-****-********32b8',
7 'application_id_uri' VALUE 'api://7a368d40-****-****-****-********32b8'),
8 force => TRUE
9 );
10 END;
11* /
PL/SQLプロシージャが正常に完了しました。
SQL>
設定を確認します。
SELECT NAME, VALUE FROM V$PARAMETER WHERE NAME='identity_provider_type';
SQL> SELECT NAME, VALUE FROM V$PARAMETER WHERE NAME='identity_provider_type';
NAME VALUE
_________________________ ___________
identity_provider_type AZURE_AD
SQL>
Microsoft Entra IDを外部アイデンティティ・プロバイダーとして使用する場合、IdMとしてデータベースに登録する必要があります。DBMS_CLOUD_FUNCTION_ADMIN.CREATE_IDPを呼び出します。
Entra IDの画面より、引数に与える値を取り出します。
アプリケーションSALESADBの概要のページにあるアプリケーション(クライアント)IDが、client-idになります。
エンドポイントを開くと、
OpenID Connect メタデータドキュメントがあります。これが
discovery_uriの値になります。
証明書とシークレットより、シークレットの値をコピーします。これがclient-secretの値になります。
BEGIN
DBMS_CLOUD_FUNCTION_ADMIN.CREATE_IDP(
idp_name => 'AZURE_AD',
client_id => '<client-id>',
client_secret => '<client-secret>',
params => JSON_OBJECT(
'discovery_url' VALUE
'https://login.microsoftonline.com/<tenant-id>/v2.0/.well-known/openid-configuration'));
END;
/
SQL> BEGIN
2 DBMS_CLOUD_FUNCTION_ADMIN.CREATE_IDP(
3 idp_name => 'AZURE_AD',
4 client_id => '7a368d40-****-****-****-********32b8',
5 client_secret => 'dX*****************************************gdhZ',
6 params => JSON_OBJECT(
7 'discovery_url' VALUE
8 'https://login.microsoftonline.com/3940511e-****-****-****-********2758/v2.0/.well-known/openid-configuration'));
9 END;
10* /
PL/SQLプロシージャが正常に完了しました。
SQL>
設定を確認します。
select * from dba_list_idp;SQL> select * from dba_list_idp;
IDP_ID IDP_NAME CLIENT_ID PARAMS
_____________________________________________________________________________________ ___________ _______________________________________ ___________________________________________________________________________________
AZURE_AD-630b****-****-****-****-********1ba2-****093c-****-****-****-********3c14 AZURE_AD 7a368d40-****-****-****-********32b8 {"discovery_url":"https://login.microsoftonline.com/3940511e-****-****-****-***
SQL>
DBMS_CLOUD_FUNCTION_ADMIN.CREATE_IDPを呼び出す際に、引数の値が間違っていると以下のエラーが発生しました。値の間違い(discovery_uriに与えたURLが存在しないなど)と思えないエラーなので注意が必要です。
行でエラーが発生しました 1:
ORA-20001: Create IDP failed while invoking broker. ORA-20001: Broker invocation failed for method POST, endpoint databases/<database_ocid>/ext_auths, request_type idp. ORA-20400:
ORA-06512: "C##CLOUD$SERVICE.DBMS_CLOUD_FUNCTION_ADMIN", 行1399
ORA-20001: Broker invocation failed for method POST, endpoint databases/<database_ocid>/ext_auths, request_type idp. ORA-20400:
ORA-06512: "C##CLOUD$SERVICE.DBMS_CLOUD_FUNCTION_INT", 行5810
また、ビューDBA_LIST_IDPを検索する際、IDPが一件も登録されていないと以下のエラーが発生しました。未登録だから発生しているエラーには見えないので、こちらも注意が必要です。
コマンド行 : 1 列 : 26 でのエラー
エラー・レポート -
SQLエラー: ORA-20001: Broker invocation failed for method GET, endpoint databases/<database_ocid>/ext_auths,
request_type idp. ORA-20404:
ORA-06512: "C##CLOUD$SERVICE.DBMS_CLOUD_FUNCTION_INT", 行5864
ORA-06512: "C##CLOUD$SERVICE.DBMS_CLOUD_FUNCTION_INT", 行5810
以上で、外部アイデンティティ・プロバイダーとしてMicrosoft Entra IDが登録されました。
データベース・ユーザーとして
WKSP_APEXDEVを作成します。このユーザーは、Oracle APEXのワークスペース
APEXDEVのデフォルト・パーシング・スキーマとして使用します。
データベース・ユーザー
WKSP_APEXDEVには、Entra IDのアプリロール
DBTOOLS_ROLEを割り当てます。WKSP_APEXDEVには最低限の権限のみを割り当ています。
create user wksp_apexdev identified globally as 'AZURE_ROLE=DBTOOLS_ROLE';
alter user wksp_apexdev quota 25m on data;
grant create session to wksp_apexdev;
grant create table, create view, create sequence to wksp_apexdev;
SQL> create user wksp_apexdev identified globally as 'AZURE_ROLE=DBTOOLS_ROLE';
User WKSP_APEXDEVは作成されました。
SQL> alter user wksp_apexdev quota 25m on data;
User WKSP_APEXDEVが変更されました。
SQL> grant create session to wksp_apexdev;
Grantが正常に実行されました。
SQL> grant create table, create view, create sequence to wksp_apexdev;
Grantが正常に実行されました。
SQL>
スキーマ
WKSP_APEXDEVを
REST有効にします。
ORDS別名に
apexdev(これがAPEXワークスペース名として扱われます)を割り当てます。
BEGIN
ORDS_ADMIN.ENABLE_SCHEMA(
p_enabled => TRUE,
p_schema => 'WKSP_APEXDEV',
p_url_mapping_type => 'BASE_PATH',
p_url_mapping_pattern => 'apexdev',
p_auto_rest_auth => FALSE);
END;
/
SQL> BEGIN
2 ORDS_ADMIN.ENABLE_SCHEMA(
3 p_enabled => TRUE,
4 p_schema => 'WKSP_APEXDEV',
5 p_url_mapping_type => 'BASE_PATH',
6 p_url_mapping_pattern => 'apexdev',
7 p_auto_rest_auth => FALSE);
8 END;
9* /
PL/SQLプロシージャが正常に完了しました。
SQL> exit
Oracle Database 19c Enterprise Edition Release 19.0.0.0.0 - Production
Version 19.32.0.1.0から切断されました
salesadb-entraid %
以上で、データベース・ツールの認証にMicrosoft Entra IDを使用できるようになりました。
Autonomous AI Databaseに接続し、使用するツールとしてSQL Developer Webを選択します。
外部アイデンティティ・プロバイダーとしてAzureを選択します。
Microsoft Entra IDへのサインイン画面が開きます。
Entra IDへサインインします。サインイン手順については省略します。
サインインするとアクセス許可を要求されます。承諾します。
HTTPのステータス・コードとして404 Not Foundが返されました。
今回は、APEXに合わせて、
スキーマ名を
WKSP_APEXDEV、
ORDS別名(APEXワークスペース名)を
apexdevにしています。スキーマのREST有効化のために、ORDS_ADMIN.ENABLE_SCHEMAを以下の引数で呼び出しています。
BEGIN
ORDS_ADMIN.ENABLE_SCHEMA(
p_enabled => TRUE,
p_schema => 'WKSP_APEXDEV',
p_url_mapping_type => 'BASE_PATH',
p_url_mapping_pattern => 'apexdev',
p_auto_rest_auth => FALSE);
END;
/
URLを確認すると/ords/wksp_apexdev/_sdw/となっています。つまり、
データベース・ツールのSSO認証でのリダイレクト先としてスキーマ名が使われ、ORDS別名(p_url_mapping_patternの値)が使われていないことが問題のようです。ブラウザに表示されているURLの
/ords/wksp_apexdev/_sdw/の部分を
/ords/apexdev/_sdw/に変更して、URLにアクセスします。
スキーマ
WKSP_APEXDEVを接続先として、データベース・アクションの画面が開きます。
Microsoft Entra IDで認証したユーザーにて、データベース・ツールに接続できました。
データベース・アクションより以下のSELECT文を実行し、どのようにユーザーが認証されているか確認してみます。
select
sys_context('userenv','authentication_method') authenticated_method,
sys_context('userenv','authenticated_identity') authenticated_identity,
sys_context('userenv','session_user') session_user,
sys_context('userenv','current_user') current_user
from dual
AUTHENTICATED_METHODはNONE、AUTHENTICATED_IDENTITY、SESSION_USER、CURRENT_USERすべてが、接続スキーマであるWKSP_APEXDEVを返しています。
データベース・ツールの外部アイデンティティ・プロバイダーによる認証は、データベース・ツールの認証であって、データベース接続の認証には使用されていないようです。
Oracle APEXへの接続
「
There are no workspaces associated with your account.」と報告されますが、
Microsoft Entra IDで認証されたユーザーは認識されています。
ユーザーを識別する値として、アクセス・トークンのクレーム
unique_nameの値が使用されています。SQLclによるデータベースへの接続では、クレーム
upnの値がユーザーを識別する値となっている点に注意が必要です。
APEXのワークスペースとしてAPEXDEVを作成し、Oracle IAMのユーザーに作成したAPEXのワークスペースを割り当てます。
上記の画面から
サインアウトし、管理者ユーザー
ADMINでサインインし直します。
管理サービスにサインインし、ワークスペースの作成を実行します。
ORDS_ADMIN.ENABLE_SCHEMAに与えた引数の値に合わせて、
データベース・ユーザーは
WKSP_APEXDEV、
ワークスペース名は
apexdevとします。
ワークスペース・ユーザー名は
apexdev、
ワークスペース・パスワードにパスワードを設定します。このユーザーはワークスペースの管理者になります。必ずしもワークスペース名に一致している必要はありませんが、この名前でデータベース・ユーザーが作成されます。
以上で
ワークスペースを作成します。
ワークスペースが作成されます。
インスタンスに設定されている
開発環境認証スキームを確認します。
インスタンス管理を開きます。
インスタンス管理のセキュリティを開きます。
認証制御の開発環境認証スキームを確認すると、Autonomous AI Database Single Sign-Onがカレント・スキームであることが確認できます。
Autonomous AI Database Single Sign-Onの説明に「
This scheme authenticates developers using the integrated identity provider in Oracle Autonomous AI Database.」と記述されています。Autonomous AI Databaseに構成しているアイデンティティ・プロバイダーで認証する、と説明されています。
ワークスペースの管理から
開発者とユーザーの管理を開き、Microsoft Entra IDのユーザーに、APEXのワークスペース
APEXDEVを割り当てます。
ユーザーの作成をクリックします。
APEXの管理者ユーザーや開発者ユーザーの外部認証は、あくまで認証に外部のアイデンティティ・プロバイダーを使うだけです。管理者や開発者であるユーザーは、それぞれのワークスペースに作成する必要があります。
ユーザー名に
Microsoft Entra IDで認証されるユーザー名を設定します。大文字小文字は区別しないため、英大文字で設定します。
電子メール・アドレスは必須項目なので入力します。
ワークスペースを割り当てます。今回の作業では
APEXDEVを割り当てています。管理者か開発者かの権限を選択します。
パスワードの設定は必須です。管理ツールや開発ツールの認証は外部アイデンティティ・プロバイダーによって行われるため、ここで設定しているパスワードは使用されません。認証スキーム
Oracle APEXアカウントによる認証の際に使用されます。
以上で
ユーザーを作成します。
注)APEXの管理者ユーザーまたは開発者ユーザーを作成すると、同名のデータベース・ユーザーが作成されていました。ユーザー認証は、外部アイデンティティ・プロバイダーによって行われています。CREATE SESSION権限が割り当たっていないため、そのユーザーでデータベースに接続できません。より安全性を求める場合、NO AUTHENTICATION(パスワード無し)に変更できます。データベース・ユーザーからパスワードを除いても、APEXへのサインインは可能です。
ワークスペースAPEXDEVに管理者ユーザーが追加されました。
再度、APEXへのサインインを試みます。
今度はサインインしたユーザーに、APEXのワークスペース
APEXDEVが割り当たっています。
サインインするワークスペースとして
APEXDEVを選択します。
APEXのワークスペースに接続できました。
以上で、外部アイデンティ・プロバイダーで認証したユーザーで、Oracle APEXの開発ツールに接続できました。
SQLclでの接続
Microsoft Entra IDで発行してもらったアクセス・トークンを使って、データベースに接続します。作業はMacBook Pro、macOS Tahoe 25.6.1で実施します。
Homebrewを使ってazure-cliをインストールします。
brew install azure-cli
私の環境にはazure-cli 2.88.0がインストールされていました。
salesadb-entraid % brew install azure-cli
Warning: azure-cli 2.88.0 is already installed and up-to-date.
To reinstall 2.88.0, run:
brew reinstall azure-cli
salesadb-entraid %
Microsoft Entra IDの画面から、データベースへの接続に必要な値を取り出します。
アプリケーションSALESADBの概要から、ディレクトリ(テナント)IDを取得します。
APIの公開から、
スコープの値を取得します。
Entra IDにログインします。az loginコマンドを実行します。
az login --tenant "テナントID" --scope "api://アプリケーションIDのURI/session:scope:connect"
salesadb-entraid % az login --tenant "3940511e-****-****-****-*********2758" --scope "api://7a368d40-****-****-****-********32b8/session:scope:connect"
A web browser has been opened at https://login.microsoftonline.com/3940511e-****-****-****-********2758/oauth2/v2.0/authorize. Please continue the login in the web browser. If no web browser is available or if the web browser fails to open, use device code flow with `az login --use-device-code`.
ブラウザが開き、Entra IDへのサインインを求められます。
アクセス許可を要求されます。次へ進みます。
同様の確認を求められるので、(内容を理解したうえで)承諾します。
サインインが完了します。
az loginを実行している画面でAzureのサブスクリプションの選択を求められます。サブスクリプションが1つだけだったので、Enterを入力しました。
Select a subscription and tenant (Type a number or Enter for no changes):
salesadb-entraid % az login --tenant "3940****-****-****-****-********2758" --scope "api://7a368d40-****-****-****-********32b8/session:scope:connect"
A web browser has been opened at https://login.microsoftonline.com/3940511e-****-****-****-********2758/oauth2/v2.0/authorize. Please continue the login in the web browser. If no web browser is available or if the web browser fails to open, use device code flow with `az login --use-device-code`.
Retrieving subscriptions for the selection...
[Tenant and subscription selection]
No Subscription name Subscription ID Tenant
----- -------------------- ------------------------------------ ------------------------------------
[1] * Azure subscription 1 7ada****-****-****-****-********7b71 3940****-****-****-****-********2758
The default is marked with an *; the default tenant is '3940****-****-****-****-********2758' and subscription is 'Azure subscription 1' (7ada****-****-****-****-*******7b71).
Select a subscription and tenant (Type a number or Enter for no changes):
Tenant: 394****-****-****-****-*******2758
Subscription: Azure subscription 1 (7adac****-****-****-****-*******7b71)
[Announcements]
With the new Azure CLI login experience, you can select the subscription you want to use more easily. Learn more about it and its configuration at https://go.microsoft.com/fwlink/?linkid=2271236
If you encounter any problem, please open an issue at https://aka.ms/azclibug
[Warning] The login output has been updated. Please be aware that it no longer displays the full list of available subscriptions by default.
salesadb-entraid %
以上で、Entra IDにサインインしてIDトークンが取得できました。
アクセストークンを取得します。
az account get-access-tokenを実行します。取得したトークンは、
tnsnames.oraに
TOKEN_LOCATIONとして指定している /Uses/[ユーザー名
]/Documents/salesadb-entraid/token.txt に出力します。
az account get-access-token --scope "api://アプリケーションID URL/session:scope:connect" --query accessToken -o tsv > ./token.txtsalesadb-entraid % az account get-access-token --scope "api://7a36****-****-****-****-*******32b8/session:scope:connect" --query accessToken -o tsv > ./token.txt
salesadb-entraid %
作業ディレクトリ以下のtoken.txtにアクセストークンが出力されています。https://jwt.ioに貼り付けて、内容を確認できます。
アクセストークンが取得できたので、データベースに接続します。
tnsnames.oraにトークンで認証するTNS名
salesadb_tokenを追加します。salesadb_lowに以下の設定を加えます。
TOKEN_LOCATIONはtoken.txtのフルパスでの指定です。
(TOKEN_AUTH=OAUTH)(TOKEN_LOCATION=/Users/[ユーザー名]/Documents/salesadb-entraid/token.txt)salesadb_token = (
description= (retry_count=20)(retry_delay=3)
(address=(protocol=tcps)(port=1522)(host=adb.ca-toronto-1.oraclecloud.com))
(connect_data=(service_name=**************_salesadb_low.adb.oraclecloud.com))
(security=(ssl_server_dn_match=yes)(TOKEN_AUTH=OCI_TOKEN)
(TOKEN_LOCATION=/Users/[ユーザー名]/Documents/salesadb-entraid/token.txt)
)
)
Autonomous AI DatabaseのSALESADBに、データベースのアクセス・トークンを使って接続します。
sql /@salesadb_token
salesadb-entraid % sql /@salesadb_token
SQLcl: 火 7月 14 16:46:38 2026のリリース26.1 Production
Copyright (c) 1982, 2026, Oracle. All rights reserved.
接続先:
Oracle Database 19c Enterprise Edition Release 19.0.0.0.0 - Production
Version 19.32.0.1.0
SQL>
データベースに接続できました。
以下のSELECT文を実行します。
select
sys_context('userenv','authentication_method') authenticated_method,
sys_context('userenv','authenticated_identity') authenticated_identity,
sys_context('userenv','session_user') session_user,
sys_context('userenv','current_user') current_user
from dual
SQL> select
2 sys_context('userenv','authentication_method') authenticated_method,
3 sys_context('userenv','authenticated_identity') authenticated_identity,
4 sys_context('userenv','session_user') session_user,
5 sys_context('userenv','current_user') current_user
6 from dual
7* /
AUTHENTICATED_METHOD AUTHENTICATED_IDENTITY SESSION_USER CURRENT_USER
_______________________ _____________________________________________________________ _______________ _______________
TOKEN_GLOBAL yuji.***********.com_EXT_@yu***************.onmicrosoft.com WKSP_APEXDEV WKSP_APEXDEV
SQL>
データベース・ツールから実行したときと異なり、
AUTHENTICATED_METHODは
TOKEN_GLOBAL、
AUTHENTICATED_IDENTITYは、アクセス・トークンのクレームupnの値が、一意のユーザー名として返されます。
今回の構成で使用したスキーマWKSP_APEXDEVですが、スキーマにパスワードを設定していません。データベース・ツール、Oracle APEXおよびSQclの全てで、Oracle IAMで認証したアイデンティティによってスキーマWKSP_APEXDEVに接続しています。パスワードを設定していない以上、スキーマWKSP_APEXDEVのパスワードが流出することはありません。
Microsoft Entra IDでのユーザー認証は、多要素認証などが適用されており、単純なユーザー名とパスワードだけで認証するということはありません。そのため、これまでのデータベース・ユーザーとパスワードによる認証と比べて、より安全になっています。
今回の記事は以上になります。
完