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 | /auth/authorization/issue | /auth/userinfo/issue |
| 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 |
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 to obtain a list of user claims that the RP wants.
- Create a UserInfo response defined in the specification , without using /auth/userinfo/issue API.\
- Deploying Authlete’s on-premises package so that you can manage the Authlete service.
- 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:
- 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.