Okta Identity Engineリリースノート（プレビュー）

バージョン：2026.01.0

2026年1月

一般提供

デバイス保証のOSバージョンアップデート

デバイス保証ポリシーで、次のOSバージョンがサポートされるようになりました。

  • iOS 18.7.3、26.2
  • macOS 14.8.3、15.7.3、26.2

［ユーザープロファイルリスク］タブのUIの改善

視認性向上のために［ユーザープロファイルリスク］タブの表の列の並び順が変更され、コンテキスト変更イベントがポリシー違反イベントに置き換えられました。

［最近のアクティビティ］ページのヘルプドキュメントリンクを更新

End-User Settings 2.0の［最近のアクティビティ］ページにあるヘルプのドキュメントリンクが更新されました。

Admin Consoleのシームレスなナビゲーション

アプリスイッチャー、［管理者］ボタン、または直接URLからAdmin Consoleに移動するときに、アクティブなセッションが再利用されるようになりました。これにより、重複するMFAプロンプトが削減され、ナビゲーションエクスペリエンスが向上します。

ファーストパーティアプリスイッチャーの更新

以前は、Oktaファーストパーティアプリスイッチャーを使用するには、Okta管理者である必要がありました。今では、管理者以外のユーザーはアプリスイッチャーを使用して、ISPM、Workflows、パートナー管理者ポータルなどのOktaファーストパーティアプリ間をシームレスに移動できるようになりました。

OIDC以外のアプリケーションのログインヒントの評価

Admin Consoleの［セキュリティ］>［一般］ページが更新され、［OIDC以外のアプリケーションのログインヒントの評価］設定が追加されました。この設定は、アプリが提供するログインヒントをSign-In Widgetが評価するかどうかを制御します。「一般的なセキュリティ」を参照してください。

新しいIPサービスカテゴリーのサポート

PAWXY_VPN、QUARK_VPN、GIAMPING_VPN、ENCRYPT_SECURE_SERVERS_VPNが、機能強化された動的ゾーンのIPサービスカテゴリーとしてサポートされるようになりました。「サポートされるIPサービスカテゴリー」を参照してください。

カスタムFIDO2 AAGUID

お客様は、FIDOメタデータサービス（MDS）以外のセキュリティキーや他のAuthenticatorを追加して、それらをより詳細に制御できます。これにより、FIDO2（WebAuthn）Authenticatorのサポートが幅広いセキュリティキーや他のAuthenticatorに拡張され、お客様が環境内のセキュリティをより柔軟に制御できるようになります。

［サインインしたままにする］のテキストの説明

アプリサインインポリシー 構成ページのテキストが更新され、［サインインしたままにする］オプションがすべてのアプリで保持されることが明確になりました。「アプリ・サインイン・ポリシー・ルールを追加する」を参照してください。

アクセスリクエストメール通知の新しい外観と操作性

アクセスリクエストメール通知で、テキストの配置や使用される色、Oktaロゴの場所、グレー背景の追加など、外観と操作性が新しくなりました。

Windows TransportでのWS-Trust 1.3のサポート

Windows TransportがWS-Trust 1.3プロトコルをサポートするようになりました。これにより、新しいMicrosoft Officeクライアントのサイレントアクティベーションが可能になり、ユーザーが手動で資格情報を入力する必要がなくなります。

パスワードで使用される単語をブロックする

Okta Expression Languageを使用して、パスワードで使用される単語をブロックできるようになりました。この機能により、パスワードの強度要件をカスタマイズすることでセキュリティが強化されます。

End-User Settingsへの直接アクセス

ユーザーは、End-User Dashboard以外にも、URLから直接［設定］ページにアクセスようになりました。この機能によって、ユーザーの利便性とセキュリティや、管理者がEnd-User Dashboardアクセス制御のシナリオを扱う際の柔軟性が高まります。アクセシビリティとUXも改善されました。「Okta End-User Settings」を参照してください。

早期アクセス

AIエージェント向けOkta

Okta内で直接AIエージェントのアイデンティティを登録、保護、管理できるようになりました。AIエージェント用のOktaは、人間がエージェントを介してアプリへ接続する経路を保護するように設計されており、最小権限のアクセスを適用し、永続的な権限を排除し、System Logを使用してすべてのエージェントのアクションを追跡するのに役立ちます。また、シームレスなユーザーエクスペリエンスを維持しながら、AIエージェントをデジタル従業員の責任ある一員として機能させることもできます。「AIエージェントを管理」を参照してください。

侵害された資格情報の保護

侵害された資格情報の影響からorgを保護します。Oktaでは、サードパーティが選択したデータセットと比較した後、ユーザー名とパスワードの組み合わせが侵害されたと判断された場合、ユーザーパスワードのリセット、強制ログアウト、委任Workflowの呼び出しなど、パスワードポリシーにより保護応答をカスタマイズできます。「侵害された資格情報の保護」を参照してください。

侵害された資格情報の保護を米国連邦政府のお客様にもご利用いただけるようになりました。

Web SSOへのネイティブ

Native to Web SSOは、ユーザーがOIDCアプリ（ネイティブまたはWebアプリなど）からWebアプリ（OIDCまたはSAMLのいずれか）に移行するときに、シームレスで統合された認証エクスペリエンスを作成します。この機能では、SAMLやOpenID Connectなど、標準のWebベースのフェデレーションプロトコルを使用します。これにより、1回限りの一方向クライアント間信頼SSOトークンを使用して、2つの異なるアプリケーション環境間のギャップを埋めることができます。これにより、すでに提供されているサインオン保証の繰り返しが不要になり、認証の複雑さが軽減されることで、開発が簡略化されます。「Native to Web SSOを構成する」を参照してください。

ポリシーインサイトダッシュボード

ポリシーインサイトダッシュボードで、 orgに対するポリシーの影響を明確に把握できます。サインインの成功、アクセス拒否、 Authenticator登録の傾向を監視することができ、ユーザーのサインインにかかる時間やフィッシング耐性のある認証の普及についての知見も得ることができます。ダッシュボードではルール一致の頻度と、サインイン試行の成功の割合も追跡します。「ポリシーインサイトダッシュボードを使用する」を参照してください。

独自のTL：テレフォニー資格情報を持ち込む

TL：テレフォニーインラインフックを使用する必要がなく、簡単になった新しいセットアップを使用して、独自のTL：テレフォニープロバイダーに接続できるようになりました。使用量請求はプロバイダーと直接処理できます。Oktaは現在、TwilioとTelesignをサポートしています。「Admin ConsoleでTL：テレフォニープロバイダーを構成する」を参照してください。

WindowsでのOkta Verifyのリリース制御

新しいリリース制御機能で、管理者はWindowsでOkta Verifyの自動更新を許可、一時停止、または制限するかを構成できるようになります。これにより、企業の変更管理要件を満たし、Windowsエンドポイント全体でバージョンロールアウトを管理するための柔軟性が高まります。「Okta Verifyのリリース制御を構成する」を参照してください。

Okta Verifyによるユーザー検証のインラインステップアップフロー

エンド ユーザーは、現在の登録が不十分な場合でも、高いユーザー検証（UV）レベルを必要とする認証ポリシーを簡単に満たすことができます。この機能により、ユーザーにはUVの必要な有効化手順が事前に案内されます。そのため、管理者はより厳格な生体認証UVポリシーを自信を持って実装し、ユーザーロックアウトのリスクをなくし、UVの不一致に関連するサポートの問い合わせを減らすことができます。「Okta Verifyユーザー検証設定に基づくユーザーエクスペリエンス」を参照してください。

修正事項

  • パスワードを必要とするグローバルセッションポリシーが設定されたorgでは、orgのアプリサインインポリシーでその要素の組み合わせが許可されていても、ユーザーはパスワードと秘密の質問を使って認証できませんでした。（OKTA-1020729）

  • ユーザーがOkta Sign-In Widgetに無効なOTPを何度も入力し、［サインインに戻る］をクリックすると、誤ったページにリダイレクトされていました。（OKTA-1038368）

  • Authenticator登録ポリシーでOkta Verifyが要求された場合、一部のユーザーはデスクトップブラウザーでの登録を求められませんでした。（OKTA-1047509）

  • 次の属性が予約属性として正しく制限されていませんでした：orgid、activationstatus、apistatus、logintype、initialreconcilecomplete、activationdate、statuschangeddate、apilastupdate、passwordexpirationguess、passwordexpirationcursor、numunlocks、changedstatus。「予約済み属性のレビュー」を参照してください。（OKTA-1049339）

  • Preview Orgでは、バナーによってブロックされていたため、管理者にエラーメッセージが表示されませんでした。（OKTA-1053703）

  • レプリケーションの遅延中にユーザーがJIT経由でサインインしようとすると、500エラーが発生することがありました。（OKTA-1055324）

  • クレーム共有が有効になっているorgで、管理者がアプリサインインポリシーを変更しようとしても、 FastPass認証方法を無効にできませんでした。（OKTA-1076241）

  • End-User Settings 2.0が有効なorgでは、［自分の設定］ページにブランドロゴが表示されていませんでした。（OKTA-1082109）

  • End-User Settings 2.0が有効なorgでは、［自分の設定］ページのナビゲーションメニューにブランディングのプライマリ色が表示されていませんでした。（OKTA-1082119）

  • アクセステストツールで、どの条件が一致するかを説明する列のタイトルとテキストが、管理者にとってわかりにくい場合がありました。（OKTA-949568）

  • ユーザーがTouch IDでサインインしたときに、User.Session.StartイベントがSystem Logに記録されない場合がありました。（OKTA-996730）

  • 管理者がアプリユーザーのユーザー名を更新しようとするとエラーが発生していました。（OKTA-1047716）

  • LDAP Generalized Time属性を持つLDAPユーザーを管理者がOktaからLDAPにプロビジョニングしたときに、時刻値が誤ってフォーマットされていました。（OKTA-1056428）

  • コンピューターからの一部の認証試行が誤ってiOSデバイスと識別され、client.device eq "Computer"式を使用するポリシーでアクセス拒否が生じていました。（OKTA-1060121）

  • アプリの割り当てが完了する前にJITユーザーがSPにリダイレクトされ、アクセス拒否エラーが発生していました。（OKTA-1061698）

  • Okta Org2Org統合のorgでは、認証中にアドレスが変更された場合、Okta Sign-In Widget に誤ったユーザーメールアドレスが表示されていました。（OKTA-1063332）

  • Microsoft Office 365ユーザーのプロビジョニングが、429エラーで断続的に失敗していました。これは、システムがMicrosoft Entraのごみ箱にすでに存在するユーザーを、同じ onPremisesImmutableIdでプロビジョニングしようとしたときに発生しました。（OKTA-1068843）

  • 管理対象外デバイスの一部のユーザーが、Sign-In Widgetで内部サーバーエラーを受け取っていました。これはユーザーの認証されたorgの管理証明が有効になっているが、管理対象デバイスの修復に関するカスタムメッセージがない場合に発生しました。（OKTA-1079371）

  • Office 365の証明書ベースの認証を無効にしたorgでは、Windows Autopilotが誤ってアプリサインインポリシーから削除されていました。（OKTA-1081329）

  • DirSyncが有効な場合に、Active Directoryのインポートが「誤った結果サイズ」エラーで失敗していました。これは、Active Directoryでの新規グループの作成が、インポートプロセス中に重複するエントリを生成したために発生していました。（OKTA-1082847）

  • ユーザーがOkta End-User DashboardのMicrosoft Teamsタイルをクリックすると、「クラシックTeamsは利用できなくなりました」というエラーページが表示されていました。これは、Microsoftによる変更で宛先URLが古くなったために発生しました。（OKTA-1084267）

Okta Integration Network

週次のアップデート

2026.01.1：アップデート1は1月14日にデプロイメントを開始しました

一般提供

デバイス保証のOSバージョンアップデート

デバイス保証ポリシーで、次のOSバージョンがサポートされるようになりました。

  • Android 13、14、15、16セキュリティパッチ2026-01-05

新しいIPサービスカテゴリー

FINE_PROXYが拡張動的ゾーンのIPサービスカテゴリーとしてサポートされるようになりました。「サポートされるIPサービスカテゴリー」を参照してください。

Oracle IAMのプロビジョニング

Oracle IAMアプリの統合でプロビジョニングが利用できるようになりました。アプリをプロビジョニングするとき、エンタイトルメント管理などのセキュリティ機能を有効にできます。「Oracle IAM」を参照してください。

修正事項

  • Admin Consoleでのユーザーステータスと、パスワードレスのメールで認証するユーザーに関してAPIで報告されるステータスの間に不一致がありました。（OKTA-938801）

  • 管理者が認証方法チェーンを使用して認証ポリシーを作成し、無効な再認証頻度の値を入力した場合に、エラーが表示されませんでした。（OKTA-954253）

  • クレーム共有が有効になっているOrg2Org ClassicからOkta Identity Engineへのセットアップで、ユーザーがOkta Identity Engine orgにサインインするときに、追加の要素の入力を求められました。これは、Classic orgでパスワードを入力し、Identity Engine orgのアプリサインインポリシーを［任意の1要素］に設定していても発生しました。（OKTA-1016793）

  • ［AIエージェント］ページで、［所有者］と［資格情報］タブの間隔に一貫性がありませんでした。（OKTA-1054201）

  • 一部のorgでは、ユーザーがアプリに初めてアクセスを試みたときに403エラーが表示されていました。（OKTA-1059737）

  • 管理者がユーザープロファイルポリシーに識別子を追加するときに、最大文字数の制限がありませんでした。（OKTA-1061030）

  • ポリシーが［任意の2要素タイプ］に設定され、所有要素の制約が含まれている場合、管理者がアプリサインオンポリシーのためのパスワードとセキュリティ質問のAuthenticatorを構成できませんでした。（OKTA-1061839）

  • グローバルセッションポリシーで［AND動作：］ルールが［新しいデバイス］に設定された場合に表示されるメッセージで、ユーザーがサインインのたびにMFAを要求されることが明示されていませんでした。（OKTA-1064096）

  • 複数の登録があるUEP AuthenticatorのSign-In Widgetにカスタムロゴが表示されませんでした。（OKTA-1069399）

  • End User Settingsバージョン2.0が有効になっているorgで一部のユーザーに、パスワード要件の説明でHTMLエスケープされた文字が表示されていました。（OKTA-1080153）

  • 拡張動的ゾーンがGOOGLE_VPNをブロックするように構成されている場合、GOOGLE_RENDER_PROXYからのリクエストもブロックされていました。（OKTA-1080379）

  • SPAでは、ユーザープロファイルを保存すると、明示的に更新されない限り、trueのブールのプロパティがすべてfalseに設定されていました。（OKTA-1086548）

  • orgに20を超えるネットワークゾーンが構成されている場合、［セッション保護］ページのドロップダウンメニューに表示されないネットワークゾーンがありました。（OKTA-1089885）

  • アクセスリクエスト条件によって管理されるリクエストには、リクエストの承認および拒否に関するメールとMicrosoft Teams通知がSlack通知UIと一致しませんでした。

早期アクセス

デバイスバウンドシングルサインオン

デバイスバウンドシングルサインオンでは、ユーザーがOkta-joinedのmacOSやWindowsのデバイスにサインインした後、ハードウェア保護されたセッションが開始されてアプリへシームレスにアクセスできるようになります。この機能は、セッションリプレイ保護と能率的な認証エクスペリエンスを提供します。「デバイスバウンドシングルサインオン」を参照してください。

Okta Integration Network

  • Sesmic（SCIM）が利用可能になりました。 詳細はこちら .

  • OX Security（OIDC）が利用可能になりました。 詳細はこちら .

  • Skedda（SCIM）が利用可能になりました。 詳細はこちら .

  • Jotform（SCIM）が利用可能になりました。 詳細はこちら .

  • Planhat（SCIM）が利用可能になりました。 詳細はこちら .

  • Safety AZ（OIDC）が利用可能になりました。 詳細はこちら .

  • Exabeam（SAML）が利用可能になりました。 詳細はこちら .

  • 101domain（OIDC）が利用可能になりました。 詳細はこちら .

  • OX Security（OIDC）でUniversal Logoutがサポートされるようになりました。

  • Skedda（SAML）の説明、アイコン、構成ガイドが新しくなりました。

  • Obsidian Security（SAML）の構成ガイド、属性、アプリの説明が新しくなりました。

  • Planhat（SAML）の構成ガイドが新しくなりました。

  • Exaforce（APIサービス）にokta.idps.readスコープが追加されました。

  • Seismic (SAML) のロゴ、アプリ説明、構成ガイドが新しくなりました。

  • BridgeBank Business eBanking（SWA）が更新されました。

  • Humana Military（SWA）が更新されました。

  • Jotform（SAML）が更新されました。

  • Scalefusion OneIdP（SCIM）が更新されました。

プレビュー機能

［ユーザープロファイルリスク］タブのUIの改善

視認性向上のために［ユーザープロファイルリスク］タブの表の列の並び順が変更され、コンテキスト変更イベントがポリシー違反イベントに置き換えられました。

LDAP双方向グループ管理

Lightweight Directory Access Protocol（LDAP）の双方向グループ管理では、Okta内からLDAPグループを管理できます。IDとアクセス要件に基づいてユーザーをグループに追加したり、削除したりできます。これにより、Oktaで加えたユーザーアクセスの変更が、LDAPに反映されます。

Oktaが管理できるのは、LDAPまたはActive Directory（AD）統合を使ってOktaにインポートされたユーザーとグループのグループメンバーシップのみです。LDAPまたはAD統合を通じてインポートされなかったユーザーやグループ、またはこの機能を利用している統合の組織単位の範囲外にあるユーザーやグループを管理することはできません。

LDAP増分インポートの最大クロックスキューオプションがさらに詳細に

LDAP増分インポートに、より詳細な最大クロックスキュー間隔が追加され、さらに適切な調整が可能になり、パフォーマンスが向上しました。クロックスキューを1分、2分、5分または10分に構成できるようになりました。この細かな構成により、 LDAPサーバーの実際の最大クロックドライブに近いクロックスキュー値を使用することで、インポート速度を向上できます。また、サーバーの時計が一時的に逆戻りしたときに更新を見逃すことを防止することで、データ精度を確保します。

カスタムFIDO2 AAGUID

お客様は、FIDOメタデータサービス（MDS）以外のセキュリティキーや他のAuthenticatorを追加して、それらをより詳細に制御できます。これにより、FIDO2（WebAuthn）Authenticatorのサポートが幅広いセキュリティキーや他のAuthenticatorに拡張され、お客様が環境内のセキュリティをより柔軟に制御できるようになります。

関連ドメイン

関連ドメインを利用することで、アプリ、参照ドメイン、そのドメインに関連付けられるユーザーの資格情報、Okta内の自社ブランドの間に信頼関係を構築できます。この機能により、FIDO2 (WebAuthn) authenticatorのパスキーなどのフィッシング耐性のあるAuthenticatorを簡単に採用できます。「関連ドメインを構成する」を参照してください。

パスワードの最大連続文字数の設定

パスワードの連続繰り返し文字の最大数を設定できるようになりました。この機能により、パスワードの強度要件をカスタマイズすることでセキュリティが強化されます。

Workdayによる増分インポートのサポート

Workdayに増分インポートを直ちに実行する機能が加わりました。増分インポートはフルインポートよりもはるかに速いです。ただし、ユーザーがカスタム属性のみを変更した場合は検出されないため、これらの変更を取得するには定期的にフルインポートを実行する必要があります。「増分インポート」を参照してください。

Okta FastPassの同一デバイス登録

Okta FastPassを使用しているorgでは、Okta Verifyの登録プロセスが合理化されています。 - ユーザーは、現在使用中のデバイス上で登録の開始から完了までを行うことができます。以前は、アカウントをセットアップするには2つの異なるデバイスが必要でした。- ユーザーは登録時にorgのURLを入力する必要がなくなりました。- 登録フローの手順が少なくなりました。この機能は、Android、iOS、macOSデバイスでサポートされています。

Admin Consoleへの新規の単一要素アクセスを防止する

この機能は、Admin Consoleへの単一要素アクセスを管理者が構成できないようにします。この機能は現在、新しいorgにのみ利用できます。

アプリケーションエンタイトルメントポリシー

管理者は、アプリを個人またはグループに割り当てる際に属性マッピングを上書きできるようになりました。また、属性をデフォルトのマッピングに戻すこともできます。「アプリケーション属性マッピングを上書きする」を参照してください。この機能は、すべてのorgで段階的に利用できるようになります。

ニックネーム要素のエンドユーザー設定

エンドユーザーは、電話、WebAuthn、Okta Verifyの要素にニックネームを付けられるようになりました。1つの要素のインスタンスを複数登録している場合は、ニックネームを付けると要素をすぐに識別しやすくなります（例：「自分の個人携帯電話」または「自分のオフィス用MacBook TouchID」）。「エンドユーザー向けドキュメント」を参考にしてください。これはセルフサービスの機能です。

エンドユーザーページでコンテンツセキュリティーポリシーを適用する

コンテンツセキュリティーポリシーが、カスタマイズ不可のページでカスタムドメインがあるorgのエンドユーザーページに適用されるようになりました。コンテンツセキュリティーポリシーのヘッダーにより、ブラウザーでWebページが実行できるアクションの種類を確実に認識できるようにすることで、クロスサイトスクリプトやデータインジェクションといった攻撃を検出できる追加のセキュリティーレイヤーを提供します。昨年から管理者ページにはポリシーがすでに適用され、エンドユーザーページに対してもレポートのみのモードに適用されています。今後もエンドユーザーページに対するコンテンツセキュリティーポリシーの適用を繰り返し行っていくことで、この最初のリリースよりも厳格にしていく予定です。

この機能は、すべてのorgで段階的に利用できるようになります。

システムログイベントの詳細

Oktaがセキュリティ脅威を特定すると、結果のシステムログエントリ「security.threat.detected」にイベントの詳細な理由が提供されるようになりました。「システムログ」を参照してください。

新しい柔軟なLDAP

新しいLDAPスキーマでは、メールをカスタムスキーマに移動し、名、姓、ユーザー名、UIDを任意にすることで柔軟性が向上します。これにより、LDAPスキーマに特定の属性が含まれていない場合のエラーシナリオを回避できます。

ThreatInsightのコアOkta APIエンドポイントでの対象範囲

Okta ThreatInsight対象範囲が、コアOkta APIエンドポイントに利用できるようになりました。

Okta ThreatInsightは、ヒューリスティックスと機械学習モデルに基づいて、Oktaの顧客ベース全体で悪意のあるアクティビティを一貫して示すIPアドレスのリストを更新して維持します。Okta orgにOkta ThreatInsightが有効化されている場合、これらの不正なIPアドレスからのリクエストはブロックされるか、さらに分析するために昇格されます。これまで、Okta ThreatInsightの対象範囲は、Okta認証エンドポイント（登録エンドポイントと復旧エンドポイントを含む）にのみ適用されていました。本リリースでは、認証エンドポイントに強化された攻撃パターンが検出され、非認証エンドポイントにも制限された攻撃パターンが検出されます。既存のOkta ThreatInsight構成に変更はありません。ログとブロックモード、ログモード、および除外ネットワーク ゾーンを使用しても、Okta ThreatInsightを有効化できます。高脅威のsecurity.threat.detectedイベントに対して、Negative IP Reputationの新しい理由が利用可能になりました。「Okta ThreatInsightのシステムログイベント」を参照してください。

SSOアプリのダッシュボードウィジェット

SSOアプリの新しいウィジェットには、選択した期間におけるorgの各アプリでのユーザーサインインイベント数が表示されます。これを使用すれば、最も頻繁に使用されるアプリを確認し、org全体の認証アクティビティを簡単に監視できます。

システムログのメール失敗イベント

管理者はシステムログでメール配信失敗イベントを表示できるようになりました。これにより、管理者がorg内のメールイベントアクティビティを適切に監視できるようになります。「システムログ」を参照してください。

セルフサービスロック解除プロセスの改善

以前のバージョンのセルフサービスロック解除（SSU）フローでは、エンドユーザーエクスペリエンスで不要な摩擦が発生していました。新しく強化されたSSU機能により、アカウントのロック解除メールにシームレスなマジックリンクエクスペリエンスが導入されます。ユーザーは、同じブラウザーを使用する場合は同意を提供する必要がなくなりました。さらに、アカウントのロック解除に成功した後、メールマジックリンクのクリックもアプリの保証ポリシーに反映されるようになりました。保証要件が満たされた後、ユーザーはアプリに直接サインインします。

セルフサービス登録エクスペリエンスの改善

セルフサービス登録（SSR）フローの以前のバージョンでは、複雑な一連のテンプレートを使用して、アクティベーションメールをエンドユーザーに送信していました。これは、簡素化されたSSRフローにより、カスタマイズされたウェルカムメッセージを含む2つのメールテンプレートのみに削減されます。アプリでエンドユーザーのメールアドレスをすぐに確認する必要がある場合、Oktaでは登録 - アクティベーションテンプレートを使用します。このテンプレートには、よりスムーズなサインインエクスペリエンスのためのマジックリンクが含まれています。アプリへのサインインにメール確認がすぐに必要でない場合、Oktaでは登録 - メール確認テンプレートを使用します。このテンプレートには、エンドユーザーがアプリに正常にサインインした後に随時メール確認を完了するためのリンクが含まれています。

デバイス認可の付与タイプ

インターネット技術の進歩により、スマートデバイスやIoT（Internet of Things）が急増しています。ユーザーはこれらのデバイスで実行されるアプリにサインインする必要がありますが、スマートTV、車のコンソール、サーモスタットなどのデバイスではWebブラウザーがサポートされていないか、入力機能が制限されています。そのため、ユーザーはエラーが発生しやすく時間のかかる、安全でない認証ソリューションを利用することになります。

デバイス認可付与機能はOAuth 2.0の付与タイプで、入力に制約のあるデバイスだけでなく、Webブラウザーのないデバイスにもサインインできます。この機能により、ユーザーはノートパソコンや携帯電話などのセカンダリデバイスを使用して、そのようなデバイスで実行されるアプリにサインインすることができます。