Authentication via Oauth2 auth-provider using Basic Authorization is not working

[sonali-mishra-94]

While using Backstage's battery-included generic oauth2-auth-provider, the authentication fails to complete when using an authentication provider that expects clientId and clientSecret to be passed in Authorization header.

Expected Behavior

Successful authentication via all auth-providers that are based on oauth2.0

Current Behavior

Authentication is failing with the following error:
Authentication Failed, failed to obtain access token : authorization header required

Backstage is using passport-oauth2 strategy which is in turn using node-oauth's getOAuthAccessToken function

This function is making a post request to configured oauth-provider's token endpoint by setting clientId and clientSecret as request params.
(Refer: https://github.com/jaredhanson/passport-oauth2/blob/ee3fe9f17c0f3a90f2d9d938f267e9942b9fba49/lib/strategy.js#L130)

However, the expected method of authentication via most auth-providers is by using client id and secret in Authorization header as follows:
Authorization: Basic b64encodedclientId:clientSecret

This is the reason why authentication fails with the error message of missing authorization header.
However, node-oauth lib is no longer being maintained.

Possible Solution

1. To change passport strategy to one that also uses authorization header in post request to token endpoint.

Steps to Reproduce

1. Configure oauth2 config in app-config by setting the callback url, authorization url, tokenUrl, clientId, clientSecret

auth:
  environment: 
  providers:
    oauth2:
      development:
        clientId: 
        clientSecret: 
        callbackUrl:
        authorizationUrl:
        tokenUrl:

2. Add the provider to sign-in page: https://backstage.io/docs/auth/#adding-the-provider-to-the-sign-in-page
3. Ensure that the provider configured uses Authorization header for authentication via clientID and clientSecret.

Context

To configure authentication via in-house generic oauth2 auth-provider using Backstage.

Existing issues with node-oauth and passport

ciaranj/node-oauth#300
jaredhanson/passport-oauth2#75

[freben]

Hm. The constructor for the strategy here seems to be able to accept a customHeaders field, and that does get passed down and then used by node-oauth. Does that mean that we could encode this ourselves as a custom Authorization header in our own OAuth2AuthProvider?

[Rugvip]

OAuth 2.0 is unfortunately not a strict enough standard to have things work out of the box in a lot of situations.

Is it a well known OAuth provider that you're using @sonali-mishra-94? Perhaps there's a more specific passport provider that we can add instead.

[sonali-mishra-94]

Thanks @Rugvip for taking a look at this!
I work at Grab and I am trying to use an in-house oauth2 provider that is based upon oauth2.0 and is expecting the credentials to be passed in the Authorization header. So the passport strategy for oauth2 should have ideally been perfect.
We are keen on using in-house provider as it is an adopted company wide standard.

I think what @freben has suggested can be tried. I am sure a lot of others might be having the same problem given how many providers make use of auth headers...

[freben]

@sonali-mishra-94 Would you be able to try making a change to the existing Backstage strategy for this, to supply such a header? It would be valuable to be able to see that the end result works for your particular installation.

In such a pull request, we might discuss further how this behavior should be enabled. For example, whether there should be some config parameter that turns it on, or if it should be done through a header generator callback given to the factory for the strategy, or something else.

[sonali-mishra-94]

Raised the following PR to supply custom authorization header:
#8292

[jhaals]

Closing since the PR is merged.

[sonali-mishra-94]

Thanks alot for helping me with my first contribution to Backstage !
Looking forward to more PRs 😁