> ## 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. # Issue UserInfo Response > This API generates an ID token. This API is supposed to be called from within the implementation of the [userinfo endpoint](https://openid.net/specs/openid-connect-core-1_0.html#UserInfo) of the authorization server in order to generate an ID token. Before calling this API, a valid response from `/auth/userinfo` API must be obtained. Then, call this API with the access token contained in the response and the claims values of the user (subject) associated with the access token. See **OK** written in the description of `/auth/userinfo` API for details. The response from `/auth/userinfo/issue` API has various parameters. Among them, it is `action` parameter that the authorization server implementation should check first because it denotes the next action that the authorization server implementation should take. According to the value of `action`, the service implementation must take the steps described below. ## INTERNAL\_SERVER\_ERROR When the value of `action` is `INTERNAL_SERVER_ERROR`, it means that the request from the authorization server implementation was wrong or that an error occurred in Authlete. In either case, from the viewpoint of the client application, it is an error on the server side. Therefore, the service implementation should generate a response to the client application with HTTP status of "500 Internal Server Error". The parameter `responseContent` returns a string which describes the error in the format of [RFC 6750](https://datatracker.ietf.org/doc/html/rfc6750) (OAuth 2.0 Bearer Token Usage) so the userinfo endpoint implementation can use the value of `responseContent` as the value of`WWW-Authenticate` header. The following is an example response which complies with RFC 6750. Note that OpenID Connect Core 1.0 requires that an error response from userinfo endpoint comply with RFC 6750. See [5.3.3. UserInfo Response](https://openid.net/specs/openid-connect-core-1_0.html#UserInfoError) for details. ``` HTTP/1.1 500 Internal Server Error WWW-Authenticate: {responseContent} Cache-Control: no-store Pragma: no-cache ``` ## BAD\_REQUEST When the value of `action` is `BAD_REQUEST`, it means that the request from the client application does not contain an access token (= the request from the authorization server implementation to Authlete does not contain `token` parameter). The parameter `responseContent` returns a string which describes the error in the format of [RFC 6750](https://datatracker.ietf.org/doc/html/rfc6750) (OAuth 2.0 Bearer Token Usage) so the userinfo endpoint implementation can use the value of `responseContent` as the value of`WWW-Authenticate` header. The following is an example response which complies with RFC 6750. Note that OpenID Connect Core 1.0 requires that an error response from userinfo endpoint comply with RFC 6750. See [5.3.3. UserInfo Response](https://openid.net/specs/openid-connect-core-1_0.html#UserInfoError) for details. ``` HTTP/1.1 400 Bad Request WWW-Authenticate: {responseContent} Cache-Control: no-store Pragma: no-cache ``` ## UNAUTHORIZED When the value of `action` is `UNAUTHORIZED`, it means that the access token does not exist, has expired, or is not associated with any subject (= any user account). The parameter `responseContent` returns a string which describes the error in the format of [RFC 6750](https://datatracker.ietf.org/doc/html/rfc6750) (OAuth 2.0 Bearer Token Usage) so the userinfo endpoint implementation can use the value of `responseContent` as the value of`WWW-Authenticate` header. The following is an example response which complies with RFC 6750. Note that OpenID Connect Core 1.0 requires that an error response from userinfo endpoint comply with RFC 6750. See [5.3.3. UserInfo Response](https://openid.net/specs/openid-connect-core-1_0.html#UserInfoError) for details. ``` HTTP/1.1 401 Unauthorized WWW-Authenticate: {responseContent} Cache-Control: no-store Pragma: no-cache ``` ## FORBIDDEN When the value of `action` is `FORBIDDEN`, it means that the access token does not include the `openid` scope. The parameter `responseContent` returns a string which describes the error in the format of [RFC 6750](https://datatracker.ietf.org/doc/html/rfc6750) (OAuth 2.0 Bearer Token Usage) so the userinfo endpoint implementation can use the value of `responseContent` as the value of`WWW-Authenticate` header. The following is an example response which complies with RFC 6750. Note that OpenID Connect Core 1.0 requires that an error response from userinfo endpoint comply with RFC 6750. See [5.3.3. UserInfo Response](https://openid.net/specs/openid-connect-core-1_0.html#UserInfoError) for details. ``` HTTP/1.1 403 Forbidden WWW-Authenticate: {responseContent} Cache-Control: no-store Pragma: no-cache ``` ## JSON When the value of `action` is `JSON`, it means that the access token which the client application presented is valid and an ID token was successfully generated in the format of JSON. The userinfo endpoint implementation is expected to generate a response to the client application. The content type of the response must be `application/json` and the response body must be an ID token in JSON format. The value of `responseContent` is the ID token in JSON format when `action` is `JSON`, so a response to the client can be built like below. ``` HTTP/1.1 200 OK Cache-Control: no-store Pragma: no-cache Content-Type: application/json;charset=UTF-8 {responseContent} ``` ## JWT When the value of `action` is `JWT`, it means that the access token which the client application presented is valid and an ID token was successfully generated in the format of JWT (JSON Web Token) ([RFC 7519](https://datatracker.ietf.org/doc/html/rfc7519)). The userinfo endpoint implementation is expected to generate a response to the client application. The content type of the response must be `application/jwt` and the response body must be an ID token in JWT format. The value of `responseContent` is the ID token in JSON format when `action` is `JWT`, so a response to the client can be built like below. ``` HTTP/1.1 200 OK Cache-Control: no-store Pragma: no-cache Content-Type: application/jwt {responseContent} ``` ## OpenAPI ````yaml https://spec.speakeasy.com/authlete/sdk-workspace/authlete-api-explorer-with-code-samples post /api/{serviceId}/auth/userinfo/issue openapi: 3.0.3 info: title: Authlete API description: '' version: 3.0.16 license: name: Apache 2.0 url: https://www.apache.org/licenses/LICENSE-2.0.html servers: - description: πŸ‡ΊπŸ‡Έ US Cluster url: https://us.authlete.com - description: πŸ‡―πŸ‡΅ Japan Cluster url: https://jp.authlete.com - description: πŸ‡ͺπŸ‡Ί Europe Cluster url: https://eu.authlete.com - description: πŸ‡§πŸ‡· Brazil Cluster url: https://br.authlete.com security: - bearer: [] tags: - name: Service Management description: >- API endpoints for managing services, including creation, update, and deletion of services. x-tag-expanded: false - name: Client Management description: >- API endpoints for managing OAuth clients, including creation, update, and deletion of clients. x-tag-expanded: false - name: Authorization Endpoint description: API endpoints for implementing OAuth 2.0 Authorization Endpoint. x-tag-expanded: false - name: Pushed Authorization Endpoint description: >- API endpoints for implementing OAuth 2.0 Pushed Authorization Requests (PAR). x-tag-expanded: false - name: Token Endpoint description: API endpoints for implementing OAuth 2.0 Token Endpoint. x-tag-expanded: false - name: Token Operations description: >- API endpoints for various token related operations, including creating, revoking and deleting access_tokens with specified scopes. x-tag-expanded: false - name: Introspection Endpoint description: API endpoints for implementing OAuth 2.0 Introspection Endpoint. x-tag-expanded: false - name: Revocation Endpoint description: API endpoint for implementing OAuth 2.0 Revocation Endpoint. x-tag-expanded: false - name: UserInfo Endpoint description: API endpoints for implementing OpenID Connect UserInfo Endpoint. x-tag-expanded: false - name: JWK Set Endpoint description: API endpoints for to generate JSON Web Key Set (JWKS) for a service. x-tag-expanded: false - name: Discovery Endpoint description: API endpoints for implementing OpenID Connect Discovery. x-tag-expanded: false - name: Configuration Endpoint description: API endpoint for accessing configuration settings for a service. x-tag-expanded: false - name: Dynamic Client Registration description: API endpoints for implementing OAuth 2.0 Dynamic Client Registration. x-tag-expanded: false - name: CIBA description: >- API endpoints for implementing Client-Initiated Backchannel Authentication (CIBA). x-tag-expanded: false - name: Grant Management Endpoint description: >- API endpoint for implementing OAuth 2.0 grants, including grant management actions like updating and revoking grants. x-tag-expanded: false - name: Jose Object description: API endpoints for JOSE objects. x-tag-expanded: false - name: Device Flow description: API endpoints for implementing OAuth 2.0 Device Flow x-tag-expanded: false - name: Federation Endpoint description: API endpoints for implementing OpenID Federation using Authlete. x-tag-expanded: false - name: Verifiable Credential Issuer description: >- API endpoints for implementing and running a Verifiable Credential Issuer (VCI). x-tag-expanded: false - name: Hardware Security Key description: API endpoints for managing hardware security keys (HSK). x-tag-expanded: false - name: Utility Endpoints description: API endpoints for various utility operations. x-tag-expanded: false - name: Native SSO description: API endpoints for Native SSO x-tag-expanded: false paths: /api/{serviceId}/auth/userinfo/issue: post: tags: - UserInfo Endpoint summary: Issue UserInfo Response description: | This API generates an ID token. operationId: auth_userinfo_issue_api parameters: - in: path name: serviceId description: A service ID. schema: type: string required: true requestBody: required: true content: application/json: schema: $ref: '#/components/schemas/userinfo_issue_request' example: token: Ntm9MDb8WXQAevqrBkd84KTTHbYHVQrTjgUZCOWqEUI application/x-www-form-urlencoded: schema: $ref: '#/components/schemas/userinfo_issue_request' responses: '200': description: User info issued successfully content: application/json: schema: $ref: '#/components/schemas/userinfo_issue_response' example: resultCode: A096001 resultMessage: '[A096001] An ID token was generated successfully.' action: JSON responseContent: >- {\"exp\":1511600971,\"sub\":\"john\",\"aud\":[\"26478243745571\"],\"iss\":\"https://authlete.com\",\"iat\":1511514571} '400': $ref: '#/components/responses/400' '401': $ref: '#/components/responses/401' '403': $ref: '#/components/responses/403' '500': $ref: '#/components/responses/500' x-codeSamples: - lang: typescript label: Typescript (SDK) source: |- import { Authlete } from "@authlete/typescript-sdk"; const authlete = new Authlete({ bearer: process.env["AUTHLETE_BEARER"] ?? "", }); async function run() { const result = await authlete.userinfo.issue({ serviceId: "", userinfoIssueRequest: { token: "Ntm9MDb8WXQAevqrBkd84KTTHbYHVQrTjgUZCOWqEUI", }, }); console.log(result); } run(); - lang: ruby label: Ruby (SDK) source: >- require 'authlete_ruby_sdk' Models = ::Authlete::Models s = ::Authlete::Client.new( bearer: '' ) res = s.userinfo.issue_response(service_id: '', userinfo_issue_request: Models::Components::UserinfoIssueRequest.new( token: 'Ntm9MDb8WXQAevqrBkd84KTTHbYHVQrTjgUZCOWqEUI' )) unless res.userinfo_issue_response.nil? # handle response end - lang: go label: Go (SDK) source: "package main\n\nimport(\n\t\"context\"\n\t\"os\"\n\tauthlete \"github.com/authlete/authlete-go-sdk\"\n\t\"github.com/authlete/authlete-go-sdk/models/components\"\n\t\"log\"\n)\n\nfunc main() {\n ctx := context.Background()\n\n s := authlete.New(\n authlete.WithSecurity(os.Getenv(\"AUTHLETE_BEARER\")),\n )\n\n res, err := s.Userinfo.Issue(ctx, \"\", components.UserinfoIssueRequest{\n Token: \"Ntm9MDb8WXQAevqrBkd84KTTHbYHVQrTjgUZCOWqEUI\",\n })\n if err != nil {\n log.Fatal(err)\n }\n if res.UserinfoIssueResponse != nil {\n // handle response\n }\n}" x-code-samples: - lang: shell label: curl source: > curl -v -X POST https://us.authlete.com/api/21653835348762/auth/userinfo/issue \ -H 'Content-Type:application/json' \ -H 'Authorization: Bearer V5a40R6dWvw2gMkCOBFdZcM95q4HC0Z-T0YKD9-nR6F' \ -d '{ "token": "Ntm9MDb8WXQAevqrBkd84KTTHbYHVQrTjgUZCOWqEUI" }' - lang: java label: java source: | AuthleteConfiguration conf = ...; AuthleteApi api = AuthleteApiFactory.create(conf); UserInfoIssueRequest req = new UserInfoIssueRequest(); req.setToken("Ntm9MDb8WXQAevqrBkd84KTTHbYHVQrTjgUZCOWqEUI"); api.userinfoIssue(req); - lang: python source: | conf = ... api = AuthleteApiImpl(conf) req = UserInfoIssueRequest() req.token = 'Ntm9MDb8WXQAevqrBkd84KTTHbYHVQrTjgUZCOWqEUI' api.userinfoIssue(req) components: schemas: userinfo_issue_request: type: object required: - token properties: token: type: string description: > The access token that has been passed to the userinfo endpoint by the client application. In other words, the access token which was contained in the userinfo request. claims: type: string description: > Claims in JSON format. As for the format, see [OpenID Connect Core 1.0, 5.1. Standard Claims](https://openid.net/specs/openid-connect-core-1_0.html#StandardClaims). sub: type: string description: > The value of the `sub` claim. If the value of this request parameter is not empty, it is used as the value of the `sub` claim. Otherwise, the value of the subject associated with the access token is used. claimsForTx: type: string description: | Claim key-value pairs that are used to compute transformed claims. requestSignature: type: string description: | The Signature header value from the request. headers: type: array items: $ref: '#/components/schemas/pair' description: > HTTP headers to be included in processing the signature. If this is a signed request, this must include the Signature and Signature-Input headers, as well as any additional headers covered by the signature. verifiedClaimsForTx: type: array items: type: string description: > Values of verified claims requested indirectly by "transformed claims". x-mint: metadata: description: >- Values of verified claims requested indirectly by "transformed claims". content: > A client application may request "transformed claims". Each of transformed claims uses an existing claim as input. As a result, to compute the value of a transformed claim, the value of the referenced existing claim is needed. This `verifiedClaimsForTx` request parameter has to be used to provide values of existing claims for computation of transformed claims. A response from the `/auth/userinfo` API may include the `requestedVerifiedClaimsForTx` response parameter which is a list of verified claims that are referenced indirectly by transformed claims (cf. `requestedVerifiedClaimsForTx` in `/auth/userinfo` API response). The authorization server implementation should prepare values of the verified claims listed in `requestedVerifiedClaimsForTx` and pass them as the value of this `verifiedClaimsForTx` request parameter. The following is an example of the value of this request parameter. ``` [ "{\"birthdate\":\"1970-01-23\",\"nationalities\":[\"DEU\",\"USA\"]}" ] ``` The reason that this `verifiedClaimsForTx` property is an array is that the `"verified_claims"` property in the claims request parameter of an authorization request can be an array like below. ``` { "transformed_claims": { "nationality_usa": { "claim": "nationalities", "fn": [ [ "eq", "USA" ], "any" ] } }, "userinfo": { "verified_claims": [ { "verification": { "trust_framework": { "value": "gold" } }, "claims": { "::18_or_above": null } }, { "verification": { "trust_framework": { "value": "silver" } }, "claims": { ":nationality_usa": null } } ] } } ``` For the example above, the value of this `verifiedClaimsForTx` property should be an array of size 2 and look like below. The first element is JSON including claims which have been verified under the trust framework `"gold"`, and the second element is JSON including claims which have been verified under the trust framework `"silver"`. ``` [ "{\"birthdate\":\"1970-01-23\"}", "{\"nationalities\":[\"DEU\",\"USA\"]}" ] ``` userinfo_issue_response: type: object properties: resultCode: type: string description: The code which represents the result of the API call. resultMessage: type: string description: A short message which explains the result of the API call. action: type: string enum: - INTERNAL_SERVER_ERROR - BAD_REQUEST - UNAUTHORIZED - FORBIDDEN - JSON - JWT description: >- The next action that the authorization server implementation should take. responseContent: type: string description: > The content that the authorization server implementation can use as the value of `WWW-Authenticate` header on errors. signature: type: string description: | The signature header of the response message. signatureInput: type: string description: | The signature-input header of the response message contentDigest: type: string description: | The content-digest header of the response message pair: type: object properties: key: type: string description: The key part. value: type: string description: The value part. result: type: object properties: resultCode: type: string description: The code which represents the result of the API call. resultMessage: type: string description: A short message which explains the result of the API call. responses: '400': description: '' content: application/json: schema: $ref: '#/components/schemas/result' example: resultCode: A001201 resultMessage: '[A001201] /auth/authorization, TLS must be used.' '401': description: '' content: application/json: schema: $ref: '#/components/schemas/result' example: resultCode: A001202 resultMessage: '[A001202] /auth/authorization, Authorization header is missing.' '403': description: '' content: application/json: schema: $ref: '#/components/schemas/result' example: resultCode: A001215 resultMessage: >- [A001215] /auth/authorization, The client (ID = 26837717140341) is locked. '500': description: '' content: application/json: schema: $ref: '#/components/schemas/result' example: resultCode: A001101 resultMessage: '[A001101] /auth/authorization, Authlete Server error.' securitySchemes: bearer: type: http scheme: bearer bearerFormat: JWT description: > Authenticate every request with a **Service Access Token** or **Organization Token**. Set the token value in the `Authorization: Bearer ` header. **Service Access Token**: Scoped to a single service. Use when automating service-level configuration or runtime flows. **Organization Token**: Scoped to the organization; inherits permissions across services. Use for org-wide automation or when managing multiple services programmatically. Both token types are issued by the Authlete console or provisioning APIs. ````