Service)です。機能を簡単に実現できます。ユーザーの同意の元、サードパーティーアプリがあるサービスのユーザーデータに、アクセスすることを許可する仕組みです。パスワードを共有することなく、情報へのアクセスを許可できます。プロバイダーによって管理されているユーザのアイデンティティ情報を取得することが可能となります。Connect)を実装すること必要となります。その実装は容易ではなく、実装に多くのリソース・時間が必要となります。個人データを管理すること自体、非常に慎重を要する作業です。限られた社内外のエンジニアのリソースを使い、これら課題を解決しつつ、競合よりも先にサービス提供することは、非常に大変です。使うことで、上記課題を解決できます。認可関連仕様の多くをサポートしています。実装することが可能となります。Architecture)を採用しています。アクセスしていただくことになります。アクセスすることはありません。仕様を利用といった事が可能となります。例にとると、下図のようなアーキテクチャになります。実装する場合、4つの構成要素を念頭に置きましょう。認証(Authentication)認証は、「誰か」に関する情報を取り扱います。認証に関する仕様です。実装者は、エンドユーザーのアカウントを管理するとともに、各エンドユーザーを認証します。使う場合、Authleteへ各ユーザーの一意識別子(subject)を手渡す必要があります。ユーザーの一意識別子を受け取り、トークンやその他の情報と紐づけます。エンドユーザーのアカウントを管理せず、また、どのようにユーザーを認証したのか、についても問いません。好きな認証方式をお使いいただけます。「誰が誰に何の権限を与えたのか」に関する情報を取り扱います。認可に関する業界標準の仕様です。プロバイダーに関するメタデータを登録します。登録には、サービス管理者コンソールをご利用いただけます。アクセストークン、リフレッシュトークン、認可コード、認可サーバーおよびクライアントのメタデータなどを管理します。使う場合、これら情報を管理するためのデータベースは不要となります。リソース管理リソース管理は、サードパーティーアプリにアクセスさせるリソース(=データ)を扱います。