Org Authorization Serverを使用してアクセストークンをリクエストする場合、そのアクセストークンのJWTに対する検証プロセスは失敗します。
トークンの発行者（クレームに格納）がベースドメインURL（例：https://example.okta.com、https://okta.mycompany.com）の場合は、Org Authorization Serverが使用されています。
- OAuth 2.0
- OpenID Connect
- Org Authorization Server
- Okta Classic Engine
Org Authorization Serverのアクセストークンは、Oktaのみが使用するように設計されています。アクセストークンは変更される可能性があり、ローカルでデコードや検証を行うと問題が発生する恐れがあります（たとえば、Oktaが外部公開された署名鍵の使用を開始した際にtypヘッダーが変更されました）。詳しくは2024年3月のリリースをご覧ください。これらのアクセストークンはOktaのエンドポイントで使用されることが想定されており、それ以外では使用すべきではありません。
Okta自体がこれらのトークンの対象オーディエンスであるため、これらのアクセストークンのaudパラメーターはOkta org（例：https://example.okta.com）です。Okta Org Authorization Serverによって発行されたアクセストークンは、認可のユースケースにおいては、オーディエンスをリソースサーバーに送信することが求められ、かつカスタムスコープ/適切なアクセスポリシーが必要となることから、安全に使用することができません。
Org Authorization Serverによって発行されたアクセストークンは、認証のユースケース（Open ID Connect）にのみ使用し、認可のユースケース（OAuth）には使用すべきではありません。認可（OAuth）のユースケースが必要な場合は、代わりにローカルでのトークンの検証がサポートされているCustom Authorization Server（API Access Management機能に関連付けられたもの）を使用する必要があります。
Org Authorization Serverからアクセストークンを受け取った統合は、それらを不透明として扱う必要があります。Org Authorization Serverによって発行されたアクセストークンを、サードパーティのデコーダーを使用してデコードすることは技術的に可能ですが、Org Authorization Serverのドキュメントに記載されているように、これらのトークンの内容はいつでも予告なしに変更される可能性があります。トークンを検証する必要がある場合は、イントロスペクションエンドポイントを使用して検証してください。イントロスペクションエンドポイントには、Org Authorization Serverによって発行されたアクセストークンに対する最新の変更が反映されているため、正常にデコードし、安全に検証できます。
Oktaは対象オーディエンスであるため、Org Authorization Serverによって発行されたアクセストークンはOktaのAPI（特にUserinfo Endpoint、Introspect Endpoint、Management Endpoint）を認可できます。
