Okta OIDC Sign-in redirect URI redirect_uri=http:// instead of https

Grafana Authentication
1

  • What Grafana version and what operating system are you using?
    Grafana v10.3.1 Ubuntu

  • What are you trying to achieve?
    iframe with automated Okta auth0 login

  • How are you trying to achieve it?

With the auth0 Okta and oauth_auto_login = true

  • What happened?

According to the Grafana docs Configure Okta OIDC authentication | Grafana documentation

Step 4:

  • Set the Sign-in redirect URI to **http://**<my_grafana_server_name_or_ip>:<grafana_server_port>/login/okta.Ensure that the sign-in redirect URI is the complete HTTP address that you use to access Grafana via your browser, but with the appended path of /login/okta.For the sign-in redirect URI to be correct, it might be necessary to set the root_url option to [server], for example, if you are serving Grafana behind a proxy.

It’s a http and not a https URL which leads to mixed content and is blocked by the browser.

  • What did you expect to happen?

A httpS callback adress delivered from Grafana

  • Can you copy/paste the configuration(s) that you are having problems with?

It’s built in Grafana

Question: Why is (according to the docs) the Grafana Callback url Sign-in redirect URI and Sign-out redirect URI an HTTP and not a HTTPS (or both)???

This makes no sense to me, do I miss a configuration?

2

Yes, you missed:

it might be necessary to set the root_url option to [server]

3

I don’t think so, the the root_url = config is IMHO for requests to the grafana server to redirect if the browser calls for http or grafana is behind a proxy.

But the callback url for auth0 is served from Grafana to the browser as a http address which is not accepted by the browser.

So the last browser request is then :

http://dev.domain.com:3000/login/okta?code=

This url is served from grafana to the iframe panel in the browser and i can not influence.

Please enlight me how to configure the root_url if I’m wrong.

I tried some possibilities without success, like

enforce_domain = true
root_url = %(protocol)s://%(domain)s:%(http_port)s/

Thanks a bunch in advance

4

Additional question: Is this not a general security vulnarability in Grafana?
I mean the callback contains sensitive data and it’s not encrypted by default.

5

No, you have what you configured

Why you think, why you just don’t try it? Prove me that I’m wrong, but provide reproducible example, pls.

6

What should is say, how to proof? See the Grafana docu with the fixed http://

Steps

To integrate your Okta OIDC provider with Grafana using our Okta OIDC integration, follow these steps:

  1. Follow the OIDC app integration guide to reach the OIDC new application configuration wizard.
  2. Select OIDC - OpenID Connect as the sign-in method and Single-Page Application.
  3. Select Authorization Code and Refresh Token as the grant types.
  4. **Set the Sign-in redirect URI to http://**<my_grafana_server_name_or_ip>:<grafana_server_port>/login/okta.Ensure that the sign-in redirect URI is the complete HTTP address that you use to access Grafana via your browser, but with the appended path of /login/okta.For the sign-in redirect URI to be correct, it might be necessary to set the root_url option to [server], for example, if you are serving Grafana behind a proxy.
  5. Set the Sign-out redirect URI to http://<my_grafana_server_name_or_ip>:<grafana_server_port>/logout.

So http:// and /login/okta is a given, nothing to configure.

And so is then the request from the browser is accordingly in http:// which leads to a mixed block error in Firefox and Chrome. Safari doesn’t care, there it works.

I dont know if it’s a security issue, auth0 requests in http: is strange in general, isn’t it?.

PS: I tried all the configs I can think of. To reproduce simple set up an Okta Auth0 login in Grafana and check the network while the auth process. For regular Grafana login everything works fine, the problem is just within the iframe setup with automatic okta login.

7

This is the output from ChatGP:
Using an HTTP-only callback URI in the context of authentication services like Okta or Auth0 can introduce security risks. HTTP is inherently insecure compared to HTTPS, as data transmitted over HTTP is not encrypted, making it susceptible to interception and manipulation by attackers.

Here are some potential security risks associated with using an HTTP-only callback URI:

  1. Man-in-the-Middle (MitM) Attacks: Attackers can intercept communication between the client and the authentication server, potentially stealing sensitive user information such as access tokens or credentials.

  2. Session Hijacking: Without encryption provided by HTTPS, session tokens or cookies used for authentication can be intercepted, allowing attackers to hijack user sessions and impersonate them.

  3. Data Tampering: Attackers can modify data exchanged between the client and the authentication server, leading to unauthorized access, injection of malicious content, or manipulation of user data.

  4. Phishing Attacks: Attackers can exploit the lack of HTTPS to launch phishing attacks, where they impersonate the authentication server and trick users into providing their credentials or other sensitive information.

To mitigate these risks, it is strongly recommended to use HTTPS for callback URIs and ensure that all communication between the client and the authentication server is encrypted. This can be achieved by configuring your web server to support HTTPS and ensuring that callback URIs use the HTTPS protocol.

Additionally, modern browsers are increasingly enforcing stricter security policies, such as blocking insecure content and warning users when accessing HTTP sites. Using HTTPS not only enhances security but also improves user trust and compliance with industry standards and regulations.