backstage: 🐛 Bug Report: Auth Tutorial not working as described

📜 Description

https://github.com/backstage/backstage/blob/master/contrib/docs/tutorials/authenticate-api-requests.md

The above tutorial was followed to implement the service-to-service authentication for Techdocs (and other libraries), and although it’s working with our internal plugins, it’s not working as described when it comes to Techdocs asset or event stream retrieval.

After doing some fiddling around with the node_modules was able to determine that the authorization header gets sent “sometimes” and the cookie is forwarded consistently, however, we still receive a 401 since it can’t find the authorization header.

We attempted to also add the permissions framework as it appears that it’s a requirement of the techdocs item from what was displayed in the code.

Found a similar issue here https://github.com/backstage/backstage/issues/5041, but reports make it seem like the issue was fixed by using the tutorial.

👍 Expected behavior

The authorization header is pulled from the cookie and passed along to the services requiring it.

👎 Actual Behavior with Screenshots

401 errors when trying to retrieve assets

401 from event stream

👟 Reproduction steps

Install backstage
Follow steps in this tutorial: https://github.com/backstage/backstage/blob/master/contrib/docs/tutorials/authenticate-api-requests.md

📃 Provide the context for the Bug.

Our company is having a hard time moving forward with the service-to-service auth structure

🖥️ Your Environment

OS: Linux 5.15.0-58-generic - linux/x64 node: v18.12.1 yarn: 1.22.19 cli: 0.22.1 (installed) backstage: 1.10.1

👀 Have you spent some time to check if this bug has been raised before?

I checked and didn’t find similar issue

🏢 Have you read the Code of Conduct?

I have read the Code of Conduct

Are you willing to submit PR?

Yes I am willing to submit a PR!

About this issue

Original URL
State: closed
Created a year ago
Comments: 17 (7 by maintainers)

Most upvoted comments

Yep, it’s in https://github.com/backstage/backstage/blob/2cc2155bcf823145d6ce910b228eda2d5c1daf50/contrib/docs/tutorials/authenticate-api-requests.md#L98

That could probably be highlighted a bit in the doc.

Erik commented on why the API requests work, they set up the auth header directly.

Pike on Feb 14, 2023

👋 It was a while ago I looked at this but the original implementation still seems to work for me (we’re running Backstage 1.9.1 at the moment).

it’s working with our internal plugins, it’s not working as described when it comes to Techdocs asset or event stream retrieval.

This suggests to me that there is an issue with the cookie. Most client plugins send an authorization header with any API request, and it sounds as if this still works. Techdocs assets (and the Scaffolder event stream) is a bit different, as these asset requests are sent by the browser in response to other protocols, e.g. when Techdocs loads a HTML document the browser tries to load the related javascript/css assets - without Backstage being involved and able to inject the Authorization header. This is the cookie trick in the guide, where the client regularly pings the backend to set a token cookie that gets forwarded on asset and event stream requests.

Could you double-check if this cookie is set on your browser, and maybe specifically on which domain it is set? I’m wondering if there could be some discrepancy there causing this to fail:

When running locally, the client and api can run on different ports/domains. This might cause the cookie to be set on one, but not the other
Is the techdocs / scaffolder api being served on a different domain? E.g. a domain where the cookie is not forwarded?

The cookie is simply called token and should contain a JWT token.

erikxiv on Feb 11, 2023