Table of Contents
OAuth 2.0 を実装し、アクセストークンを発行するためには、２つのエンドポイントを実装しなければなりません。一つは、認可エンドポイントであり、もう一方は、トークンエンドポイントです。これらエンドポイントのことを、Oauth 2.0 エンドポイントと呼びます。OAuth2.0 の仕様である RFC6749 では、これら２つのエンドポイントがどのように振る舞うべきか、述べられています。
さらに、OpenID Connect を実装することにより、上記２つのエンドポイントを拡張し、ID トークンを発行することができます。詳細な要件については、OpenID Connect Core 1.0 にて言及されています。
これら仕様書上には、その他のエンドポイントも定義されていますが、実装するかどうかは任意です。OAuth 2.0 及び OpenID Connect を最低限機能させるためには、上記の認可エンドポイントとトークンエンドポイントがあれば十分です。また、RFC 6749 で定義されている認可タイプ（grant type）の一部をサポートしない場合、認可エンドポイントないしはトークンエンドポイントのどちらか一方の実装のみで十分場合があります。例えば、インプリシットフローのみをサポートする場合、認可エンドポイントだけあれば十分です。
Authlete は、OAuth 2.0 等で定義されているエンドポイントを簡単に実装するための機能を Web API として定義し、提供しています。
OAuth 2.0 の仕組みを使う以上、クライアントアプリの管理が必要不可欠です。設計によっては、あるサービスは各エンドユーザーをそれぞれ開発者と定義し、彼らにクライアントアプリの開発・登録を許可することになります。
Authlete は、クライアントアプリを管理（登録、削除、参照、更新）するための Web API を提供しています。直接、それらの Web API を使ってもいいですし、呼ぶためのツールを開発することもできます。もっとも簡単な方法は、Authlete が提供する 開発者コンソール を使うことである。クライアントアプリの開発者は、開発者コンソールを使って、クライアントアプリのメタ情報を管理できます。
ウェブサービスを提供する場合、Web API を通して、クライアントアプリへエンドユーザーの情報を渡すことになります。このような API を、**保護リソースエンドポイント（Protected Resource Endpoint）**と呼びます。
クライアントアプリは、認可サーバーから発行されたアクセストークンをつかって、これら保護リソースエンドポイントにアクセスします。保護リソースエンドポイントでは、クライアントアプリが提示したアクセストークンを検証し、そのクライアントアプリが保護されたリソースへのアクセス権限を持っているのか、確認しなければなりません。
アクセストークンの情報を取得するための API のことをイントロスペクション API といい、2015年にリリースされた RFC 7662 に定義されています。保護リソースエンドポイントの実装には、これら API を使うことになります。
Authlete では、この仕様と異なる、より便利な Web API も提供しています。