Spotnana の認証方法について

作成者 Ashish Chaudhary, 変更日 土, 4 10月 で 3:05 午前 作成者 Ashish Chaudhary

Spotnanaの認証フロー - 概要

目次

Spotnanaでは、パートナー様が当社プラットフォームと安全に連携できるよう、さまざまな認証方式をご用意しています。本ドキュメントでは、Spotnanaが現在サポートしている各認証方式の概要と、その具体的なプロセスについてご説明します。ここでご紹介する認証フローを通じて、Spotnanaがどのようにユーザーを認証・認可し、組織単位で保護されたリソース(つまりユーザーの所属企業がSpotnana上で管理する情報)へのアクセスを許可しているかをご理解いただけます。


主要な構成要素

始める前に、このドキュメントで登場するシステムの主要な構成要素について、定義を確認しておきましょう。

  • Spotnana UI(Spotnana ユーザーインターフェース) SpotnanaのフロントエンドWebアプリ(オンライン予約ツール)や、Spotnanaのモバイルアプリを指します。特に、ユーザーがログインや新規登録を行う際に表示されるログイン画面を指し、ここからフロントエンドの認証フローが始まります。
  • Spotnanaサーバー 認証のために利用されるSpotnanaのバックエンドサーバーです。ユーザーのリソースへのアクセス許可や、ユーザー情報の安全な保存・処理などを担っています。
  • パートナーUI (パートナーのユーザーインターフェース) パートナー企業がSpotnanaプラットフォームにアクセスするために利用するフロントエンドアプリケーションです。たとえばiFrame認証の場合、Spotnanaの画面がパートナーUI内に埋め込まれ、ユーザーはパートナーUI経由でSpotnanaを利用します。
  • パートナーサーバー Spotnanaとの連携のために、パートナー企業が利用するバックエンドサーバーを指します。
  • Spotnana IdP (Spotnanaアイデンティティプロバイダー) ユーザーのID管理や認可を担う、Spotnanaの内部サービスです。
  • パートナーIdP パートナー企業が利用する外部のアイデンティティプロバイダー(IdP)です。GoogleやAzureなどがよく使われています。 
  • OBT Spotnanaのオンライン予約ツール(OBT)。以下のURLからアクセスできます。 https://app.spotnana.com/ 
  • サブジェクトトークン iFrame認証(トークン交換方式)では、サブジェクトトークンはユーザーのIDを表します。このトークンを使ってユーザー情報を取得し、Spotnanaプラットフォームへのアクセス権を認可します。
  • アクセストークン パートナーアプリがユーザーの代理として保護されたリソースにアクセスするために使う、一時的な認可キー(OAuthの認証情報)です。ユーザーのパスワードなどを直接やり取りせず、APIリクエストを行うことができます。
  • リフレッシュトークン ユーザーが再認証しなくても新しいアクセストークンを取得できる、長期間有効な認証情報です。初回ログイン時などにアクセストークンとセットで発行されます。
  • クライアント認証情報 Spotnana APIに直接接続するユーザー向けに発行される情報(例:一意の clientId および clientSecret)。
  • PID(個人識別子) ユーザーごとに発行される個人識別子です。PIDを使ってSpotnanaサーバーからユーザー情報を取得します。
  • orgId Spotnanaがユーザーの所属組織ごとに割り当てる一意の識別子です。
  • tmcId SpotnanaがTMC(旅行管理会社)ごとに割り当てる一意の識別子です。


対応している認証方法

Spotnanaで利用できる認証方法は以下の通りです。


パスワード認証

パスワード認証を利用する場合、Spotnana UI(OBTのログイン・新規登録画面)がSpotnanaのバックエンドサーバーと連携して認証処理を行います。既存のプロフィールでログインする場合と、新しくプロフィールを作成する場合で、フローが異なります。それぞれの認証フローについて、下記でシーケンス図を用いて解説します。


既存ユーザー

下記のシーケンス図と手順で、Spotnana UIがバックエンドサービスとどのように連携して既存ユーザーを認証するかをご説明します。

図: 既存ユーザー向けパスワード認証のシーケンス図


ステップフロー
既存ユーザーが、OBTまたはSpotnanaモバイルアプリでメールアドレスを使ってログインします。
1
  • Spotnana UIが、ユーザーの認証設定情報を取得するためにSpotnanaサーバーへAPIリクエストを送信します。このリクエストには、ユーザーのログイン情報が含まれます。
  • レスポンスにはユーザーの tmcIdorgId、および authProviderTypeが含まれます。
2
  • Spotnana UIが、clientId・メールアドレス・パスワードを使ってSpotnana IdPへAPIリクエストを送信します。Spotnana IdPが新しいベアラートークンを発行し、Spotnana UIに返します。 clientIdこのステップでユーザー認証が完了します。
  • 3
2の認証が完了した後は、以降のAPIリクエストすべてにベアラートークン、orgId、tmcIdをリクエストヘッダーに含める必要があります。
  • Once the user is authenticated in step 2, all further API requests must contain the bearer token, the orgId, and the tmcId すべてのAPIリクエストでベアラートークンが検証され、Spotnana UIにレスポンスが返されます。
  • The bearer token is validated in all the incoming API requests and the response is sent back to the Spotnana UI.


新規ユーザー

下記のシーケンス図と手順で、Spotnana UIがバックエンドサービスとどのように連携して新規ユーザー(またはパスワードリセットを希望する既存ユーザー)を認証するかをご説明します。


図: 新規ユーザー向けパスワード認証のシーケンス図


ステップ
フロー
新規ユーザーがSpotnana OBTのログイン画面でメールアドレスを入力し、「Next」をクリックします。 Next
1
  • Spotnana UIが、ユーザーの認証設定情報を取得するためにSpotnanaサーバーへAPIリクエストを送信します。このリクエストには、ユーザーのログイン情報が含まれます。
  • レスポンスにはユーザーの tmcIdorgId、および authProviderTypeが含まれます。
1 a

ユーザーが新しいパスワードを入力し、「Next」をクリックします。 Next

2
  • Spotnana UIが、clientId・メールアドレス・新しいパスワードとともにSpotnana IdPへAPIリクエストを送り、ユーザー登録を行います。 clientId、メールアドレス、新しいパスワード
  • 登録完了後、ワンタイムパスワード(OTP)がユーザーのメールアドレス宛てに送信されます。
3
  • ユーザーがSpotnana UIでOTPを入力し、「Verify」をクリックします。 Verify
  • Spotnana UIがSpotnana IdPへOTPの検証とベアラートークン発行をリクエストします。
  • ベアラートークンが発行されSpotnana UIに返されます。これでユーザーはSpotnanaプラットフォームへのアクセスが認証されたことになります。
4
  • 3の認証が完了した後は、以降のAPIリクエストすべてにベアラートークン、orgId、tmcIdをリクエストヘッダーに含める必要があります。 orgId, and the tmcId すべてのAPIリクエストでベアラートークンが検証され、Spotnana UIにレスポンスが返されます。
  • The bearer token is validated in all the incoming API requests and the response is sent back to the Spotnana UI.


IdP認証

Spotnanaでは、GoogleやAzureなどのIdP(アイデンティティプロバイダー)、OpenID ConnectやSAMLプロトコルを使ったカスタムIdPによる認証に対応しています。下記のシーケンス図と手順で、IdP認証の流れをご説明します。

図: IdP認証フローのシーケンス図


ステップフロー
ユーザーがOBTまたはSpotnanaモバイルアプリでメールアドレスを使ってログインします。
1
  • Spotnana UIが、ユーザーの認証設定情報を取得するためにSpotnanaサーバーへAPIリクエストを送信します。このリクエストには、ユーザーのログイン情報が含まれます。
  • レスポンスにはユーザーの tmcIdorgId、および authProviderTypeが含まれます。
2

Spotnana UIがリクエストをSpotnana IdPにリダイレクトします。

3

Spotnana IdPがリクエストをパートナーのIdPにリダイレクトし、IdP認証が開始されます。

補足 :リダイレクトごとに、リクエストが別URLに転送されたことを示す302ステータスコードが返されます。
4

Spotnana IdPとパートナーIdP間で接続が確立され、パートナーIdPによるユーザー認証が行われます。

補足 :この接続時、Spotnana IdPはclientIdとclientSecretをAPIコールでパートナーIdPにフォームURLエンコード形式で送信します。もしIdPサーバーがこの形式に対応していない場合、Spotnanaサーバーがプロキシとなり、パートナーIdPが認識できる形式に変換します。 clientId および clientSecret as a form URL-encoded data using an API call to the Partner IdP. If the IdP servers are unable to process this data format, the Spotnana server can act as a proxy to translate the data into a format recognized by the partner IdP.
5

パートナーIdPがユーザー認証に成功します。

補足 :この後、ユーザープロフィールはベアラートークンによる検証を経る必要があります。
5 a

認証成功後、パートナーIdPからのレスポンスがSpotnana IdPに送信されます。

5 b

Spotnana IdPがユーザープロフィール用の一意なコードを生成し、Spotnana UIに送信します。

6
  • Spotnana UIが、clientIDと5(b)で受け取ったコードを使ってSpotnana IdPへAPIリクエストを送信します。 clientID および5(b)で受け取ったコード
  • Spotnana IdPが新しいベアラートークンを生成し、Spotnana UIに返します。
補足 :ベアラートークンが正常に発行されれば、ユーザーは認証されSpotnanaへアクセス可能となります。
7
  • 6の認証が完了した後は、以降のAPIリクエストすべてにベアラートークン、orgId、tmcIdをリクエストヘッダーに含める必要があります。 orgId, and the tmcId すべてのAPIリクエストでベアラートークンが検証され、Spotnana UIにレスポンスが返されます。
  • The bearer token is validated in all the incoming API requests and the response is sent back to the Spotnana UI.


API認証

SpotnanaのAPIを利用してプラットフォームと連携するパートナー様は、認証エンドポイントを使ってユーザー用のベアラートークンを発行できます。下記のシーケンス図で、API認証の流れを説明します。

図: API認証のシーケンス図


ステップフロー
1

APIユーザーがSpotnanaサーバーのget-auth-token(clientId,clientSecret)エンドポイントにPOSTリクエストを送り、一時的なベアラートークンを発行・取得します。 POST リクエストを get-auth-token(clientId,clientSecret) エンドポイントに送信します。

以下はget-auth-tokenエンドポイントを呼び出す際のcURLリクエスト例です。 get-auth-token エンドポイント:

curl -i -X POST \
https://api.spotnana.com/get-auth-token \
-H 'Content-Type: application/json' \
-d '{
  "clientId": "sample-apiuser@tmcorg.com",
  "clientSecret": "<password>"
}'
補足 :clientIdとclientSecretの値は、Spotnanaから発行された認証情報に置き換えてください。 clientId および clientSecret は、ご自身の認証情報に差し替えてください。 
2
  • SpotnanaサーバーがSpotnana IdPのgetToken(clientId,clientSecret)メソッドを呼び出し、一時的なbearerTokenを発行します。 getToken(clientId,clientSecret) メソッドで bearerToken が生成され、Spotnanaサーバーに返されます。
  • SpotnanaサーバーはこのベアラートークンをJSON形式でAPIユーザーに返します。


APIユーザーはベアラートークンを受け取った後、以降のSpotnana API(例:Trip APIs)へのリクエストすべてで、ヘッダーにベアラートークンを含めて認可を行う必要があります。 Trip APIsなどのAPIリクエスト時に、ヘッダーへベアラートークンを追加してください。 

補足 get-auth-token(clientId, clientSecret) エンドポイントには、5分間で最大100回のAPIコール制限があります。 endpoint has a rate limit of 100 API calls per 5 minutes.


iFrame認証

iFrameや埋め込み型ソリューションでは、パートナーUI内にSpotnana UIを埋め込むことで、ユーザーはパートナーUI経由でSpotnanaを利用します。この場合、パートナーシステムとSpotnanaシステム間でトークンをやり取りして認証を行います。

補足:iFrame認証では、ログインするユーザーを「caller」と呼びます。これは、API/マシンユーザーが他のユーザーのアクセストークンを取得するケースにも対応するためです。API/マシンユーザーがTMC管理者権限でSpotnanaサーバーに接続する場合なども含め、「caller」という表現を使っています。 callerという用語は、自分のプロフィールでログインするユーザーや、API/マシンユーザーが他のユーザーのアクセストークンをリクエストする場合の両方を指します。 caller という表現は、こうした幅広いシナリオをカバーするために使っています。


下記のシーケンス図で、Spotnanaとパートナーサーバー間でのトークン交換による認証フローをご紹介します。

図: トークン交換を使ったiFrame認証のシーケンス図


ステップフロー
caller(ユーザーまたはAPI/マシンユーザー)がパートナーUIでログインします。
1パートナーUIがiFrameを使ってSpotnana UIを表示します。
2Spotnana UIが、トークン取得のためのpost message(type=TOKEN_EXCHANGE_REQUEST)をパートナーUIに送信します。 type=TOKEN_EXCHANGE_REQUESTがリクエストに含まれます。
3

パートナーUIがパートナーサーバーへOAuthトークン取得のAPIリクエストを送り、次の認証処理に進みます。

3 a

パートナーサーバーが、ユーザー認証情報とサブジェクトトークンをパラメータとしてSpotnanaサーバーにリクエストします。SpotnanaサーバーはリクエストがAPI/マシンユーザーによるものか確認します。

3 b
  • Spotnanaサーバーがパートナーサーバーに「caller」のメールアドレス取得をリクエストします。
  • メールアドレスが取得されSpotnanaサーバーに返され、ユーザー識別に使われます。
3 c
  • 1のAPIリクエストに対するSpotnanaサーバーからのレスポンスとして、アクセストークンとリフレッシュトークンがパートナーサーバーに返されます。
  • これらの情報がパートナーUIに渡されます。
4

パートナーUIが、post message(type=TOKEN_EXCHANGE_RESPONSE)でトークンをSpotnana UIに送信します。 type=TOKEN_EXCHANGE_RESPONSE.

5
  • Spotnana UIがSpotnanaサーバーにAPIリクエストを送り、新しいベアラートークンを発行・取得します。
  • Spotnanaサーバーがベアラートークンを発行し、Spotnana UIに返します。
補足 :ベアラートークンが正常に発行されれば、ユーザーは認証されSpotnanaへアクセス可能となります。
6
  • 3の認証が完了した後は、以降のAPIリクエストすべてにベアラートークン、orgId、tmcIdをリクエストヘッダーに含める必要があります。 orgId, and the tmcId すべてのAPIリクエストでベアラートークンが検証され、Spotnana UIにレスポンスが返されます。
  • The bearer token is validated in all the incoming API requests and the response is sent back to the Spotnana UI.


認可コード認証

下記のシーケンス図で、認可コードを使った認証フローをご紹介します。

図: 認可コードを使った認証のシーケンス図


ステップフロー
1

パートナーUIがパートナーサーバーにAPIリクエストを送り、ログインするcaller用の認可コードを取得します。取得した認可コードはパートナーUIに返されます。

2

パートナーUIが、tmcIdとauthCodeをパラメータとして含むカスタムリダイレクトURLでSpotnana UIにリクエストを送信します。 tmcId および authCode がパラメータとして含まれます。

3

Spotnana UIが、v2/auth/token/companies/<tmcId>(authCode)エンドポイントにPOSTリクエストをSpotnanaサーバーへ送信します。 POST APIリクエストをSpotnanaサーバーに送信します。 v2/auth/token/companies/<tmcId>(authCode) エンドポイントです。

3 a
  • Spotnanaサーバーがパートナーサーバーにリクエストを送り、auth codeを使ってユーザーのpidを取得します。 pid をauth codeで取得します。
  • ユーザーの pid が取得され、Spotnanaサーバーに返されます。
3 b

Spotnanaサーバーがアクセストークンとリフレッシュトークンを生成し、Spotnana UIに返します。

4
  • Spotnana UIがアクセストークンとリフレッシュトークンを使い、Spotnanaサーバーにベアラートークン発行リクエストを送信します。
  • ベアラートークンが生成され、Spotnana UIに返されます。
補足 :ベアラートークンが正常に発行されれば、ユーザーは認証されSpotnanaへアクセス可能となります。
5
  • 4の認証が完了した後は、以降のAPIリクエストすべてにベアラートークン、orgId、tmcIdをリクエストヘッダーに含める必要があります。 orgId, and the tmcId すべてのAPIリクエストでベアラートークンが検証され、Spotnana UIにレスポンスが返されます。
  • The bearer token is validated in all the incoming API requests and the response is sent back to the Spotnana UI.


補足 :この認証フローは、TMC管理者が同じメールアドレスで複数ユーザーのログインを許可する場合には利用できません。


マシン間(M2M)認証

M2M認証は、クライアントアプリケーションがユーザーのアクセストークンを生成するために、サードパーティのコールバックURLへアクセスするようなケースに適しています。下記のシーケンス図で、M2M認証の流れをご紹介します。 accessToken をユーザー用に発行します。

図: M2M認証フローのシーケンス図


ステップフロー
認証に利用するすべてのアプリケーションの公開鍵が、SpotnanaサーバーとSpotnana IdP間で同期されます。これらの公開鍵は後ほどアクセストークンの検証に使われます。
1

パートナーサーバーがSpotnana IdPの/oauth2/token(clientId,clientSecret)エンドポイントにAPIリクエストを送り、ベアラートークンを発行します。新しいベアラートークンはパートナーサーバーに返されます。 /oauth2/token(clientId,clientSecret) Spotnana IdPへのリクエストでベアラートークンが返されます。

2
  • パートナーサーバーがサードパーティのコールバックURLにAPIリクエストを送り、ユーザー用のアクセストークンを発行します。
  • 発行されたアクセストークンはSpotnanaサーバーに送信されます。
3
  • Spotnanaサーバーは、事前に同期された公開鍵を使ってアクセストークンの署名を検証します。また、claim_idでパートナーの正当性も確認します。 claim_id でパートナーのIDを検証します。
  • その後、アクセストークンがパートナーサーバーに送られ、ユーザー認証が行われます。




この記事は役に立ちましたか?

それは素晴らしい!

フィードバックありがとうございます

お役に立てず申し訳ございません!

フィードバックありがとうございます

この記事に改善できることがあれば教えてください。

少なくとも一つの理由を選択してください
CAPTCHA認証が必要です。

フィードバックを送信しました

記事の改善におけるご協力ありがとうございます。