> ## Documentation Index
> Fetch the complete documentation index at: https://developers.authlete.com/llms.txt
> Use this file to discover all available pages before exploring further.

> ## Agent Instructions
> ### Authlete versions
> Authlete 3.0 is the current version. Unless the user says they use another version, answer for Authlete 3.0 using the 3.x documentation.
> Documentation for Authlete 2.x (pages under `/v2/` and `/ja/v2/`) is for the legacy version. Refer to it only when the user is on Authlete 2.x.
>
> ### Authlete architecture
> Authlete is a backend engine for OAuth 2.0 and OpenID Connect processing. End users and client applications do not call it directly; the service provider's authorization server and API server call Authlete's APIs. Authlete handles protocol processing and token, client, and service management, while the service provider owns the OAuth/OIDC endpoints and user authentication.
> See [Architecture](https://developers.authlete.com/get-started/introduction-to-authlete/architecture.md).
>
> ### Concepts
> If the user is new to Authlete, read these pages first:
> - [Request and Response](https://developers.authlete.com/get-started/concepts/request-and-response.md): Core API requests pass the client's request parameters as-is, and responses return `resultCode`, `action`, and `responseContent`.
> - [Action Handling](https://developers.authlete.com/get-started/concepts/action-handling.md): Branch on `action`, never on `resultCode`, and map each action to the HTTP response your server returns.
> - [Two-Step API Calls](https://developers.authlete.com/get-started/concepts/two-step-api-calls.md): Actions such as `INTERACTION` are completed with a second call (`/auth/authorization/issue` or `/auth/authorization/fail`) linked by a `ticket`.
> - [Management API Overview](https://developers.authlete.com/get-started/concepts/overview.md): The Management API configures services, manages clients, and operates issued tokens, separately from the protocol flows handled by the Core API.
> - [API Authentication](https://developers.authlete.com/get-started/concepts/authentication.md): Authlete APIs use bearer tokens: a Service Access Token (one service) or an Organization Token (the whole organization).

# ユーザーが認可しているクライアント一覧の取得

> Authlete は、あるユーザーがどのクライアントを認可しているかを、トークンの存在の有無によって判断し、一覧に含めます。

## 概要

認可サーバーは Authlete の [Get Authorized Applications API](/api-reference/client-management/get-authorized-applications) を用いて、特定のエンドユーザーが認可しているクライアントの一覧を取得できます。

Authlete は、有効期限に関わらず**データベース内に該当トークンのレコードが存在するかどうか**で認可状態を判定します。

## 判定条件と有効期限との関係

アクセストークンまたはリフレッシュトークンのレコードが Authlete のデータベース上に存在する間、それらにひもづくクライアント情報が一覧に返却されます。

アクセストークンまたはリフレッシュトークンの少なくとも一方が有効（期限切れでない）である間は、必ずデータベース内に存在します。また、両方のトークンが有効期限切れとなった場合でも、削除のトリガーとなる以下の処理が実行されるまではデータベースに残存し、一覧に含められます。

* [該当アクセストークンをリクエストに含めて Process Introspection Request API を呼び出した場合](/ja/configuration-reference/endpoints/introspection-response-for-expired-access-token)
* [バッチ削除 (クリーンアップ) 処理が実行された場合](/ja/configuration-reference/tokens-and-claims/authletes-policy-on-sweeping-unused-tokens)
* 明示的な削除 API (e.g. [Delete Client Tokens (by Subject) API](/api-reference/client-management/delete-client-tokens-by-subject)) が呼び出された場合


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.