独自のメールプロバイダーを使用する
Oktaが管理するSMTPサーバーではなく、サードパーティプロバイダーを介してOkta通知メールを送信する場合は、外部のメールプロバイダーを使用します。カスタムメールプロバイダーを追加すると、ビジネス要件と規制要件を満たすことができます。
- 特定の地理的場所にデータを保存するメールプロバイダーを選択することで、データレジデンシー要件が満たされます。
- メールに使用されるIPアドレスを制御できます。
- メールの配信や使用状況など、送信するメールに関する詳細な指標と情報を取得できます。
Oktaでは複数回、カスタムメールプロバイダー経由でのメッセージ配信を試行します。最初の試行が失敗すると、メッセージをキューに入れて、後で配信を再試行します。2回目の試行が失敗した場合は、メッセージはより長い遅延で再度キューに入れられます。最大再試行回数を超えると、FAILUREの配信イベントがSystem Logに記録されます。このような場合、メッセージの配信はOktaのデフォルトメールサービスにフォールバックされません。配信が成功すると、SUCCESSの配信イベントがSystem Logに記録されます。
接続タイプ
Oktaは、基本的なSMTPおよびOAuth 2.0認証を備えたカスタムメールプロバイダーをサポートします。
基本的なSMTP認証では、ユーザー名とパスワードを使用して、SMTPサーバーへのリクエストを認可します。管理者資格情報がこれらのリクエストで送信および保存されるため、一部のメールプロバイダー(MicrosoftやGoogle Workspaceなど)では、基本的なSMTP認証のサポートが廃止されます。
Oktaでは、これらのカスタムメールプロバイダーを使用するorgに、Microsoftの要件をサポートするクライアント資格情報フローと、Googleの要件をサポートするJWTベアラートークンフローの2つのOAuth 2.0認証オプションを提供しています。
開始する前に
-
お使いの外部メールプロバイダーをセットアップします。「カスタムSMTP」を参照してください。
- プロバイダーのSMTPサーバーに関する次の詳細を収集します。
- Host(ホスト):SMTPサーバーのホスト名またはIPアドレス(例:your.smtp.host.com)。
- Port(ポート):SMTPサーバーが使用するポート。Oktaではデフォルトで465、587、2587がサポートされます。orgが標準以外のポートを使用している場合は、Oktaサポートまでお問い合わせください。
- [Username(ユーザー名)]:自分のSMTPユーザー名。
- [SMTP password(SMTPパスワード)]:自分のSMTPパスワードまたはGoogleアプリのパスワード。
OAuth 2.0を使用してカスタムメールプロバイダーを追加する
早期アクセスリリース。「セルフサービス機能を有効にする」を参照してください。
OAuth 2.0認証は、クライアント資格情報またはJWTベアラートークンを使用して構成できます。
クライアントの資格情報
このオプションでは、基本的なSMTP認証にMicrosoftを現在使用しているorgがサポートされます。クライアント資格情報を使用してOAuth 2.0プロバイダーを作成すると、クライアントシークレットはAPIレスポンスに返されません。
- Admin Consoleでに移動します。
- [Add custom email provider(カスタムメールプロバイダーを追加)]をクリックします。
- [Connection type(接続タイプ)]ドロップダウンメニューで、[OAuth 2.0 - client credentials flow(OAuth 2.0 - クライアント資格情報フロー)]を選択します。
- OAuth 2.0クライアント資格情報フローの詳細を入力します。
- クライアントID
- クライアントシークレット
- Scope(スコープ)
- トークンエンドポイントURL
- トークンエンドポイント認証方式
- SMTPの詳細([Host(ホスト)]、[Port(ポート)]、[Username(ユーザー名)])を入力します。
- [Save(保存)]をクリックします。新しいプロバイダーが追加されます。
- テストメールを送信して、正しく動作することを確認します。
- [Use custom email provider(カスタムメールプロバイダーを使用)]に切り替えます。
クライアントシークレットの有効期限が切れると、OAuth 2.0構成は機能しなくなります。OktaはこれをイベントとしてSystem Logに記録しますが、更新を求めるプロンプトは表示されません。新しいものを生成し、この日付までに構成を更新してください。
JWTベアラートークン
このオプションでは、基本的なSMTP認証にGoogle Workspaceを現在使用しているorgがサポートされます。クライアント資格情報を使用してOAuth 2.0プロバイダーを作成すると、秘密鍵はAPIレスポンスに返されません。
- Admin Consoleでに移動します。
- [Add custom email provider(カスタムメールプロバイダーを追加)]をクリックします。
- [Connection type(接続タイプ)]ドロップダウンメニューで、[OAuth 2.0 - JWT bearer tokens flow(OAuth 2.0 - JWTベアラートークンフロー)]を選択します。
- OAuth 2.0クライアント資格情報フローの詳細を入力します。
- クライアントID
- トークンエンドポイントURL
- Signing algorithm(署名アルゴリズム)
- キーID(kid)
- 発行者(iss)
- 件名(sub)
- オーディエンス(aud)
- Scope(スコープ)
- 秘密鍵
- SMTPの詳細([Host(ホスト)]、[Port(ポート)]、[Username(ユーザー名)])を入力します。
- [Save(保存)]をクリックします。新しいプロバイダーが追加されます。
- テストメールを送信して、正しく動作することを確認します。
- [Use custom email provider(カスタムメールプロバイダーを使用)]に切り替えます。
秘密鍵の有効期限が切れると、OAuth 2.0構成は機能しなくなります。OktaはこれをイベントとしてSystem Logに記録しますが、更新を求めるプロンプトは表示されません。新しいものを生成し、この日付までに構成を更新してください。
基本的なSMTP認証でカスタムメールプロバイダーを追加する
一部のメールプロバイダー(MicrosoftやGoogle Workspaceなど)では、基本的なSMTP認証のサポートが廃止されます。Oktaでは、可能であれば、カスタムメールプロバイダーでOAuth 2.0認証を使用することを推奨しています。
カスタムメールプロバイダーを追加する(Google Workspace以外)
- Admin Consoleでに移動します。
- [Add custom email provider(カスタムメールプロバイダーを追加)]をクリックします。
- [Connection type(接続タイプ)]ドロップダウンメニューで、[Basic authentication(基本認証)]を選択します。
- SMTPの詳細([Host(ホスト)]、[Port(ポート)]、[Username(ユーザー名)]、[SMTP password(SMTPパスワード)])を入力します。
- [Save(保存)]をクリックします。新しいプロバイダーが追加されます。
- テストメールを送信して、正しく動作することを確認します。
- [Use custom email provider(カスタムメールプロバイダーを使用)]に切り替えます。
Google Workspaceをカスタムメールプロバイダーとして追加する
Googleでは、Oktaなどの外部製品から同社サービスにアクセスする際にユーザー名とパスワードを許可していません。代わりに、Google WorkspaceでOAuthトークンの一種であるアプリパスワードを生成し、そのトークンを OktaでSMTPパスワードとして使用します。
- Google Workspaceでアプリパスワードを作成します。Googleのサポート記事「アプリパスワードを作成、使用する」を参照してください 。
- アプリパスワードをコピーして、安全な場所に保存します。
- Okta Admin Consoleでに移動します。
- [Add custom email provider(カスタムメールプロバイダーを追加)]をクリックします。
- [Connection type(接続タイプ)]ドロップダウンメニューで、[Basic authentication(基本認証)]を選択します。
- SMTPの詳細([Host(ホスト)]、[Port(ポート)]、[Username(ユーザー名)])を入力します。
- [SMTP password(SMTPパスワード)]フィールドにアプリパスワードを貼り付けます。
- [Save(保存)]をクリックします。
- テストメールを送信して、正しく動作することを確認します。
- [Use custom email provider(カスタムメールプロバイダーを使用)]に切り替えます。
Googleのサポート記事「安全性の低いアプリからOAuthへの移行」をご参照ください。
テストメールを送信する
メールプロバイダーが正しく構成されていることを確認するために、テストメールを送信します。
- Admin Consoleでに移動します。
- [SMTP server(SMTPサーバー)]の下の[Send test email(テストメールを送信)]をクリックします。
- [From(送信元)]アドレスを入力します。機能する有効なメールアドレスを使用してください。SMTPサーバーは、このテストの一環としてメールアドレスを検証します。
- [To(宛先)]アドレスを入力します。テストメールの送信先となるアドレスです。メールクライアントでこのメールアドレスにアクセスできることを確認します。
- [Send test email(テストメールを送信)]をクリックします。
- メールが送信され、通知が表示されます。
- メールクライアントで、[To(宛先)]アドレスにアクセスし、テストメールが届いたことを確認します。
カスタムメールドメインをブランドに追加する
カスタムメールドメインを各ブランドに追加します。
- Admin Consoleで[Brands(ブランド)]に移動します。
- カスタムメールドメインの追加先ブランドをクリックします。
- に移動します。
- デフォルトokta.comドメインの横の[Add email domain(メールドメインを追加)]をクリックします。
- メール送信者のメールアドレスと名前を追加します。ユーザーの受信ボックスにはこの情報が表示されます。
- [Next(次へ)]をクリックします。
- まだ構成していない場合は、メールプロバイダーを構成します。前のタスクを参照してください。
- [Verify(確認)]をクリックします。メールプロバイダーがブランドに追加され、に表示されるようになります。
- ブランドごとに手順を繰り返します。
カスタムメールプロバイダーを削除する
orgのカスタムメールプロバイダーを削除します。プロバイダーを削除すると、orgのどのブランドもそのプロバイダーを使用しなくなります。その後、メールはデフォルトのメールプロバイダーokta.comから送信されます。
- Admin Consoleでに移動します。
- メールプロバイダーの横の[Delete(削除)]アイコンをクリックします。[Remove email provider(メールプロバイダーを削除する)]ページが表示されます。
- [Remove email provider(メールプロバイダーの削除)]をクリックします。
カスタムメールプロバイダーを編集する
- Admin Consoleでに移動します。
- メールプロバイダーの横の[Edit(編集)]アイコンをクリックします。[Edit custom email provider(カスタムメールプロバイダーを編集する)]ページが表示されます。
- メールプロバイダーの情報を編集します。
- [Save(保存)]をクリックします。
