Client Should return Headers returned by Identity Provider (IdP)

[MuhammadBilalYar]

Is your feature request related to a problem? Please describe. I have a use case where IdP returns some additional information in the header. I don't see any support in the existing client where I can read these additional information from headers.

Describe the solution you'd like The client should return all these headers returned by Idp

[panva]

Client Should return Headers

Should it, really? Based on?

I have a use case where IdP returns some additional information in the header.

header of ... ? ID Tokens, HTTP responses, ... ? Which requests...

Describe the solution you'd like The client should return all these headers returned by Idp

Please be more specific with the interface you're expecting and add way more substance to your request here.

[MuhammadBilalYar]

Should it, really? Based on?

YES really

header of ... ? ID Tokens, HTTP responses, ... ? Which requests...

YES, the header of HTTP request, suppose userinfo endpoint, where we don't have access to HTTP response headar, Client is only parsing HTTP response body.

[Type] What if we simply add header like below in UserinfoResponse, IntrospectionResponse `headers?: {

};`

What you think?

[panva]

Should it, really? Based on?

YES really

Based on? What is the use case?

[Type] What if we simply add header like below in UserinfoResponse, IntrospectionResponse headers?: { [key: string]: unknown; };

What you think?

I think this is a bad proposal, its mixing two different sources of data.

I think it would be possible to enrich the returned objects with a symbol reachable property that isn't serializable but that can't consistently be done for all methods, neither on the Client nor the Issuer.

Another way would be to expose a method like "getLastResponseObject()" on the library, that however, given the asynchronous nature of the interactions is also not possible.

[panva]

Closing this for now, but i'll keep it in mind for some major API refactor.