> ## 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).
# How to Provide User Attributes
> Technical Information about providing user attributes in Authlete in accordance with OpenID Connect.
## Preface
In order to provide user attributes with Authlete, in accordance with OpenID Connect, you have to consider requirements on how identity provider (OpenID Provider; OP) should handle the information and choose the appropriate method.
***
## Methods for providing user attributes
Authlete supports the following three methods for providing user attributes:\
\*EP: Endpoint, RP: Relying Party
| Method | Providing ID Token from Token EP | Providing ID Token from Authorization EP | Providing response from Userinfo EP |
| - | - | - | - |
| Authentication request parameters | response\_type includes "code" and scope does "openid" | response\_type includes "id\_token" | N/A |
| Authlete API | [/auth/authorization/issue](/api-reference/authorization-endpoint/issue-authorization-response) | [/auth/authorization/issue](/api-reference/authorization-endpoint/issue-authorization-response) | [/auth/userinfo/issue](/api-reference/userinfo-endpoint/issue-userinfo-response) |
| How it works | Once receiving an authentication request from an RP, an OP authenticates a user, prepares a request including user attributes and ask Authlete to create a response to the client by sending the request data.Authlete generates both an ID token and a code, responds to the server with the code and stores the token to Authlete's database. The token is to be provided from token EP on receiving the valid code | Once receiving an authentication request from an RP, an OP authenticates a user, prepares a request including user attributes and ask Authlete to create a response to the client by sending the request data.Authlete generates an ID token and responds to the server with the token | Once receiving a request at UserInfo EP from an RP, an OP prepares a request including user attributes and ask Authlete to create a response to the client by sending the request data. Authlete generates UserInfo response including user attributes |
| Does Authlete keep user attributes? | Yes. Authlete encrypts the ID Token which contains user attributes and stores it temporarily. The token data will be kept until cleanup process for expired authorization codes is completed | No. Authlete doesn't keep any user attributes | No. Authlete doesn't keep any user attributes |
| Authorization server's tasks | Implement both authorization EP and Token EP and use Authlete as a backend for each EP | Implement authorization EP and use Authlete as a backend for the EP | Implement Userinfo EP as well as other EPs as described on the left columns, and use Authlete as a backend for the EPs |
*Providing ID Token from Token EP*
*Providing ID Token from Authorization EP*
*Providing response from Userinfo EP*
***
## How to choose the right method
* **Authlete never keeps user attributes for a long time.**
* In the case where Authlete provides the data from authorization EP or UserInfo EP, the data is removed on memory right after responded.
* Even if Authlete provides the data via token EP (i.e. using authorization code), the data is removed after completion of cleanup process for expired authorization codes.
* **If you have some security requirement which prohibits Authlete from keeping user attributes** even if they are encrypted and to be removed in a short period of time, using authorization EP or Userinfo EP is the solution.
* **If sending user attributes to Authlete API is not permitted** due to strict security reasons, consider the following options:
* **Create a UserInfo response by OP itself**. On providing user attributes from UserInfo EP, an OP asks Authlete to analyze an access token and then creates a UserInfo response. The actual sequence is as follows:
* Send the access token to [/auth/userinfo](/api-reference/userinfo-endpoint/process-userinfo-request) API to obtain a list of user claims that the RP wants.
* Create a UserInfo response defined in [the specification](https://openid.net/specs/openid-connect-core-1_0.html#UserInfoResponse) , without using [/auth/userinfo/issue](/api-reference/userinfo-endpoint/issue-userinfo-response) API.
* **Deploying Authlete's on-premises package** so that you can manage the Authlete service.
* The other thing to be considered is operational requirement. If it recommends **not to support implicit flows or Userinfo EP**, the appropriate method would be going to issue authorization code from authorization EP and provide ID Token from token EP.
This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.