react-oauth2-pkce

react-oauth2-pkce copied to clipboard

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 with extraAuthParameters, extraTokenParameters ... etc

Basic Example

<AuthProvider authConfig={{
  clientId: 'myClientID',
  authorizationEndpoint: 'https://myAuthProvider.com/auth',
  tokenEndpoint: 'https://myAuthProvider.com/token',
  redirectUri: 'http://localhost:3000/',
  scope: 'someScope openid',
  ---------------
  extraTokenHeaders: {
     Authorization: 'basic eyasd54asd564.56asd645asd654asd.asd56as546d456asd'
     // any other extra header
  }
}}>

Drawbacks

I don't think there will be drawback but benefits

Unresolved questions

No response

Implementation PR

No response

Reference Issues

No response

Hi @videate-miguel I'm not opposed to allowing for extra headers in general, but the example you give is exactly why I'm not sure it's a good idea. Sending a custom authorization header using basic auth to get the token is exactly the problem OAauth2, and the code flow in particular, is intended to solve.

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? What kind of authentication server are you using?

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