(57)【要約】【課題】複数のＡＰＩ基盤のＡＰＩを利用するアプリケーションの開発負担、認証認可情報の管理負担を軽減する。【解決手段】ＡＰＩ基盤２のアプリ認証／認可情報とアプリに払い出したＡＰＩ−Ｋｅｙとを関連付けて認証認可情報記憶部１２に記憶し、認証認可情報統合システム１が払い出したＡＰＩ−Ｋｅｙを含むＡＰＩリクエストを受信した場合、リクエスト処理部１３は、認証認可情報記憶部１２を参照し、ＡＰＩリクエストに含まれるＡＰＩ−ＫｅｙをＡＰＩリクエストの転送先のＡＰＩ基盤２のアプリ認証／認可情報に変換したうえで、ＡＰＩ基盤２へ転送する。【選択図】図１
2019139621.tif 000002
【特許請求の範囲】
【請求項１】
複数のＡＰＩ基盤の認証認可情報を管理する認証認可情報統合装置であって、
前記ＡＰＩ基盤から取得した第１の認証認可情報と当該認証認可情報統合装置の生成した第２の認証認可情報とを関連付けて記憶する記憶手段と、
前記第２の認証認可情報を含む処理要求を受信した場合、前記記憶手段を参照し、当該処理要求の第２の認証認可情報を当該処理要求に対応する前記ＡＰＩ基盤の第１の認証認可情報に変換したうえで、当該処理要求を前記ＡＰＩ基盤へ転送する処理手段と、
を有することを特徴とする認証認可情報統合装置。
【請求項２】
前記記憶手段は、前記ＡＰＩ基盤から第１の認証認可情報を取得するための取得情報を記憶し、
前記第２の認証認可情報を含む処理要求を受信した場合、前記記憶手段に前記処理要求に対応する前記ＡＰＩ基盤の第１の認証認可情報が記憶されていない場合又は前記記憶手段に記憶された前記第１の認証認可情報が有効でない場合は、前記取得情報を用いて前記ＡＰＩ基盤から第１の認証認可情報を取得し、取得した前記第１の認証認可情報を前記記憶手段に記録する取得手段を有することを特徴とする請求項１に記載の認証認可情報統合装置。
【請求項３】
複数のＡＰＩ基盤の認証認可情報を管理する認証認可情報統合装置が実行する認証認可情報統合方法であって、
前記認証認可情報統合装置は、前記ＡＰＩ基盤から取得した第１の認証認可情報と当該認証認可情報統合装置の生成した第２の認証認可情報とを関連付けて記憶する記憶手段を備え、
前記第２の認証認可情報を含む処理要求を受信した場合、前記記憶手段を参照し、当該処理要求の第２の認証認可情報を当該処理要求に対応する前記ＡＰＩ基盤の第１の認証認可情報に変換するステップと、
前記第２の認証認可情報を前記ＡＰＩ基盤の第１の認証認可情報に変換した前記処理要求を前記ＡＰＩ基盤へ転送するステップと、
を有することを特徴とする認証認可情報統合方法。
【請求項４】
前記記憶手段は、前記ＡＰＩ基盤から第１の認証認可情報を取得するための取得情報を記憶し、
前記第２の認証認可情報を含む処理要求を受信した場合、前記記憶手段に前記処理要求に対応する前記ＡＰＩ基盤の第１の認証認可情報が記憶されていない場合又は前記記憶手段に記憶された前記第１の認証認可情報が有効でない場合は、前記取得情報を用いて前記ＡＰＩ基盤から第１の認証認可情報を取得し、取得した前記第１の認証認可情報を前記記憶手段に記録するステップを有することを特徴とする請求項３に記載の認証認可情報統合方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、アプリケーションを認証認可する技術に関する。
【背景技術】
【０００２】
ＡＰＩ基盤は、機能や情報をＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ  Ｐｒｏｇｒａｍｉｎｇ  Ｉｎｔｅｒｆａｃｅ）として提供するＡＰＩ提供装置（以下、「イネーブラ」と称する）を束ねて管理する（例えば非特許文献１）。近年、ＡＰＩを活用して開発されるアプリケーション（以下、「アプリ」と称する）が増えている。
【先行技術文献】
【非特許文献】
【０００３】
【非特許文献１】“CA API Gateway”、［online］、日本ＣＡ株式会社、［平成29年12月22日検索］、インターネット〈 URL：https://www.ca.com/jp/products/ca-api-gateway.html〉
【非特許文献２】“Security and Privacy Considerations for the OASIS Security Assertion Markup Language (SAML) V2.0 ”、［online］、OASIS、15 March 2005、［平成29年12月22日検索］、インターネット〈 URL：http://docs.oasis-open.org/security/saml/v2.0/saml-sec-consider-2.0-os.pdf〉
【発明の概要】
【発明が解決しようとする課題】
【０００４】
アプリ開発には、複数のＡＰＩ基盤から提供されるＡＰＩを活用することがある。ＡＰＩ基盤から払い出されるアプリ認証／認可情報（ＡＰＩ−Ｋｅｙ、ＯＡｕｔｈ２．０  Ａｃｃｅｓｓ  ｔｏｋｅｎ等）が多くなると、アプリ認証／認可情報の管理負担や開発コストが増大するという問題があった。
【０００５】
非特許文献２のＳＡＭＬは、異なるネットドメイン間で統一的なユーザ認証（シングルサインオン等）を実現する規格であるが、事前にサービス間で信頼関係を構築する必要があり、上記の問題を解決するものではない。
【０００６】
本発明は、上記に鑑みてなされたものであり、複数のＡＰＩ基盤のＡＰＩを利用するアプリケーションの開発負担、認証認可情報の管理負担を軽減することを目的とする。
【課題を解決するための手段】
【０００７】
第１の本発明に係る認証認可情報統合装置は、複数のＡＰＩ基盤の認証認可情報を管理する認証認可情報統合装置であって、前記ＡＰＩ基盤から取得した第１の認証認可情報と当該認証認可情報統合装置の生成した第２の認証認可情報とを関連付けて記憶する記憶手段と、前記第２の認証認可情報を含む処理要求を受信した場合、前記記憶手段を参照し、当該処理要求の第２の認証認可情報を当該処理要求に対応する前記ＡＰＩ基盤の第１の認証認可情報に変換したうえで、当該処理要求を前記ＡＰＩ基盤へ転送する処理手段と、を有することを特徴とする。
【０００８】
第２の本発明に係る認証認可情報統合方法は、複数のＡＰＩ基盤の認証認可情報を管理する認証認可情報統合装置が実行する認証認可情報統合方法であって、前記認証認可情報統合装置は、前記ＡＰＩ基盤から取得した第１の認証認可情報と当該認証認可情報統合装置の生成した第２の認証認可情報とを関連付けて記憶する記憶手段を備え、前記第２の認証認可情報を含む処理要求を受信した場合、前記記憶手段を参照し、当該処理要求の第２の認証認可情報を当該処理要求に対応する前記ＡＰＩ基盤の第１の認証認可情報に変換するステップと、前記第２の認証認可情報を前記ＡＰＩ基盤の第１の認証認可情報に変換した前記処理要求を前記ＡＰＩ基盤へ転送するステップと、を有することを特徴とする。
【発明の効果】
【０００９】
本発明によれば、複数のＡＰＩ基盤のＡＰＩを利用するアプリケーションの開発負担、認証認可情報の管理負担を軽減することができる。
【図面の簡単な説明】
【００１０】
【図１】本実施形態の認証認可情報統合システムを含む全体構成図である。
【図２】認証認可情報記憶部の記憶するアプリ情報テーブルの例である。
【図３】認証認可情報記憶部の記憶するアプリ認証／認可情報種別テーブルの例である。
【図４】認証認可情報記憶部の記憶するＡＰＩ−Ｋｅｙ変換テーブルの例である。
【図５】認証認可情報記憶部の記憶するＡｃｃｅｓｓ  ｔｏｋｅｎ変換テーブルの例である。
【図６】認証認可情報記憶部の記憶するＯＡｕｔｈ２．０情報テーブルの例である。
【図７】認証認可情報管理部によるアプリ認証／認可情報の事前登録処理の流れを示すフローチャートである。
【図８】認証認可情報管理部によるＡＰＩ−Ｋｅｙの払い出し処理の流れを示すフローチャートである。
【図９】リクエスト処理部によるクライアントサイドアプリに対するＡＰＩ−Ｋｅｙの払い出し処理の流れを示すフローチャートである。
【図１０】リクエスト処理部によるＡＰＩリクエストを受信したときの処理の流れを示すフローチャートである。
【図１１】トークン取得部によるＡＰＩ基盤からＡｃｃｅｓｓ  ｔｏｋｅｎを取得する処理の流れを示すフローチャートである。
【図１２】ＡＰＩクライアントがサーバサイドアプリであり、ＡＰＩ基盤のアプリ認証／認可情報種別がＡＰＩ−Ｋｅｙである場合の処理の流れを示すシーケンス図である。
【図１３】ＡＰＩクライアントがサーバサイドアプリであり、ＡＰＩ基盤のアプリ認証／認可情報種別がＡｃｃｅｓｓ  ｔｏｋｅｎである場合の処理の流れを示すシーケンス図である。
【図１４】ＡＰＩクライアントがクライアントサイドアプリである場合の処理の流れを示すシーケンス図である。
【発明を実施するための形態】
【００１１】
以下、本発明の実施の形態について図面を用いて説明する。
【００１２】
図１は、本実施形態の認証認可情報統合システムを含む全体構成図である。
【００１３】
ＡＰＩ基盤２は、１つ以上のイネーブラ３を管理し、管理するイネーブラ３を利用するためのＡＰＩを提供する。ＡＰＩ基盤２は、イネーブラ３を利用する権利を示すアプリ認証／認可情報を払い出し、アプリ認証／認可情報を含むＡＰＩリクエストを受け付け、アプリ認証／認可情報が有効であれば、ＡＰＩリクエストの処理をイネーブラ３に依頼する。なお、図１では、１つのＡＰＩ基盤２のみを図示しているが、複数のＡＰＩ基盤２が認証認可情報統合システム１に接続される。
【００１４】
イネーブラ３は、例えば音声合成や雑談対話などの機能を提供する装置である。図１では、１つのイネーブラ３のみを図示しているが、１つのＡＰＩ基盤２が複数のイネーブラ３を管理してもよい。
【００１５】
ＡＰＩクライアント４は、ＡＰＩ基盤２の提供するＡＰＩを実行するアプリケーションである。ＡＰＩクライアント４は、複数のＡＰＩ基盤２のＡＰＩを利用してもよい。ＡＰＩクライアント４は、ユーザ毎に配布されてユーザ利用端末５で実行されるクライアントサイドアプリの場合と、サーバで実行されるサーバサイドアプリの場合がある。
【００１６】
ユーザ利用端末５は、ユーザがアプリを利用するために用いる端末であり、例えば、パーソナルコンピュータやタブレット等の携帯端末である。クライアントサイドアプリの場合は、ユーザ利用端末５がアプリを実行する。サーバサイドアプリの場合は、ユーザはユーザ利用端末５を用いてサーバにアクセスし、サーバがアプリを実行する。
【００１７】
アプリ開発者利用端末６は、ＡＰＩクライアント４の開発者が利用する端末である。開発者は、アプリ開発者利用端末６を用いて、アプリ情報、ＡＰＩ基盤２から取得したアプリ認証／認可情報を認証認可情報統合システム１に入力する。
【００１８】
認証認可情報統合システム１は、複数のＡＰＩ基盤２のアプリ認証／認可情報を管理し、ＡＰＩクライアント４に対しては、自身の発行したＡＰＩ−Ｋｅｙ（アプリ認証／認可情報）を払い出す。ＡＰＩクライアント４がクライアントサイドアプリの場合は、ユーザ利用端末５のＡＰＩクライアント４のそれぞれに対してＡＰＩ−Ｋｅｙを払い出す。ＡＰＩクライアント４がサーバサイドアプリの場合は、サーバに対して１つのＡＰＩ−Ｋｅｙを払い出す。ＡＰＩクライアント４は、ＡＰＩ基盤２のＡＰＩを呼び出すときに、認証認可情報統合システム１の払い出したＡＰＩ−Ｋｅｙを含むＡＰＩリクエストを送信する。
【００１９】
認証認可情報統合システム１は、自身が払い出したＡＰＩ−Ｋｅｙを含むＡＰＩリクエストを受信すると、そのＡＰＩ−Ｋｅｙの有効性を確認したうえで、そのＡＰＩ−Ｋｅｙを適切なＡＰＩ基盤２のアプリ認証／認可情報に変換し、変換後のアプリ認証／認可情報を含むＡＰＩリクエストをＡＰＩ基盤２へ転送する。
【００２０】
なお、特に指定しない限り、各装置間は、ＨＴＴＰ（Ｈｙｐｅｒｔｅｘｔ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌ）にて通信する。
【００２１】
次に、認証認可情報統合システム１の構成について説明する。
【００２２】
図１に示す認証認可情報統合システム１は、認証認可情報管理部１１、認証認可情報記憶部１２、リクエスト処理部１３、及びトークン取得部１４を備える。認証認可情報統合システム１が備える各部は、演算処理装置、記憶装置等を備えたコンピュータにより構成して、各部の処理がプログラムによって実行されるものとしてもよい。このプログラムは認証認可情報統合システム１が備える記憶装置に記憶されており、磁気ディスク、光ディスク、半導体メモリ等の記録媒体に記録することも、ネットワークを通して提供することも可能である。
【００２３】
認証認可情報管理部１１は、アプリ開発者利用端末６からアプリ情報とそのアプリが利用する１つ以上のＡＰＩ基盤２から払い出されたアプリ認証／認可情報を受け付け、アプリに対するＡＰＩ−Ｋｅｙを払い出し、アプリ情報、アプリ認証／認可情報、および払い出したＡＰＩ−Ｋｅｙを認証認可情報記憶部１２に記録する。
【００２４】
また、認証認可情報管理部１１は、ＡＰＩクライアント４がクライアントサイドアプリである場合に、ＡＰＩクライアント４からのＡＰＩ−Ｋｅｙの発行要求に対してＡＰＩ−Ｋｅｙを生成し、生成したＡＰＩ−Ｋｅｙを認証認可情報記憶部１２に記録する。
【００２５】
認証認可情報記憶部１２は、アプリの開発者から入力したアプリ情報、ＡＰＩ基盤２のアプリ認証／認可情報、及びアプリに払い出したＡＰＩ−Ｋｅｙを記憶する。図２〜図６に、認証認可情報記憶部１２の記憶するデータの例を示す。
【００２６】
図２は、アプリ情報テーブルの例である。認証認可情報統合システム１のＡＰＩ−Ｋｅｙとアプリ種別（サーバサイドアプリ又はクライアントサイドアプリ）を記憶する。
【００２７】
図３は、アプリ認証／認可情報種別テーブルの例である。ＡＰＩ基盤２のドメインとアプリ認証／認可情報種別を記憶する。
【００２８】
図４は、ＡＰＩ−Ｋｅｙ変換テーブルの例である。認証認可情報統合システム１のＡＰＩ−ＫｅｙとＡＰＩ基盤２のＡＰＩ−Ｋｅｙを記憶する。ＡＰＩ基盤２のアプリ認証／認可情報種別がＡＰＩ−Ｋｅｙの場合に、認証認可情報統合システム１のＡＰＩ−ＫｅｙをＡＰＩ基盤２のＡＰＩ−Ｋｅｙに変換するときに用いる。
【００２９】
図５は、Ａｃｃｅｓｓ  ｔｏｋｅｎ変換テーブルの例である。認証認可情報統合システム１のＡＰＩ−ＫｅｙとＡＰＩ基盤２のＡｃｃｅｓｓ  ｔｏｋｅｎを記憶する。ＡＰＩ基盤２のアプリ認証／認可情報種別がＡｃｃｅｓｓ  ｔｏｋｅｎの場合に、認証認可情報統合システム１のＡＰＩ−ＫｅｙをＡＰＩ基盤２のＡｃｃｅｓｓ  ｔｏｋｅｎに変換するときに用いる。
【００３０】
図６は、ＯＡｕｔｈ２．０情報テーブルの例である。図５のＡｃｃｅｓｓ  ｔｏｋｅｎを取得するために必要な情報を記憶する。
【００３１】
リクエスト処理部１３は、ＡＰＩクライアント４からＡＰＩリクエストを受信し、ＡＰＩリクエストに含まれるＡＰＩ−Ｋｅｙの有効性を確認し、そのＡＰＩ−Ｋｅｙを適切なＡＰＩ基盤２のアプリ認証／認可情報へ変換する。そして、リクエスト処理部１３は、変換後のアプリ認証／認可情報を含むＡＰＩリクエストをＡＰＩ基盤２へ転送し、ＡＰＩ基盤２から受信した処理結果をＡＰＩクライアント４に返却する。
【００３２】
リクエスト処理部１３は、ＡＰＩ−Ｋｅｙ発行要求を受信すると、認証認可情報管理部１１にＡＰＩ−Ｋｅｙの生成を依頼し、生成されたＡＰＩ−Ｋｅｙを返却する。
【００３３】
トークン取得部１４は、ＡＰＩ基盤２のアプリ認証／認可情報種別がＡｃｃｅｓｓ  ｔｏｋｅｎである場合に、ＡＰＩ基盤２からＡｃｃｅｓｓ  ｔｏｋｅｎを取得し、認証認可情報記憶部１２に記録する。
【００３４】
次に、認証認可情報統合システム１の各部の処理について説明する。
【００３５】
まず、認証認可情報管理部１１の処理について説明する。
【００３６】
図７は、認証認可情報管理部１１によるアプリ認証／認可情報の事前登録処理の流れを示すフローチャートである。
【００３７】
認証認可情報管理部１１は、アプリ開発者利用端末６からアプリ情報及びＡＰＩ基盤２のアプリ認証／認可情報を受信すると（ステップＳ１１）、アプリに対してＡＰＩ−Ｋｅｙを払い出し（ステップＳ１２）、ＡＰＩ−Ｋｅｙと受信したアプリ情報及びアプリ認証／認可情報を認証認可情報記憶部１２に記録する（ステップＳ１３）。
【００３８】
なお、アプリ種別がクライアントサイドアプリである場合は、ここで記録するＡＰＩ−Ｋｅｙは仮ＡＰＩ−Ｋｅｙとなる。ユーザ利用端末５のＡＰＩクライアント４からＡＰＩ−Ｋｅｙ発行要求を受信した際に、本ＡＰＩ−Ｋｅｙを発行して記録する。
【００３９】
また、Ａｃｃｅｓｓ  ｔｏｋｅｎテーブルのＡｃｃｅｓｓ  ｔｏｋｅｎ及びその有効期限は、ＡＰＩクライアント４からＡＰＩリクエストを受信したときの認可処理の過程でＡＰＩ基盤２から取得するため、この時点では記録されない。
【００４０】
図８は、認証認可情報管理部１１によるＡＰＩ−Ｋｅｙの払い出し処理の流れを示すフローチャートである。
【００４１】
認証認可情報管理部１１は、ＡＰＩ−Ｋｅｙ発行要求を受信すると（ステップＳ２２１）、ＡＰＩ−Ｋｅｙ発行要求に含まれる情報からＡＰＩ−Ｋｅｙを生成して認証認可情報記憶部１２に記録し（ステップＳ２２２）、生成したＡＰＩ−Ｋｅｙをリクエスト処理部１３に返却する（ステップＳ２２３）。
【００４２】
認証認可情報管理部１１は、ＡＰＩ−Ｋｅｙ発行要求内の、仮ＡＰＩ−Ｋｅｙ、ユーザＩＤとパスワードを基にしたハッシュ値からＡＰＩ−Ｋｅｙを生成する。ここでのユーザＩＤとパスワードは、認証認可情報統合システム１のユーザＩＤとパスワードであり、事前にユーザに通知しておく。
【００４３】
続いて、リクエスト処理部１３の処理について説明する。
【００４４】
図９は、リクエスト処理部１３によるクライアントサイドアプリに対するＡＰＩ−Ｋｅｙの払い出し処理の流れを示すフローチャートである。
【００４５】
リクエスト処理部１３は、クライアントサイドアプリであるＡＰＩクライアント４からＡＰＩ−Ｋｅｙ発行要求を受信すると（ステップＳ２１）、認証認可情報管理部１１にＡＰＩ−Ｋｅｙの生成を依頼し、ＡＰＩ−Ｋｅｙを生成する（ステップＳ２２）。認証認可情報管理部１１は、図８で示した処理を実行し、ＡＰＩ−Ｋｅｙを生成する。
【００４６】
リクエスト処理部１３は、生成したＡＰＩ−ＫｅｙをＡＰＩクライアント４へ返却する（ステップＳ２３）。
【００４７】
図１０は、リクエスト処理部１３によるＡＰＩリクエストを受信したときの処理の流れを示すフローチャートである。
【００４８】
リクエスト処理部１３は、ＡＰＩクライアント４からＡＰＩリクエストを受信すると（ステップＳ３１）、ＡＰＩリクエストに含まれるＡＰＩ−Ｋｅｙが正規のものであるか否か判定する（ステップＳ３２）。
【００４９】
ＡＰＩ−Ｋｅｙが正規のものでない場合（ステップＳ３２のＮｏ）、リクエスト処理部１３は、エラーをＡＰＩクライアント４に返却する（ステップＳ３９）。
【００５０】
ＡＰＩ−Ｋｅｙが正規のものである場合（ステップＳ３２のＹｅｓ）、リクエスト処理部１３は、アプリ認証／認可情報種別テーブルを参照し、ＡＰＩリクエストの転送先のＡＰＩ基盤２のアプリ認証／認可情報種別がＡＰＩ−Ｋｅｙであるか否か判定する（ステップＳ３３）。ＡＰＩリクエストの転送先のＡＰＩ基盤２は、ＡＰＩリクエストに含まれるＵＲＬ（Ｕｎｉｆｏｒｍ  Ｒｅｓｏｕｒｃｅ  Ｌｏｃａｔｏｒ）に基づいて特定できる。
【００５１】
転送先のＡＰＩ基盤２のアプリ認証／認可情報種別がＡＰＩ−Ｋｅｙの場合（ステップＳ３３のＹｅｓ）、ステップＳ３６に進む。
【００５２】
転送先のＡＰＩ基盤２のアプリ認証／認可情報種別がＡｃｃｅｓｓ  ｔｏｋｅｎの場合（ステップＳ３３のＮｏ）、リクエスト処理部１３は、Ａｃｃｅｓｓ  ｔｏｋｅｎ変換テーブルを参照し、ＡＰＩクライアント４について転送先のＡＰＩ基盤２のＡｃｃｅｓｓ  ｔｏｋｅｎが取得されており、有効期限内であるか否か判定する（ステップＳ３４）。
【００５３】
Ａｃｃｅｓｓ  ｔｏｋｅｎが取得されており、有効である場合（ステップＳ３４のＹｅｓ）、ステップＳ３６に進む。
【００５４】
Ａｃｃｅｓｓ  ｔｏｋｅｎが取得されていないか、取得したＡｃｃｅｓｓ  ｔｏｋｅｎの有効期限を過ぎている場合（ステップＳ３４のＮｏ）、リクエスト処理部１３は、トークン取得部１４にＯＡｕｔｈ２．０認可処理を依頼し、Ａｃｃｅｓｓ  ｔｏｋｅｎを取得する（ステップＳ３５）。トークン取得部１４は、後述の図１１で示す処理を実行し、ＡＰＩ基盤２からＡｃｃｅｓｓ  ｔｏｋｅｎを取得する。
【００５５】
リクエスト処理部１３は、ＡＰＩリクエストに含まれるＡＰＩ−Ｋｅｙを転送先のＡＰＩ基盤２のアプリ認証／認可情報に変換し、適切なＡＰＩ基盤２へＡＰＩリクエストを送信する（ステップＳ３６）。リクエスト処理部１３は、転送先のＡＰＩ基盤２のアプリ認証／認可情報がＡＰＩ−Ｋｅｙの場合は、ＡＰＩ−Ｋｅｙ変換テーブルを参照してＡＰＩリクエストを書き換え、転送先のＡＰＩ基盤２のアプリ認証／認可情報がＡｃｃｅｓｓ  ｔｏｋｅｎの場合は、Ａｃｃｅｓｓ  ｔｏｋｅｎ変換テーブルを参照してＡＰＩリクエストを書き換える。
【００５６】
リクエスト処理部１３は、ＡＰＩ基盤２からＡＰＩリクエストの処理結果を受信すると（ステップＳ３７）、その処理結果をＡＰＩクライアント４に返却する（ステップＳ３８）。
【００５７】
続いて、トークン取得部１４の処理について説明する。
【００５８】
図１１は、トークン取得部１４によるＡＰＩ基盤２からＡｃｃｅｓｓ  ｔｏｋｅｎを取得する処理の流れを示すフローチャートである。
【００５９】
トークン取得部１４は、ＯＡｕｔｈ２．０認可処理要求を受信すると（ステップＳ３５１）、ＯＡｕｔｈ２．０情報テーブルから必要な情報を抽出して、ＡＰＩ基盤２に対して認可処理を実施する（ステップＳ３５２）。
【００６０】
ＡＰＩ基盤２からＡｃｃｅｓｓ  ｔｏｋｅｎを取得すると、Ａｃｃｅｓｓ  ｔｏｋｅｎをＡｃｃｅｓｓ  ｔｏｋｅｎ変換テーブルに記録して、リクエスト処理部１３へ通知する（ステップＳ３５３）。
【００６１】
次に、システム全体の処理の流れについて説明する。
【００６２】
図１２は、ＡＰＩクライアント４がサーバサイドアプリであり、ＡＰＩ基盤のアプリ認証／認可情報種別がＡＰＩ−Ｋｅｙである場合の処理の流れを示すシーケンス図である。
【００６３】
ユーザは、ユーザ利用端末５を用いて、サーバサイドアプリにアクセスする（ステップＳ４１）。
【００６４】
サーバサイドアプリは、認証認可情報統合システム１の払い出したＡＰＩ−Ｋｅｙ（ａａａ−ｋｅｙ）を含むＡＰＩリクエストを認証認可情報統合システム１へ送信する（ステップＳ４２）。
【００６５】
認証認可情報統合システム１は、ＡＰＩリクエストを受信すると、ＡＰＩリクエストに含まれるＡＰＩ−Ｋｅｙ（ａａａ−ｋｅｙ）を認証し、ＡＰＩ−Ｋｅｙ（ａａａ−ｋｅｙ）をＡＰＩ基盤ＡのＡＰＩ−Ｋｅｙ（ｋｅｙ１）に変換する（ステップＳ４３）。
【００６６】
認証認可情報統合システム１は、ＡＰＩ基盤ＡのＡＰＩ−Ｋｅｙ（ｋｅｙ１）を含むＡＰＩリクエストをＡＰＩ基盤Ａに送信する（ステップＳ４４）。
【００６７】
ＡＰＩ基盤Ａは、イネーブラＡ−１に処理を依頼し（ステップＳ４５）、処理結果を受信する（ステップＳ４６）。ＡＰＩ基盤とイネーブラが一体の場合もある。
【００６８】
認証認可情報統合システム１は、ＡＰＩ基盤ＡからＡＰＩリクエストのレスポンスを受信し、サーバサイドアプリへ返却する（ステップＳ４７）。
【００６９】
その後、サーバサイドアプリは、ＡＰＩ基盤Ｂに対するＡＰＩリクエストを認証認可情報統合システム１へ送信する（ステップＳ４８）。このＡＰＩリクエストには、認証認可情報統合システム１のＡＰＩ−Ｋｅｙ（ａａａ−ｋｅｙ）が含まれる。
【００７０】
認証認可情報統合システム１は、ＡＰＩリクエストを受信すると、ＡＰＩリクエストに含まれるＡＰＩ−Ｋｅｙ（ａａａ−ｋｅｙ）を認証し、ＡＰＩ−Ｋｅｙ（ａａａ−ｋｅｙ）をＡＰＩ基盤ＢのＡＰＩ−Ｋｅｙ（ｋｅｙ２）に変換し（ステップＳ４９）、ＡＰＩ基盤ＢのＡＰＩ−Ｋｅｙ（ｋｅｙ２）を含むＡＰＩリクエストをＡＰＩ基盤Ｂへ送信する（ステップＳ５０）。
【００７１】
ＡＰＩ基盤Ｂは、イネーブラＢ−１に処理を依頼し（ステップＳ５１）、処理結果を受信する（ステップＳ５２）。
【００７２】
認証認可情報統合システム１は、ＡＰＩ基盤ＢからＡＰＩリクエストのレスポンスを受信し、サーバサイドアプリへ返却する（ステップＳ５３）。
【００７３】
図１３は、ＡＰＩクライアント４がサーバサイドアプリであり、ＡＰＩ基盤のアプリ認証／認可情報種別がＡｃｃｅｓｓ  ｔｏｋｅｎである場合の処理の流れを示すシーケンス図である。図１３では、ＯＡｕｔｈ２．０の認可方式のうち、アプリケーションだけの認証（Ｃｌｉｅｎｔ  Ｃｒｅｄｅｎｔｉａｌｓ  Ｇｒａｎｔｓ）の場合を示す。
【００７４】
図１２の処理と同様に、ユーザがサーバサイドアプリにアクセスすると（ステップＳ４１）、サーバサイドアプリは、認証認可情報統合システム１のＡＰＩ−Ｋｅｙ（ａａａ−ｋｅｙ）を含むＡＰＩリクエストを認証認可情報統合システム１へ送信し（ステップＳ４２）、認証認可情報統合システム１は、ＡＰＩリクエストに含まれるＡＰＩ−Ｋｅｙ（ａａａ−ｋｅｙ）に基づいてサーバサイドアプリを認証する（ステップＳ４３）。
【００７５】
ＡＰＩ基盤ＡのＡｃｃｅｓｓ  ｔｏｋｅｎを取得していないか、有効期限を超えているので、認証認可情報統合システム１は、Ａｃｃｅｓｓ  ｔｏｋｅｎリクエストをＡＰＩ基盤Ａへ送信し（ステップＳ６１）、ＡＰＩ基盤ＡからＡｃｃｅｓｓ  ｔｏｋｅｎを受信する（ステップＳ６２）。受信したＡｃｃｅｓｓ  ｔｏｋｅｎ（ｔｏｋｅｎ１）は、Ａｃｃｅｓｓ  ｔｏｋｅｎ変換テーブルに記録される。
【００７６】
認証認可情報統合システム１は、サーバサイドアプリから受信したＡＰＩリクエストのアプリ認証／認証認可情報をＡｃｃｅｓｓ  ｔｏｋｅｎ（ｔｏｋｅｎ１）に変換し（ステップＳ６３）、Ａｃｃｅｓｓ  ｔｏｋｅｎ（ｔｏｋｅｎ１）を含むＡＰＩリクエストをＡＰＩ基盤Ａに送信する（ステップＳ６４）。
【００７７】
ＡＰＩ基盤Ａは、イネーブラＡ−１に処理を依頼し（ステップＳ６５）、処理結果を受信する（ステップＳ６６）。
【００７８】
認証認可情報統合システム１は、ＡＰＩ基盤ＡからＡＰＩリクエストのレスポンスを受信し、サーバサイドアプリへ返却する（ステップＳ６７）。
【００７９】
ＡＰＩ基盤Ｂに対するＡＰＩリクエストも上記と同様に処理される。ＡＰＩ基盤Ｂのアプリ認証／認可情報種別がＡＰＩ−Ｋｅｙの場合は、図１２で示した処理が行われる。
【００８０】
図１４は、ＡＰＩクライアント４がクライアントサイドアプリである場合の処理の流れを示すシーケンス図である。サーバサイドアプリの場合とは、認証認可情報統合システム１がＡＰＩクライアント４からの要求に応じてＡＰＩ−Ｋｅｙを払い出す点で相違する。
【００８１】
ユーザは、ユーザ利用端末５を操作し、クライアントサイドアプリにユーザＩＤとパスワードを入力する（ステップＳ７１）。
【００８２】
クライアントサイドアプリは、仮ＡＰＩ−Ｋｅｙ、ユーザＩＤとパスワードを基にしたハッシュ値を含むＡＰＩ−Ｋｅｙ発行要求を認証認可情報統合システム１へ送信する（ステップＳ７２）。
【００８３】
認証認可情報統合システム１は、ＡＰＩ−Ｋｅｙ発行要求内の仮ＡＰＩ−Ｋｅｙ、ユーザＩＤとパスワードを基にしたハッシュ値からＡＰＩ−Ｋｅｙを生成し（ステップＳ７３）、生成したＡＰＩ−Ｋｅｙ（ｂｂｂ−ｋｅｙ）をクライアントサイドアプリへ返却する（ステップＳ７４）。生成したＡＰＩ−Ｋｅｙは認証認可情報記憶部１２に記録する。
【００８４】
クライアントサイドアプリは、ＡＰＩ−Ｋｅｙ（ｂｂｂ−ｋｅｙ）を含むＡＰＩリクエストを認証認可情報統合システム１へ送信する（ステップＳ７５）。
【００８５】
ＡＰＩリクエストの処理は、図１２，１３で説明したサーバサイドアプリの場合の処理と同様である。
【００８６】
ＡＰＩリクエストの実行後、認証認可情報統合システム１は、ＡＰＩリクエストのレスポンスをクライアントサイドアプリへ返却する（ステップＳ７６）。
【００８７】
以上説明したように、本実施の形態によれば、ＡＰＩ基盤２のアプリ認証／認可情報とアプリに払い出したＡＰＩ−Ｋｅｙとを関連付けて認証認可情報記憶部１２に記憶し、認証認可情報統合システム１が払い出したＡＰＩ−Ｋｅｙを含むＡＰＩリクエストを受信した場合、リクエスト処理部１３は、認証認可情報記憶部１２を参照し、ＡＰＩリクエストに含まれるＡＰＩ−ＫｅｙをＡＰＩリクエストの転送先のＡＰＩ基盤２のアプリ認証／認可情報に変換したうえで、ＡＰＩ基盤２へ転送することにより、アプリの開発者は、認証認可情報統合システム１の払い出したＡＰＩ−Ｋｅｙのみを用いて複数のＡＰＩ基盤２のＡＰＩを活用するアプリを開発できるので、複数のＡＰＩ基盤２の認証認可処理のそれぞれに対応する開発負担と、複数のＡＰＩ基盤２のアプリ認証／認可情報の管理負担を軽減できる。
【符号の説明】
【００８８】
１…認証認可情報統合システム
１１…認証認可情報管理部
１２…認証認可情報記憶部
１３…リクエスト処理部
１４…トークン取得部
２…ＡＰＩ基盤
３…イネーブラ
４…ＡＰＩクライアント
５…ユーザ利用端末
６…アプリ開発者利用端末
【図１】
2019139621.tif 000003
【図２】
2019139621.tif 000004
【図３】
2019139621.tif 000005
【図４】
2019139621.tif 000006
【図５】
2019139621.tif 000007
【図６】
2019139621.tif 000008
【図７】
2019139621.tif 000009
【図８】
2019139621.tif 000010
【図９】
2019139621.tif 000011
【図１０】
2019139621.tif 000012
【図１１】
2019139621.tif 000013
【図１２】
2019139621.tif 000014
【図１３】
2019139621.tif 000015
【図１４】
2019139621.tif 000016