Open charlesericjs opened 7 months 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
.
Thanks for the suggestion @charlesericjs . Right now we have a full roadmap, but when we revisit this endpoint, we can review this request.
If the state
value provided on the authorize request was provided on the token, I assume that would be a solution as well?
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: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.