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 |
|
2 |
|
2の認証が完了した後は、以降のAPIリクエストすべてにベアラートークン、orgId、tmcIdをリクエストヘッダーに含める必要があります。 |
|
新規ユーザー
下記のシーケンス図と手順で、Spotnana UIがバックエンドサービスとどのように連携して新規ユーザー(またはパスワードリセットを希望する既存ユーザー)を認証するかをご説明します。
図: 新規ユーザー向けパスワード認証のシーケンス図
ステップ | フロー |
---|---|
新規ユーザーがSpotnana OBTのログイン画面でメールアドレスを入力し、「Next」をクリックします。 Next。 | |
1 |
|
1 a | ユーザーが新しいパスワードを入力し、「Next」をクリックします。 Next。 |
2 |
|
3 |
|
4 |
|
IdP認証
Spotnanaでは、GoogleやAzureなどのIdP(アイデンティティプロバイダー)、OpenID ConnectやSAMLプロトコルを使ったカスタムIdPによる認証に対応しています。下記のシーケンス図と手順で、IdP認証の流れをご説明します。
図: IdP認証フローのシーケンス図
ステップ | フロー |
---|---|
ユーザーがOBTまたはSpotnanaモバイルアプリでメールアドレスを使ってログインします。 | |
1 |
|
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が認識できる形式に変換します。 |
5 | パートナーIdPがユーザー認証に成功します。 補足 :この後、ユーザープロフィールはベアラートークンによる検証を経る必要があります。 |
5 a | 認証成功後、パートナーIdPからのレスポンスがSpotnana IdPに送信されます。 |
5 b | Spotnana IdPがユーザープロフィール用の一意なコードを生成し、Spotnana UIに送信します。 |
6 |
補足 :ベアラートークンが正常に発行されれば、ユーザーは認証されSpotnanaへアクセス可能となります。 |
7 |
|
API認証
SpotnanaのAPIを利用してプラットフォームと連携するパートナー様は、認証エンドポイントを使ってユーザー用のベアラートークンを発行できます。下記のシーケンス図で、API認証の流れを説明します。
図: API認証のシーケンス図
ステップ | フロー |
---|---|
1 | APIユーザーがSpotnanaサーバーのget-auth-token(clientId,clientSecret)エンドポイントにPOSTリクエストを送り、一時的なベアラートークンを発行・取得します。 POST リクエストを 以下はget-auth-tokenエンドポイントを呼び出す際のcURLリクエスト例です。 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から発行された認証情報に置き換えてください。 |
2 |
|
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を表示します。 |
2 | Spotnana UIが、トークン取得のためのpost message(type=TOKEN_EXCHANGE_REQUEST)をパートナーUIに送信します。 type=TOKEN_EXCHANGE_REQUEST がリクエストに含まれます。 |
3 | パートナーUIがパートナーサーバーへOAuthトークン取得のAPIリクエストを送り、次の認証処理に進みます。 |
3 a | パートナーサーバーが、ユーザー認証情報とサブジェクトトークンをパラメータとしてSpotnanaサーバーにリクエストします。SpotnanaサーバーはリクエストがAPI/マシンユーザーによるものか確認します。 |
3 b |
|
3 c |
|
4 | パートナーUIが、post message(type=TOKEN_EXCHANGE_RESPONSE)でトークンをSpotnana UIに送信します。 |
5 |
補足 :ベアラートークンが正常に発行されれば、ユーザーは認証されSpotnanaへアクセス可能となります。 |
6 |
|
認可コード認証
下記のシーケンス図で、認可コードを使った認証フローをご紹介します。
図: 認可コードを使った認証のシーケンス図
ステップ | フロー |
---|---|
1 | パートナーUIがパートナーサーバーにAPIリクエストを送り、ログインするcaller用の認可コードを取得します。取得した認可コードはパートナーUIに返されます。 |
2 | パートナーUIが、tmcIdとauthCodeをパラメータとして含むカスタムリダイレクトURLでSpotnana UIにリクエストを送信します。 |
3 | Spotnana UIが、v2/auth/token/companies/<tmcId>(authCode)エンドポイントにPOSTリクエストをSpotnanaサーバーへ送信します。 POST APIリクエストをSpotnanaサーバーに送信します。 |
3 a |
|
3 b | Spotnanaサーバーがアクセストークンとリフレッシュトークンを生成し、Spotnana UIに返します。 |
4 |
補足 :ベアラートークンが正常に発行されれば、ユーザーは認証されSpotnanaへアクセス可能となります。 |
5 |
|
補足 :この認証フローは、TMC管理者が同じメールアドレスで複数ユーザーのログインを許可する場合には利用できません。
マシン間(M2M)認証
M2M認証は、クライアントアプリケーションがユーザーのアクセストークンを生成するために、サードパーティのコールバックURLへアクセスするようなケースに適しています。下記のシーケンス図で、M2M認証の流れをご紹介します。 accessToken
をユーザー用に発行します。
図: M2M認証フローのシーケンス図
ステップ | フロー |
---|---|
認証に利用するすべてのアプリケーションの公開鍵が、SpotnanaサーバーとSpotnana IdP間で同期されます。これらの公開鍵は後ほどアクセストークンの検証に使われます。 | |
1 | パートナーサーバーがSpotnana IdPの/oauth2/token(clientId,clientSecret)エンドポイントにAPIリクエストを送り、ベアラートークンを発行します。新しいベアラートークンはパートナーサーバーに返されます。 |
2 |
|
3 |
|
この記事は役に立ちましたか?
それは素晴らしい!
フィードバックありがとうございます
お役に立てず申し訳ございません!
フィードバックありがとうございます
フィードバックを送信しました
記事の改善におけるご協力ありがとうございます。