FusionAuth / fusionauth-issues

FusionAuth issue submission project
https://fusionauth.io
91 stars 12 forks source link

Return the authorization code after the code grant exchange is completed #2685

Open charlesericjs opened 7 months ago

charlesericjs commented 7 months ago

Return the authorization code after the code grant exchange for an access token is completed

Problem

When communicating with FusionAuth through an official FusionAuth SDK, there is no way to implement a "correlation ID" for HTTP requests with responses containing data unless a response actually contains an ID that can be identified with the originating HTTP requests.

The POST /oauth2/token endpoint is one of them in the context of a code grant exchange, meaning that when we exchange the authorization code for an access token, the following response:

{ 
  "access_token": string,
  "expires_in": integer,
  "id_token": string,
  "refresh_token": string,
  "refresh_token_id": UUID,
  "scope": string,
  "token_type": string,
  "userId": string
}

cannot be traced back / correlated to the initial HTTP request since we have no control over the REST client implemented by the FusionAuth SDK.

All the other calls are manageable because they usually return a piece of information that matches the parameters / props sent in the initial HTTP request.

Solution

Make the POST /oauth2/token endpoint return the authorization code in the final response after a code grant exchange is completed.

Additional context

Some business client we serve require this sort of mechanism (ability to correlate a request/reponse) when fetching data.

mooreds commented 1 month ago

Looks like this is not encouraged by the spec but not prohibited:

The client MUST ignore unrecognized value names in the response.

It looks like we already do return values that are not part of the spec, though, such as userId.

mooreds commented 1 month ago

Thanks for the suggestion @charlesericjs . Right now we have a full roadmap, but when we revisit this endpoint, we can review this request.

mooreds commented 1 month ago

If the state value provided on the authorize request was provided on the token, I assume that would be a solution as well?