-
Notifications
You must be signed in to change notification settings - Fork 49
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
💡 [Feature] - Ability to send custom headers in the authorization, token requests #144
Comments
Hi @videate-miguel So I'm afraid adding this feature might lead to unsafe usage of the library, and until I find some solid arguments why it would be needed, I don't think we should add it. Do you have some documentation on why you need this header for the token endpoint? A usual workaround for ID-providers not following the OAuth2 spec, is to deploy a small custom auth API, that can add client-secrets etc. to the request before forwarding to the IDP. |
Hi there 👋 I am encountering a challenge in integrating with a client's custom OAuth implementation. While their approach largely adheres to the specifications, a specific token request is failing due to an additional header they have included. I value your library and intended to adopt it as a replacement for our current solution. However, the current inflexibility of the library prevents it from accommodating this exceptional scenario. As I lack the authority to influence or command our clients to strictly follow the specifications, I am constrained to either seek an alternative library or manually handle these requests, I have to adapt to what my clients have otherwise it could result in not getting a deal 😅. I understand the importance of maintaining adherence to the specifications, but I kindly request that the library be enhanced to provide greater flexibility in handling such rare cases. This would enable us to continue utilizing your valuable resource without compromising our ability to adapt to client-specific requirements. |
All right, I don't like this. But since all the defaults are secure, the library should not limit anyone in doing custom/unsafe stuff if they know what they are doing. Will make a pull-request when I get some time. Shouldn't be too long |
Thank you so much, I really appreciated 🥳 |
Stale issue message |
Stale issue message |
Summary
I have a use case where to get the access token I need to send a custom header like
Authorization: basic <token>
, and I cannot do that with the library, it will be nice to have special objects to specify the custom headers just like is already done withextraAuthParameters
,extraTokenParameters
... etcBasic Example
Drawbacks
I don't think there will be drawback but benefits
Unresolved questions
No response
Implementation PR
No response
Reference Issues
No response
The text was updated successfully, but these errors were encountered: