メインコンテンツへスキップ
この認証方式は最も安全と考えられます。認証リクエストをユーザーに直接送るのではなく、アプリケーションが Vantage の認可サーバーに送信するためです。認可サーバーがユーザーを認証し、クライアントに認可コードを返します。 認可コードの傍受を防ぐために、この認証シナリオでは PKCE (Proof Key for Code Exchange) というセキュリティ拡張を使用します。動作は次のとおりです。各認可リクエストで暗号学的に安全な乱数を生成して code_verifier に保存し、それを用いて code_challenge に格納する暗号学的に導出された値を生成します。続いてこの値を認可サーバーへ送信し、認可コードを取得します。 PKCE の詳細については こちらをご覧ください。

​
認可コードの取得

認証プロセスを開始するには、以下のパラメーターを渡してユーザーを authorize エンドポイントにリダイレクトします。
response_type、scope、productId の値は、必ず上記のとおり正確に指定してください。response_type を除くこれらのキーは変更される可能性があります。設定で管理することをお勧めします。
サンプルリクエスト リソースの識別子を含む redirect_uri パラメーターは OAuth 2.0 で使用されます。これにより、Vantage は認可コードをリソースに送信し、そのコードをアクセストークンに交換できます。アクセストークンは、以降のすべての API call での認証に必要です。この認証方法を使用するには、redirect_uri パラメーターの値を ABBYY technical support に提供し、管理者によってホワイトリストに登録してもらう必要があります。 scope パラメーターで要求したアクセス権限の付与が確認されると、ブラウザーは Vantage server で設定された専用の Web ページにリダイレクトされます。この Web ページには、アカウントを使用して認可を行うためのダイアログウィンドウが表示されます。このページは、ページ URL と接続の SSL 証明書の状態を確認できるよう、アドレスバーが表示されるブラウザーで開く必要があります。 メールアドレスが異なるテナント内の複数のアカウントに関連付けられている場合は、メールアドレスを入力した後、テナントの選択と password の入力を求められます。次のいずれかのリソースを使用して、テナント identifier (tokenId パラメーター) を直接渡すこともできます。 または テナント アカウントの password を入力する必要があります。認証情報を入力すると、認可はサーバー側で完了し、アプリケーションに Vantage API へのアクセスが付与され、request へのレスポンスで認可コードが返されます。 この認証タイプをサイトまたはアプリケーションが使用する場合、Vantage ユーザーは、自分に代わって、許可されたリダイレクト URL のリストに追加するそのサイトまたはアプリに Vantage API へのアクセス権を与えることになります。サイトまたはアプリにアクセス権を与えるために、ユーザーは自分のログイン名とパスワードを使って Vantage にログインして認証を行うよう求められます。ユーザーが認証されると、そのサイトまたはアプリには次の権限が付与されます。
  • ユーザーに代わって Vantage テナント内のデータ カタログを管理すること
  • ユーザーに代わって Vantage テナント内の Skill にアクセスすること
  • ユーザーに代わって Vantage トランザクションを作成および参照すること
そのサイトまたはアプリは、ユーザーのパスワードを変更したり、Vantage テナントのユーザー一覧を変更したり、Skill を編集したりすることはできません。許可されるのは Vantage API へのアクセスのみです。一度アクセス権が付与されると、ユーザーがそのアクセス権を取り消すことはできません。

​
認可トークンの取得

認可コードを取得したら、1分以内にアクセストークンへ交換します。application/x-www-form-urlencoded データを使用して、トークンエンドポイントに POST リクエストを送信します。 リクエスト本文のパラメーター: サンプルリクエスト: Windows の場合: Linux の場合: サーバーからの応答にはアクセス トークンが含まれます。
認可コードフローの詳細は、こちらをご覧ください。 各フローのレスポンスでは、access_token キーにトークンが含まれ、expires_in キーにトークンの有効期限までの残り時間 (秒) が指定されます。デフォルトのアクセストークンの有効期間は 24 時間です (詳細は Token lifetimes を参照してください) 。すべてのリクエストに次の Authorization ヘッダーを追加し、token を取得したトークンの値に置き換えてください。
同じアカウントでも複数のトークンを取得できることに注意してください。認可トークンの詳細については、こちらのリンクをご覧ください。

​
リフレッシュトークンの取得

Vantage API クライアントを設定する際に Allow issuing refresh tokens to refresh access tokens オプションを有効にし、アクセストークンを取得するためのリクエストに scope=openid permissions global.wildcard offline_access パラメーターが含まれていた場合、レスポンスとして追加のリフレッシュトークンも受け取ります。リフレッシュトークンを取得したら、次のパラメーターを指定してトークンエンドポイントに POST リクエストを送信することで、アクセストークンを更新できます。 サンプルリクエスト: Windows の場合: Linux の場合:

​
トークンの有効期間

Access トークンと Refresh トークンには、次の有効期間が設定されています。
  • Access トークンの有効期間: 発行された Access トークンを使用してユーザーが Vantage にアクセスできる期間を定義します。Access トークンの既定の有効期間は 24 時間です。
  • Refresh トークンの有効期間: 最初の Access トークンが発行された時点から起算される固定の期間を定義し、その期間中は発行された Refresh トークンを使用して Access トークンを更新できます。Refresh トークンの既定の有効期間は 30 日です。