Authenticating API calls in embedded iframe using JWT authentication

[ulken]

Figured I'd start with a discussion around this, since I'm not entirely sure if it's a bug or working as intended. If the latter, I'm curious what the intended use cases are.

I'm using JWT authentication for embedding a iframe of a Grafana dashboard into our app.

The authentication is done client side, using MSAL against AAD B2C. The access token is passed as a query parameter to the iframe src URL. Then a reverse proxy intercepts the request and converts into a HTTP header.

Everything works great for the dashboard and all publicly available resources, but as soon as a call is done towards API endpoints, the authentication fails. The reason is obvious as no relevant query parameter/header is included in the call. Maybe naively, I expected such calls to be authenticated as the dashboard as a whole is authenticated. I.e. all "nested"/subsequent calls would be authenticated as well.

Right now, I've worked around the issue by installing a service worker which decorates all API calls with the necessary query parameter, but it feels kinda hackish.

So, is this intended behavior or am I missing something? Are you supposed to do the authentication in the proxy? Then I fail to see the value of URL login.

[ulken]

@usmangt care to chip in?

[usmangt]

@grafana/grafana-authnz-team can you please take a look on this one

[Jguer]

Hey @ulken , it was designed with Authentication in the proxy in mind (example: https://github.com/grafana/grafana-iframe-oauth-sample).

We can take a look at this scenario, I can see how it could potentially not work (API access was not considered). Could you share a redacted version of your auth.jwt config to confirm the other config options

[jangaraj]

I would go step further and use SSO OIDC https://github.com/jangaraj/grafana-iframe#i-want-to-have-grafana-in-my-app-as-an-iframe-and-i-would-like-to-have-seamless-login-experience

[ulken]

@jangaraj thank you for chipping in, but we're already using that which worked great for quite some time, until Safari tightened their default cookie policy, which now Firefox has done as well.

We're serving Grafana under a subpath /grafana which makes the browsers treat cookies like third-party — unless the user has actively visited /grafana.

As a workaround, if a custom cookie hadn't been sent, I sent the users to a that subpath with a certain query parameter, which was intercepted by the proxy that set two cookies, on for the root and one for subpath and redirected back. Also, worked great.

But not with Firefox's TCP, and their isolated cookie jars, enabled by default.

[jangaraj]

Yes, my repo mentions that. There is also official solution:

Be aware of Safari (this privacy feature will be implemented also in Chrome/Firefox in 2022). It blocks third party cookies. Recommended solution is Option 1 from https://webkit.org/blog/10218/full-third-party-cookie-blocking-and-more/

[ulken]

Yes, sorry, I know it does. Forgot to mention I read it. I'm on vacation so my answer was a little rushed, via my cellphone.

I haven't had time to look into it, yet, but at a first glance I can't say I quite understand what the setup would look like. Do you have any more in-depth pointers?

[jangaraj]

Correct setup of Cookies for Grafana:

Option 1: OAuth 2.0 Authorization with which the authenticating domain (in your case, the third-party that expects cookies) forwards an authorization token to your website which you consume and use to establish a first-party login session with a server-set Secure and HttpOnly cookie.

[ulken]

Yeah, I've read/followed the link, thank you. That's what I was referring to as quite high level and not entirely obvious how that would work* at a first glance, but maybe I'll figure it out when I get back and look more into it.

* how do I make Grafana (third party) forward a token to my site?

[ulken]

@Jguer thank you for looking into this.

Hey @ulken, it was designed with Authentication in the proxy in mind (example: https://github.com/grafana/grafana-iframe-oauth-sample).

Hum, OK. Maybe I'm missing something, but that wasn't entirely obvious reading the docs. I guess my eyes got stuck on this:

if you want to use pass-through authentication in an app embedding Grafana.

from https://grafana.com/docs/grafana/latest/setup-grafana/configure-security/configure-authentication/jwt/

That's exactly our use case.

We can take a look at this scenario, I can see how it could potentially not work (API access was not considered). Could you share a redacted version of your auth.jwt config to confirm the other config options

That would be great. Requested config:

[auth.jwt]
enabled = true
url_login = true
skip_org_role_sync = true
header_name = X-Forwarded-Access-Token
username_claim = email
email_claim = email
key_file = /etc/grafana/jwk.public.pem
cache_ttl = 60m
auto_sign_up = true

Let me know if you need any other parts.

[ulken]

@Jguer any new insights to share?

[ulken]

@Jguer nothing?

[Jguer]

Hey @ulken, I've not had the proper time to look at this.

Rereading your original issue:

Are you still maintaining the reverse proxy in The access token is passed as a query parameter to the iframe src URL. Then a reverse proxy intercepts the request and converts into a HTTP header.?

The frontend can cache your JWT for a while, allowing the subsequent requests to be authenticated, so the reverse proxy should not be necessary as long as you passed &auth_token=eyJhbxxxxxxxxxxxxx to the iframe url.

cc @kalleep

[ulken]

@Jguer Thank you for the update.

Yes, we still have a reverse proxy (which we use for other stuff as well), but I assume you mean it shouldn't be necessary for this specific use case?

With url_login set, the query parameter should be enough, right? No need to populate the header as well? I remember thinking that when I set it up, but for some reason it didn't work, as I recall it. But that could very well be me confusing things at the time. Seems to work now, removing the header forwarding. Thanks!

The frontend can cache your JWT for a while, allowing the subsequent requests to be authenticated, so the reverse proxy should not be necessary as long as you passed &auth_token=eyJhbxxxxxxxxxxxxx to the iframe url.

Are you saying it should already work like this or are you suggesting a change/fix to be implemented on your end? That would be great. If we could skip the service worker, that would be very welcome on our end.

[ulken]

The frontend can cache your JWT for a while, allowing the subsequent requests to be authenticated, so the reverse proxy should not be necessary as long as you passed &auth_token=eyJhbxxxxxxxxxxxxx to the iframe url.

I'm not gonna put money on it, but I'm pretty sure that the WebSocket/live requests indeed had the auth_token query parameter even without the service worker in place.

[ulken]

OK, guys, I'm gonna have to eat my humble pie and hit the road to Canossa... 🤦

tldr; all is good and PEBKAC.

Not only was the reverse proxy unnecessary, it was the culprit. Removing the header forwarding, I took a step back and inspected outgoing requests. And boom 🤯 , even though the query parameter wasn't present, the header was.

Since the query parameter was empty, the reverse proxy ended up clearing the header...

Sincere apologies for taking up your time and thank you very much for your support along the way!