OAuthによる認証機能の紹介(ASTERIA Warp 2212以降)

ASTERIA Warp 2206で、OAuth2.0による認証機能が標準機能として実装されました。

ASTERIA Warp 2212以降では、OAuthによる認証を実行する際のブラウザが、クライアント側で起動されます。クライアント側とは、フローサービス管理コンソール(FSMC)またはフローデザイナーを表示しているPC端末のことを指します。

下記のコネクションで、OAuthを設定できます。

HTTP / SMTP / POP3 / IMAP4 / GoogleSheets(ASTERIA Warp 2512以降)

※マルチセレクトオプションでは、ASTERIA Warp 2412以降でクライアント側でのOAuthによる認証に対応しました。マルチセレクトオプションでOAuthによる認証を使用する場合については、「マルチセレクトオプションにおける注意事項」をお読みください。

■重要事項

クライアントからのOAuthによる認証

ASTERIA WarpでのクライアントからのOAuthによる認証には、以下の2つの方法があります。

  • フローサービス管理コンソール(FSMC)から認証を実施する

    コネクション設定画面で接続テストを実行するとブラウザの別タブでユーザー認証が始まります。認証が終わると元タブに戻り接続テストの結果が表示されます。

    認証サービス側の設定でリダイレクトURIに、フローサービス管理コンソール起動サーバーのホスト名に基づく固定URIを指定します。

    コールバックURLの設定については、FSMCヘルプの「OAuth認証」の項と各コネクションの項をご確認ください。(HTTP / SMTP / POP3 / IMAP4

  • フローデザイナーから認証を実施する

    コネクションペインで接続テストを実行するとブラウザが起動してユーザー認証が始まります。認証が終わるとフローデザイナーに接続テストの結果が表示されます。

    認証サービス側のリダイレクトURIを指定する必要がある場合、リダイレクトURIの値とASTERIA Warpのコネクション情報の「コールバックURL」プロパティの値は同じ値を設定してください。異なる値を設定すると認証時にエラーになります。

    認証サービス側でリダイレクトURIの指定が不要の場合、ASTERIA Warpのコネクション情報の「コールバックURL」には「http://localhost:[使用していないポート]」を設定してください。

    コールバックURLの設定については、フローサービス マニュアルの各コネクションの項をご確認ください。(HTTP / SMTP / POP3 / IMAP4

必要に応じて、どちらの方法を用いるか使い分けるようにしてください。

OAuth 2.0の認可フロー

OAuth 2.0の認可フローにはいくつかの種類がありますが、ASTERIA Warpでは以下の2つのみに対応しています。

※下記以外のOAuth認可フローの場合は、RESTコンポーネントで実装する必要があります。

  • 認可コードフロー
  • リフレッシュトークンフロー

■実施手順

ASTERIA Warp 2212以降でOAuthによる認証を実施する手順を、下記の認証サービスごとに説明します。

ASTERIA Warp 2206でOAuthによる認証を実施する手順については、下記の記事をお読みください。

■トラブルシューティング

ASTERIA Warp 2212以降で、OAuthによる認証時のエラーへの対処方法について解説します。

※ASTERIA Warp 2206の場合、「OAuth認証機能の紹介(ASTERIA Warp 2206)」の「■注意事項」をご確認ください。

エラーが発生した場合、以下の順で設定を確認してください。

①認証サービス側の設定

②メール関連の場合、メールサービス側の設定

上記①②の認証サービス側やメールサービス側の設定確認については、前述の認証サービスごとの実施手順の記事をご参照ください。

③ASTERIA Warp側のコネクションの設定

④プロキシの設定

⑤接続テストで接続を確認


ASTERIA Warp側のコネクションの設定を確認する

□ コネクションの「OAuthを使用」が「はい」になっているか

□ クライアントID/クライアントシークレットに正しい値が設定されているか

□ 認証エンドポイント/トークンエンドポイントのURLに正しい値が設定されているか

※上記の各認証サービスでの実施手順ご確認ください。

□ フローデザイナーからの接続の場合、コールバックURLのポート番号は端末内で未使用か

フローデザイナーの接続テスト結果に「java.net.BindException: Address already in use: bind​」と表示された場合、コネクションの「コールバックURL」に指定したポートが、利用端末ですでに使用中であることが考えられます。使用していないポートを設定してください。


プロキシの設定

FSMC/mcapi.logで「API_E_5000: サーバーエラー​」と表示される場合、または、フローデザイナーの接続テスト結果に「Connect timed out​」と表示される場合、プロキシやファイアウォールなどネットワーク経路上で制限されていることが考えられます。

プロキシ環境で使用している場合、下記をご確認ください。

□ コネクション設定の「OAuth認証設定」で「プロキシサーバー」が「使用する」になっているか

□ FSMCまたはフローデザイナーのプロキシ設定に正しい値が設定されているか

OAuthによる認証を実行する際のクライアント側が、FSMCまたはフローデザイナーによって、プロキシサーバーの設定箇所が異なります。クライアント側のプロキシ設定が正しく設定されているかをご確認ください。

□ ファイアウォールなどで対象のネットワークの通信をブロックしていないか

ネットワーク環境の設定をご確認ください。


接続テストで接続を確認

FSMCまたはフローデザイナーのコネクションで接続テストを行います。

失敗した場合、下記をご確認ください。

□ FSMCまたはフローデザイナーから実施する接続テストのコネクション情報が正しいか確認する

□ ブラウザのキャッシュをクリアしてから再度テストを行う

□ 認証サービスからログアウトしてから再度テストを行う

□ 新規コネクションを作成して接続テストを行う

□ 表示されたエラーメッセージの内容と該当する箇所を確認する

□ 再度、各種設定に誤りや不足がないか確認する

 

この記事は役に立ちましたか?
0人中0人がこの記事が役に立ったと言っています

他のキーワードで検索する