Created on 05-11-2026 08:32 AM - edited 05-11-2026 08:36 AM
Hello I need help to setup oidc based login mechanism for NiFi. I came across this article https://docs.cloudera.com/cfm-operator/2.10.0/configure-nifi-cr/topics/cfm-op-configure-nifi-cr-oidc...
but I want to know how to do it for some provider other than Keycloak. I have an internal provider. Also when I read this article I saw some terms like Discovery url and "The clientID and clientSecret fields are provided to NiFi in a Kubernetes secret. Create that secret with the following command:
kubectl create secret generic oidc-client-secret --from-literal=clientID=[***YOUR CLIENT ID***] --from-literal=clientSecret=[***YOUR CLIENT SECRET***]
I am quite new to these terms and wanted to know how to do it in NiFi. Is kubernetes required? I have installed both NiFi 1.23 and NiFi 2.8 on a simple machine.
Created 05-11-2026 01:22 PM
OpenID Connect (OIDC) is a standard login protocol. Instead of NiFi managing its own passwords, it redirects users to your internal Identity Provider (IdP) to log in. Your IdP says "yes, this is a valid user" and sends NiFi a token. NiFi trusts that and lets the user in.
Every OIDC-compatible provider publishes a public JSON file describing itself its endpoints, what it supports, etc. This URL always ends with /.well-known/openid-configuration. NiFi fetches this URL at startup to learn how to talk to your provider. Example:
When you register NiFi as an "application" in your internal IdP, the IdP gives you two credentials a Client ID (like a username for the app) and a Client Secret (like a password for the app). NiFi uses these to prove to the IdP that it is a legitimate registered application.
Is Kubernetes required? The Cloudera/Kubernetes article you read uses kubectl create secret only because it runs NiFi inside Kubernetes, where secrets are managed that way. On a plain machine, you just put the Client ID and Secret directly into nifi.properties as plain text, or use NiFi's built-in encrypt-config tool for security.
Ask your IdP administrator to register a new OIDC client/application with:
Once registered, your IdP admin will give you:
Verify the Discovery URL works by opening it in a browser you should see a JSON document.
OIDC requires NiFi to run over HTTPS. It will not work on plain HTTP. Check your nifi.properties:
If you don't have a keystore/truststore yet, NiFi ships with a tls-toolkit.sh (in the bin/ directory) that can generate them for testing.
Open <nifi-install-dir>/conf/nifi.properties in a text editor and set these properties:
The nifi.security.user.oidc.discovery.url should be set to your provider's issuer endpoint with /.well-known/openid-configuration
The nifi.security.user.oidc.claim.identifying.user value depends on your provider ask your IdP admin which claim carries the unique username. Common values are email, preferred_username, or sub.
NiFi needs to know which user gets admin rights on first startup. Open conf/authorizers.xml and find the <property name="Initial Admin Identity"> line inside the FileAccessPolicyProvider block:
This value must exactly match the identity claim that NiFi will receive from your OIDC provider after login so if your provider sends email, put your email address here. If it sends preferred_username, put your username.
Step 5 Restart NiFi
Watch the logs for errors:
When a user attempts to access NiFi, NiFi will redirect them to your identity provider to log in. After logging in, the provider sends NiFi a response containing the user's credentials, and NiFi authenticates the user.
Navigate to https://<your-nifi-host>:8443/nifi you should be redirected to your internal IdP login page instead of the NiFi login form.
Leaving a plain-text secret in nifi.properties is acceptable for testing but not ideal for production. NiFi ships with an encrypt-config tool
This encrypts sensitive values in the file so they are not readable in plain text. Share your feedback
Happy Hadooping