Authlete が他のソリューションと異なる点は、まず、OAuth 2.0 & OpenID Connect サーバーを実装するのに必要な機能を全て Web API として設計・実装した点です。クライアントアプリケーションの登録管理や認可サーバーのメタ情報更新機能だけではなく、認可エンドポイント やトークンエンドポイントなどのエンドポイント群の実装に必要な機能も全て Web API として提供します。

結果、Java、Ruby、PHP、C# など、開発言語やフレームワークを問わず Authlete を利用することができます。OSS ライブラリをご利用いただくことで、数日から数週間で実装することが可能です。

Authlete は、OAuth/OIDC の実装を WebAPI として提供しており、認可エンドポイントやトークンエンドポイントの実装は、お客様の環境下で実装・運用されます。そのため、ユーザー同意の UI や フローを自在に設計することが可能です。

Authlete ユーザーは、OAuth/OIDC サーバーを複数管理することが可能です。

Authlete が提供する管理コンソールも複数の実装インスタンスを管理する前提で作られており、設定の異なるインスタンスをコンソールから簡単に追加・管理することが可能です。

そのため、開発工数の大幅な増加無しに、用途毎に OAuth/OIDC サーバーを用意することができます。「スマートフォンアプリ用と内部サーバー間連携用の OAuth/OIDC サーバーを分ける」、「一般ユーザー用と管理コンソールユーザー用の OAuth/OIDC サーバーを分ける」といった柔軟なシステム設計を行えます。

また、各認可サーバーに紐づくクライアントアプリのメタ情報を管理するためのコンソールも提供しています。

Authlete は認可に特化しており、任意のユーザー認証、ID 管理、API 管理ソリューションと組み合わせてお使いいただけます。すでに利用されている認証・ID 管理基盤をそのまま利用し、最小の開発工数で、OAuth/OIDC を実装することも可能となります。

Authlete を使う場合、Authlete へ手渡す必要があるエンドユーザーの情報は各ユーザーの一意識別子（subject）のみです。Authlete はエンドユーザーの一意識別子を受け取り、トークンやその他の情報と紐づけます。

つまり、エンドユーザーの名前やメールアドレス、認証情報等の個人情報を Authlete に共有する必要はありません。これは、他の認証・認可一体型のソリューションと大きく異なる点の一つです。

なお、ID トークンを生成する際、トークンに埋め込む情報を Authlete の API にお送りいただくことで OpenID Connect で定義されている機能を実現できます。

Authlete は、RFC6749 をはじめ、様々な仕様をサポートしています。OpenID Connect 認定を取得済であり、本番運用可能なソリューションとして業界初の Financial-grade API (FAPI) 認定を受けています。

また、OAuth / OIDC の実装を Web API で提供する、というアーキテクチャの採用により、最新仕様の対応のための負荷を最小化します。例えば、PKCE に対応する場合も、クライアントからのリクエストに関連パラメーターを追加するだけで、お客様の実装への変更は不要です。

以下に、Authlete が現在サポートしている仕様を示します（一部仕様は、Enterprise プランでのみご利用いただけます）。

Authlete API からの応答には、処理結果の結果コードと詳細説明が入っています。

例えば、「[A011308] The host of the redirect URI must be ‘localhost’ when the client’s application type is ‘native’ and the scheme of the redirect URI is ‘http’.」(クライアントのアプリケーションタイプが native でリダイレクト URI のスキームが http の場合、リダイレクト URI のホスト部は localhost でなければならない) といった詳細な内容を返します。

これらメッセージを活用いただくことで、認可サーバー、リソースサーバー、クライアントアプリケーションの開発者は、不具合解消にかかる時間を短縮することができます。

Authlete の「クライアント ID 別名 (Client ID Alias)」機能を利用することにより、各クライアントは、Authlete が自動的に割り当てるクライアント IDとは別に、任意の値のクライアント ID を持つことができます。

この機能は、「すでに既存に利用している認可サーバーおよびクライアントがあり、そこで用いているクライアント ID をそのまま使いつつ、認可サーバーを移行したい」といった際に役立ちます。

詳細につきましては、こちらをご覧ください。

Authlete では、アクセストークンまたは認可コードに任意のプロパティ群 (properties) をひもづける機能を持っています。この機能により、認可サーバーはリソースサーバーに対し、API リクエストの可否判定やリクエストの処理内容に必要な情報を提供しやすくなります。

たとえば送金機能をもつ銀行 API において「ABC商店へ5,000円を送金する」といった機能を実現するとしましょう。これを「ABC商店へ5,000円を送金する」というスコープを作って実現しようとすると、送金先および送金額を組み合わせた数のスコープが必要になってしまいます。これは現実的ではありません。

Authlete のスコープ属性機能を用いると、認可サーバーがクライアントに対して発行するアクセストークンに、上記の情報をプロパティとして直接埋め込む、ないしは、上記情報を管理する DB のレコードにひもづけておくことができます。クライアントからアクセストークンを受け取った銀行 API は、そのトークンにひもづいているプロパティから上記の情報を取得し、送金可否の判断が可能となります。

使い方等、詳細はこちらをご参照ください。

Authlete では、クライアント単位またはスコープ単位でアクセストークンまたはリフレッシュトークンの有効期限を短くすることができます。

特定のスコープを持つアクセストークンおよびリフレッシュトークンのみ、その有効期限を短くする場合、スコープの属性機能を活用します。対象とするスコープの属性に、key に access_token.duration または refresh_token.duration、value に 有効期限（秒）を設定いただくことで、サービスで設定されている有効期限より短くすることができます。詳細につきましては、こちらをご覧ください。

また、クライアント単位での制御も可能です。開発者コンソールに管理者権限でログインいただくことで、設定画面の「拡張タブ」より設定変更できます。

Authlete では、リフレッシュトークンを用いてアクセストークンを再発行する際に、リフレッシュトークンを「継続利用する」か「継続利用しない」かを選択することが可能です。

「継続利用しない」を選択した場合、アクセストークン再発行時に、リフレッシュトークンも再発行され、有効期間も更新されます。この設定の場合、リフレッシュトークンの有効期限内に定期的にアクセスしてくるエンドユーザー（＝リソースオーナー）は再度認証・認可をする必要がなくなり、一方、長期間使わないエンドユーザーは再アクセス時に認証・認可が必要となります。

「継続利用する」を選択した場合、アクセストークン再発行時にリフレッシュトークンを再発行しません。この設定の場合、アクセス頻度によらず、一定期間毎（リフレッシュトークンの有効期限が切れる毎）に、エンドユーザーは再度、認証・認可が必要となります。

Authlete では、PKCE を利用してトークンを発行する場合、リクエストに対して code_challenge_method=S256 を要求できます。この場合、「code_challenge_method=plan」 または、「code_challenge_method を指定していない」リクエストを拒絶できます。

ユーザーとクライアントの組みに対して発行するアクセストークンを 1 つに制限することができます。

Authlete では、各ユーザーが認可したスコープを覚えておく機能があり、Authlete の API を使って、認可済みのスコープの一覧を取得したり、削除することができます。

なお、この機能は Enterprise プランでのみご利用いただけます。

tls_client_auth でクライアント認証する際に、PKI チェーンを Authlete 側でチェックすることができます。

サーバーとクライアントの間の時刻差の許容秒数を指定することができます。

CIBA のバックチャネル認証リクエストが FAPI リクエストだと判定された際、リクエストに binding_message が含まれていることを要求することができます。