特許 7543154 認証連携サーバ、認証連携方法、認証連携システムおよびプログラム

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】

(24)【登録日】2024-08-23

(45)【発行日】2024-09-02

(54)【発明の名称】認証連携サーバ、認証連携方法、認証連携システムおよびプログラム

(51)【国際特許分類】

   G06F 21/33 20130101AFI20240826BHJP

【ＦＩ】

G06F21/33

【請求項の数】 9

(21)【出願番号】P 2021013917

(22)【出願日】2021-01-29

(65)【公開番号】P2022117303

(43)【公開日】2022-08-10

【審査請求日】2024-01-26

(73)【特許権者】

【識別番号】000001007

【氏名又は名称】キヤノン株式会社

(74)【代理人】

【識別番号】100126240

【弁理士】

【氏名又は名称】阿部 琢磨

(74)【代理人】

【識別番号】100223941

【弁理士】

【氏名又は名称】高橋 佳子

(74)【代理人】

【識別番号】100159695

【弁理士】

【氏名又は名称】中辻 七朗

(74)【代理人】

【識別番号】100172476

【弁理士】

【氏名又は名称】冨田 一史

(74)【代理人】

【識別番号】100126974

【弁理士】

【氏名又は名称】大朋 靖尚

(72)【発明者】

【氏名】久保山 英生

【審査官】石坂 知樹

(56)【参考文献】

【文献】特開２０１８－１３３０２２（ＪＰ，Ａ）

【文献】特開２０１７－０２７４５９（ＪＰ，Ａ）

【文献】特開２０１８－０１８１４３（ＪＰ，Ａ）

(58)【調査した分野】(Int.Cl.，ＤＢ名)

Ｇ０６Ｆ ２１／３３

(57)【特許請求の範囲】

【請求項1】

ユーザ端末に対するサービスを提供するリソースサーバに対し、認証サーバと連携して、前記ユーザ端末の認証をするための機能を提供する認証連携サーバあって、
前記ユーザ端末の認証情報を前記認証サーバへ送信する認証情報送信手段と、
前記認証サーバから、前記ユーザ端末が前記リソースサーバにアクセスするために用いられるトークンを受信するトークン受信手段と、
認証成功したレスポンスを識別するためのコードを発行して前記リソースサーバに送信するコード発行手段と、
前記コードと前記トークンとを対応付けて保存する保存手段と、
前記リソースサーバから前記コードを送信された場合、当該コードに対応する前記トークンを前記リソースサーバへ送信するトークン送信手段と、
を有することを特徴とする認証連携サーバ。

【請求項2】

前記ユーザ端末で前記認証情報を入力するための認証画面を、前記ユーザ端末に提供する処理手段をさらに有することを特徴とする請求項１に記載の認証連携サーバ。

【請求項3】

前記リソースサーバからの認証リクエストを受信するリクエスト受信手段をさらに有し、
前記処理手段は、前記認証リクエストに基づいて前記認証画面を提供し、
前記コード発行手段は、前記認証リクエストの応答として前記コードを前記リソースサーバに送信することを特徴とする請求項２に記載の認証連携サーバ。

【請求項4】

前記コード発行手段は、ＯｐｅｎＩＤ Ｃｏｎｎｅｃｔに準じて前記コードを送信し、前記トークン送信手段は、ＯｐｅｎＩＤ Ｃｏｎｎｅｃｔに準じて前記トークンを送信することを特徴とする請求項１に記載の認証連携サーバ。

【請求項5】

前記トークンには、ＩＤトークンもしくはリフレッシュトークンが含まれることを特徴とする請求項１に記載の認証連携サーバ。

【請求項6】

前記コードに対応するトークンを更新するリクエストを前記認証サーバに送信し、前記認証サーバから更新したトークンを受信するトークン更新手段をさらに有し、
前記トークン送信手段は、前記トークン更新手段によって更新したトークンを前記リソースサーバへ送信することを特徴とする請求項１に記載の認証連携サーバ。

【請求項7】

ユーザ端末に対するサービスを提供するリソースサーバに対し、認証サーバと連携して、前記ユーザ端末の認証をするための機能を提供する認証連携方法あって、
前記ユーザ端末の認証情報を前記認証サーバへ送信する認証情報送信工程と、
前記認証サーバから、前記ユーザ端末が前記リソースサーバにアクセスするために用いられるトークンを受信するトークン受信工程と、
認証成功したレスポンスを識別するためのコードを発行して前記リソースサーバに送信するコード発行工程と、
前記コードと前記トークンとを対応付けて保存する保存工程と、
前記リソースサーバから前記コードを送信された場合、当該コードに対応する前記トークンを前記リソースサーバへ送信するトークン送信工程と、
を有することを特徴とする認証連携方法。

【請求項8】

コンピュータを、
ユーザ端末に対するサービスを提供するリソースサーバに対し、認証サーバと連携して、前記ユーザ端末の認証をするための機能を提供する認証連携サーバあって、
前記ユーザ端末の認証情報を前記認証サーバへ送信する認証情報送信手段と、
前記認証サーバから、前記ユーザ端末が前記リソースサーバにアクセスするために用いられるトークンを受信するトークン受信手段と、
認証成功したレスポンスを識別するためのコードを発行して前記リソースサーバに送信するコード発行手段と、
前記コードと前記トークンとを対応付けて保存する保存手段と、
前記リソースサーバから前記コードを送信された場合、当該コードに対応する前記トークンを前記リソースサーバへ送信するトークン送信手段と、
を有することを特徴とする認証連携サーバとして機能させるためのプログラム。

【請求項9】

認証サーバと、
ユーザ端末に対するサービスを提供するリソースサーバに対して、前記認証サーバと連携して、前記ユーザ端末の認証をするための機能を提供する認証連携サーバあって、
前記ユーザ端末の認証情報を前記認証サーバへ送信する認証情報送信手段と、
前記認証サーバから、前記ユーザ端末が前記リソースサーバにアクセスするために用いられるトークンを受信するトークン受信手段と、
認証成功したレスポンスを識別するためのコードを発行して前記リソースサーバに送信するコード発行手段と、
前記コードと前記トークンとを対応付けて保存する保存手段と、
前記リソースサーバから前記コードを送信された場合、当該コードに対応する前記トークンを前記リソースサーバへ送信するトークン送信手段と、
を有することを特徴とする認証連携サーバとを有することを特徴とする認証連携システム。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、認証サーバと連携して、ユーザ端末の認証をするための機能を提供する認証連携サーバに関する。

【背景技術】

【0002】

近年、サーバ装置が提供する様々な機能を、ユーザが使用するユーザ端末からネットワーク経由で利用可能にするサービスが広く展開されている。サービスを提供するサーバ装置（以下、リソースサーバ）は、多くの場合、リソースサーバが保有するリソースへのアクセスをユーザ端末から要求された際に、ユーザＩＤおよびパスワード等のアカウント情報を用いてユーザを認証することを要求する。

【0003】

しかし、ユーザ認証を行うためにリソースサーバは自身が提供するサービスのほかにユーザの認証を行うためのサーバ（以下、認証サーバ）を用意する必要がある。そこで、ＯｐｅｎＩＤ Ｃｏｎｎｅｃｔ（ＯＩＤＣ）などに代表されるように、あるクラウドサービスのＩＤプロバイダが発行するユーザＩＤを自身のユーザＩＤとして認証連携可能なサービスが提案され既に知られている。これらの認証サービスを利用することでリソースサーバは認証サービスを自身で用意する必要がなくなるため、自身のサービス開発に注力できる。

【0004】

特許文献１に開示されている技術では、認証用情報を外部認証システムに送信し、認証成功の場合、認証情報をアドレス情報と関連付けて保存する。そして、所定の画面における外部サービスの利用終了操作に応じて送信された利用終了要求に対する応答を受信すると、該外部サービスのアドレス情報と関連付けられた第１の認証情報を削除する。

【先行技術文献】

【特許文献】

【0005】

【文献】特開２０１７－１５４４９２号公報

【発明の概要】

【発明が解決しようとする課題】

【0006】

利用する認証サービスが提供するＯｐｅｎＩＤ Ｃｏｎｎｅｃｔなどの認証連携機能や、認証に要するログイン画面などの機能がリソースサーバの要件を満たせば、特許文献１に開示されている技術を用いて、認証サーバを利用すれば良い。しかしながら、リソースサーバの要件によっては、認証サービスの認証連携機能が十分ではない場合がある。本発明は、上記課題を鑑みてなされたものであり、認証サーバと連携して、ユーザ端末の認証に関して必要な機能を提供することを目的とする。

【課題を解決するための手段】

【0007】

本発明は、ユーザ端末に対するサービスを提供するリソースサーバに対し、認証サーバと連携して、前記ユーザ端末の認証をするための機能を提供する認証連携サーバあって、前記ユーザ端末の認証情報を前記認証サーバへ送信する認証情報送信手段と、前記認証サーバから、前記ユーザ端末が前記リソースサーバにアクセスするために用いられるトークンを受信するトークン受信手段と、認証成功したレスポンスを識別するためのコードを発行して前記リソースサーバに送信するコード発行手段と、前記コードと前記トークンとを対応付けて保存する保存手段と、前記リソースサーバから前記コードを送信された場合、当該コードに対応する前記トークンを前記リソースサーバへ送信するトークン送信手段と、を有することを特徴とする

【発明の効果】

【0008】

本発明によれば、認証サーバと連携して、ユーザ端末の認証に関して必要な機能を提供することが出来る。

【図面の簡単な説明】

【0009】

【図1】第一の実施形態における機能構成を表す図である。

【図2】第一の実施形態におけるハードウェア構成図である。

【図3】第一の実施形態における認証連携サーバのシーケンス図である。

【図4】第一の実施形態におけるＩＤトークンに含まれるクレームを表す図である。

【図5】第一の実施形態における保存部が保存するデータの一例を表す図である。

【図6】第二の実施形態における認証連携サーバのシーケンス図である。

【発明を実施するための形態】

【0010】

（実施形態１）
図１は、本発明の実施形態１における認証連携サーバの機能構成を表す図である。同図において、１０１は、本実施形態における認証連携サーバである。１０２は、ＩＤを管理し、認証処理およびトークン発行処理を行う認証サーバである。認証連携サーバ１０１と認証サーバ１０２とは連携して、認証連携システムとして機能する。１０３は、ユーザが利用するユーザ端末である。１０４は、ユーザがユーザ端末を介して利用するサービスを提供するリソースサーバである。リソースサーバ１０４は、トークンを用いてユーザ端末１０３のアクセスを管理する。

【0011】

１０５は、認証連携サーバ１０１がリソースサーバ１０４からの認証リクエストを受信する認証リクエスト受信部である。１０６は、認証連携サーバ１０１がユーザ端末１０３へ認証画面を提供すると共に認証画面で入力されたユーザの認証情報を処理する認証画面処理部である。１０７は、認証画面処理部から渡されるユーザの認証情報を認証サーバ１０２へ送信する認証情報送信部である。

【0012】

１０８は、認証成功時に認証サーバからトークンを受信するトークン受信部である。１０９は、コードを発行し、リソースサーバに送信するコード発行部である。１１０は、コードとトークンを対応づけて保存する保存部である。１１１は、トークンリクエストを受信するトークンリクエスト受信部である。１１２は、トークンリクエストの応答としてトークンを送信するトークン送信部である。１１３は、トークンを更新するトークン更新部である。

【0013】

図２は、本実施形態における認証連携サーバのハードウェア構成を表す図である。同図において、２０１はＣＰＵ（中央処理装置）であり、情報処理装置の制御プログラムを実行する。２０２はＲＯＭであり、制御プログラムなどを格納する。２０３はＲＡＭであり、ＣＰＵ２０１のワークエリアを提供するために用いられる。２０４は装置外のアプリケーションと通信するネットワークＩＦである。２０５はハードディスクなどの記憶装置であり、データを格納する。

【0014】

図３は、本実施形態における認証連携サーバがリソースサーバからのリクエストを受けて認証連携を行うシーケンス図である。

【0015】

まずステップＳ３０１で、ユーザがユーザ端末１０３よりリソースサーバ１０４の所定にアクセスする。例えばユーザ端末のブラウザから所定のＵＲＬを入力するとリソースサーバにアクセスされる。この時、リソースサーバ１０４は、リソースサーバとしてのユーザのログイン状態を確認する。ログイン状態の判断は、例えばリソースサーバのドメインに対応するブラウザのクッキー情報に有効なトークンがあるか否かで判断する。リソースサーバがログイン状態ではないと判断すると、ステップＳ３０２で認証連携サーバ１０１に遷移させる。認証連携サーバ１０１の遷移先としては、認証リクエスト受信部１０５に相当する。本実施形態は認証連携サーバ１０１がＯｐｅｎＩＤ Ｃｏｎｎｅｃｔに則った認証連携機能を提供するとして説明する。この場合、認証リクエスト受信部１０５はＯｐｅｎＩＤ Ｃｏｎｎｅｃｔの仕様に含む認可エンドポイントに相当する。この時、認可エンドポイントに遷移させる時の仕様として、クライアントＩＤ、スコープ、レスポンスタイプ、リダイレクトＵＲＩなどを認可エンドポイントへのリクエストパラメータに付与する。しかしながら、本発明はこれに限るものではなく、リソースサーバから認証連携の遷移先を提供できればどのような仕様であっても良い。

【0016】

次に、ステップＳ３０３で、認証画面処理部１０６が、認証画面をユーザ端末１０３へ提供する。

【0017】

ユーザはステップＳ３０４で、認証画面に対して認証情報を入力する。認証情報は代表的なものはＩＤとパスワードだが、生体認証情報などどのような情報でも良い。

【0018】

ユーザが認証情報を入力すると、ステップＳ３０５でユーザ端末１０３が認証情報を認証連携サーバ１０１へ送信する。認証連携サーバ１０１では、ステップＳ３０６で、認証情報送信部１０７により、認証サーバ１０２へ認証情報を送信する。

【0019】

認証サーバ１０２では、ステップＳ３０７において認証情報を検証し、認証する。認証情報が一致せず認証に失敗すれば失敗レスポンスを認証連携サーバ１０１に返却し、認証連携サーバ１０１はユーザ端末１０３へ失敗レスポンスを返却する。ユーザ端末では認証画面にて認証失敗のエラー表示を行う。一方、ステップＳ３０７にて認証サーバ１０２で認証に成功すると、認証サーバはステップＳ３０８においてトークンを発行し、認証連携サーバ１０１に認証の成功レスポンスと共にトークンを返却する。認証連携サーバ１０１は発行されたトークンをトークン受信部１０８で受信する。本実施形態ではここで発行するトークンをＯｐｅｎＩＤ Ｃｏｎｎｅｃｔ仕様に準ずるＩＤトークンおよびリフレッシュトークンのペアとして説明する。

【0020】

図４はＩＤトークンに含まれるクレームの一例である。ｉｓｓはトークンの発行元であり、認証サーバ１０２を表す。ｓｕｂは認証サーバ１０２で認証したＩＤを一意に特定する値である。ａｕｄはＩＤトークンの発行先のクライアントのＩＤをあらわし、リソースサーバ１０４に相当する。 ｉａｔはＩＤトークンの発行時刻をあらわす。ｅｘｐはＩＤトークンの有効期間をあらわす。ａｕｔｈ＿ｔｉｍｅは認証サーバ１０２が認証した時刻を表す。ｐｒｅｆｅｒｒｅｄ＿ｕｓｅｒｎａｍｅは認証情報のＩＤのユーザ名をあらわす。ｅｍａｉｌは認証情報に紐づくメールアドレスをあらわす。しかしながらこれはトークンの一例にすぎず、本発明はこれに限るものではない。

【0021】

次に、認証連携サーバ１０１がトークンと認証成功レスポンスを受信すると、ステップＳ３０９においてコード発行部１０９がコードを発行する。コードはＵＵＩＤなど、認証成功したレスポンスを識別できる情報であれば、どのようなものでも良い。

【0022】

次に、ステップＳ３１０において、保存部１１０が、コードとトークンを対応づけて保存する。図５は保存部１１０がコードとトークンを対応付けて保存するデータベースの一例である。同図において、５０１はコードである。５０２は、認証サーバ１０２が発行したＩＤトークンである。５０３は、認証サーバ１０２がＩＤトークンと共に発行するリフレッシュトークンである。５０４は、リソースサーバ１０４がステップＳ３０２で認証連携サーバの認可エンドポイントへ遷移させる際に渡すクライアントＩＤである。５０５は、リソースサーバ１０４がステップＳ３０２で認証連携サーバの認可エンドポイントへ遷移させる際に渡すリダイレクトＵＲＩであり、後述するトークンエンドポイントでのリクエストパラメータ検証に用いる。５０６はコードの有効期間であり、この有効期間を超えたコードを使って後述するトークンリクエストが来た場合にはそのリクエストを無効とする。

【0023】

しかし本発明で保存部１１０が保存するデータはこれに限るものではなく、認証連携サーバ１０１が発行するコードと、認証サーバ１０２が発行するトークンとを対応付けて保存すれば本発明は適用できる。

【0024】

本発明は、認証連携サーバ１０１と異なる認証サーバで発行したトークンをステップＳ３０９で受信し、ステップＳ３１０で一度コードに対応付けて保存して後述するステップで利用することに特徴の一つがある。

【0025】

次に、ステップＳ３１１で、コード発行部１０９は、発行したコードをリソースサーバ１０４に送信する。ＯｐｅｎＩＤ Ｃｏｎｎｅｃｔの認可コードフローに則れば、このコードは認可エンドポイントの認可コードになる。ステップＳ３０２での認証連携サーバの認可エンドポイントへの遷移に対して、認可エンドポイントに渡されたリダイレクトＵＲＩへコードをつけて遷移させることに相当する。

【0026】

次に、ステップＳ３１２で、リソースサーバ１０４が認証連携サーバ１０１へトークンをリクエストする。認証連携サーバ１０１はこのトークンリクエストをトークンリクエスト受信部１１１で受信する。ＯｐｅｎＩＤ Ｃｏｎｎｅｃｔ仕様の認可コードフローに則れば、このトークンリクエストは認可エンドポイントで発行した認可コードを使いトークンエンドポイントへＩＤトークンをリクエストすることに相当する。またこの場合、クライアントＩＤに対する認証情報や認可エンドポイントへの遷移時に指定したリダイレクトＵＲＩをリクエストパラメータとして渡す。トークンリクエスト受信部１１１はトークンリクエストのリクエストパラメータを検証する。しかし本発明はＯｐｅｎＩＤ Ｃｏｎｎｅｃｔ仕様に限るものではない。

【0027】

トークンリクエスト受信部１１１がトークンを返却して良いと判断すると、ステップＳ３１３で、トークン送信部１１２がトークンリクエストに含むコードに対応するトークンを保存部１１０から取得し、リソースサーバ１０４へ送信する。

【0028】

リソースサーバ１０４はステップＳ３１４において、認証連携サーバから受け取ったトークンが認証サーバ１０２から発行された適切なトークンであるかを検証する。例えばトークンがＩＤトークンの場合、ＪＷＴ（Ｊｓｏｎ Ｗｅｂ Ｔｏｋｅｎ）形式のトークンであるため、公開鍵を認証サーバ１０２から取得し、トークンの署名を検証するとともに、図４のクレームが適切かを検証する。

【0029】

トークンの検証に成功すれば、リソースサーバ１０４はステップＳ３１５において、リソースサーバとしてのログイン状態を管理し、ユーザ端末１０３にサービスを提供する。

【0030】

以上の構成およびシーケンスにより、本実施形態における認証連携サーバは、認証画面から認証情報を認証サーバに送信し、認証成功時に受信したトークンを、認証連携サーバで発行するコードと対応付けて保存する。

【0031】

これにより、認証サーバ１０２の認証機能やトークン発行機能、トークンの検証に要する公開鍵の提供機能などを利用しながらＯｐｅｎＩＤ Ｃｏｎｎｅｃｔなどの認証連携機能や認証連携サーバ独自の認証画面を提供することができる。

【0032】

（実施形態２）
実施形態１では、ステップＳ３０８で認証サーバが発行したトークンを保存部１１０がコードに対応づけて保存し、リソースサーバからトークンリクエストが来た時点でトークン送信部１１２が保存していたトークンをステップＳ３１３で送信している。したがって、図４で示したＩＤトークンのトークン発行時刻（ｉａｔクレーム）は、厳密にはステップＳ３１３相当の時刻にはならず、ステップＳ３０８相当の時刻になる。また、トークン有効期限（ｅｘｐクレーム）も、ステップＳ３０８相当の時刻から決定される。従って、ステップＳ３０８とステップＳ３１３の時間の異なりでリソースサーバ側の処理や仕様の厳密性に影響が出る場合があり得る。

【0033】

これを解決する本実施形態のフローを図６に示す。なお、実施形態１ではトークンの種類は任意であり、リフレッシュトークンは必須構成ではなかったが、本実施形態においてはリフレッシュトークンが必要となる。

【0034】

図６において、ステップＳ３０１からステップＳ３０７までは実施形態１の図３のフローと同じである。認証サーバ１０２がステップＳ３０７で認証すると、ステップＳ６０１でトークンとリフレッシュトークンを発行する。認証連携サーバ１０１では、ステップＳ３０９で前記実施形態と同様にコード発行部１０９はコードを発行する。

【0035】

次に、ステップＳ６０２で、保存部１１０は、コードとリフレッシュトークンとを対応付けて保存する。この際、認証サーバ１０２がステップＳ６０１で発行したトークンは保存しても良いし、本実施形態では保存せずに捨てても構わない。リフレッシュトークンがコードと共に保存されれば良い。

【0036】

ステップＳ３１１、Ｓ３１２は実施形態１と同様である。トークンリクエスト受信部１１１がトークンリクエストを受信すると、トークン更新部１１３は保存部１１０からコードに対応するリフレッシュトークンを取得し、ステップＳ６０３で認証サーバ１０２に送信してトークン更新をリクエストする。認証サーバ１０２は、ステップＳ６０４で、トークン更新リクエストに応答して更新したトークンを発行する。そしてステップＳ６０５で、トークン送信部１１２は、更新されたトークンをリソースサーバ１０４に送信する。この時、トークン更新に利用したリフレッシュトークンもトークンと一緒にリソースサーバ１０４に提供しても良い。

【0037】

以上のシーケンスにより、本実施形態における認証連携サーバは、ステップＳ３０８で発行されるリフレッシュトークンを用い、ステップＳ３１２のトークンリクエスト受信時にトークンを更新する。これによりトークンに含まれるトークン発行時刻および有効期限はステップＳ６０４で更新された時刻に基づいて設定されるため、認証連携サーバの返すトークンとしてより適切な時刻を設定できる。

【0038】

（実施形態３）
実施形態１、２ではＯｐｅｎＩＤ Ｃｏｎｎｅｃｔの認可コードフローに基づいて説明し、認証サーバ１０２が発行するトークンもＩＤトークンとして説明したが、本発明はこれに限るものではない。例えばトークンが単なるＵＵＩＤなど、ＩＤトークンではないフォーマットのものであっても良い。また、認証リクエスト受信部１０５がステップＳ３０２で遷移するエンドポイントがＯｐｅｎＩＤ Ｃｏｎｎｅｃｔの認可エンドポイントに準じていなくとも良い。また、トークンリクエスト受信部１１１がステップＳ３１２で受信するエンドポイントがＯｐｅｎＩＤ Ｃｏｎｎｅｃｔのトークンエンドポイントに準じていなくとも良い。認証サーバ１０２で発行したトークンを、認証連携サーバ１０１で発行したコードに対応付けて保存し、リソースサーバがそのコードでトークンをリクエストした時にコードに対応付けたトークンを返却しても良い。

【0039】

（実施形態４）
実施形態１から３においては認証連携サーバ１０１、認証サーバ１０２、リソースサーバ１０４の三種のサーバがあるが、これらは別々の装置で構成されるとは限らない。例えば、認証連携サーバ１０１とリソースサーバ１０４とが同じ装置で構成されていて、ステップＳ３０２、Ｓ３１１、Ｓ３１２、Ｓ３１３が同装置内で動作する機能間の通信でも良い。

【0040】

一方、認証連携サーバ１０１と認証サーバ１０２の機能を同じ装置で構成するのであれば、本来はステップＳ３０８のトークン発行をステップＳ３０７の認証直後に行わず、ステップＳ３１２の直後に行えば保存部１１０は不要になる。その場合、認証連携サーバ１０１、認証サーバ１０２のソフトウェアを同一装置内で動かす構成にした方が望ましい。

【0041】

（その他の実施形態）
本発明は、上述の実施形態の１以上の機能を実現するプログラムを、ネットワーク又は記憶媒体を介してシステム又は装置に供給し、そのシステム又は装置のコンピュータにおける１つ以上のプロセッサがプログラムを読出し実行する処理でも実現可能である。また、１以上の機能を実現する回路（例えば、ＡＳＩＣ）によっても実現可能である。

【符号の説明】

【0042】

１０１ 認証連携サーバ
１０２ 認証サーバ
１０３ ユーザ端末
１０４ リソースサーバ
１０５ 認証リクエスト受信部
１０６ 認証画面処理部
１０７ 認証情報送信部
１０８ トークン受信部
１０９ コード発行部
１１０ 保存部
１１１ トークンリクエスト受信部
１１２ トークン送信部
１１３ トークン更新部

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】