I'm having a strange issue with my Application Load Balancer (ALB) that authenticates with Okta using OpenID Connect (OIDC). It seems to lose the client secret configured in the Listener rule, leading to a *561 Authentication error*. Every time this occurs, the workaround is to copy the client secret from the Okta app and paste it back into the ALB's "Authenticate using OIDC" option. I've enabled access logging now to investigate further since, previously, I didn't have that set up. I have two other ALBs with the same configuration that have been working fine for over six months. Any thoughts on what might be going wrong?
3 Answers
In our organization, we avoid storing credentials directly in configuration. I recommend using Secrets Manager for OIDC credentials. You can set it up like this: ClientSecret: '{{resolve:secretsmanager:YourSecretNameOrARN:SecretString:clientSecretKey}}'. Also, look into AWS Config and CloudTrail to see if anyone else is changing it without your knowledge.
It sounds like something else might be altering the listener rule without you realizing it. That's definitely a concern.
Yeah, that crossed my mind too. However, it seems unlikely since the other two ALBs are in the same account, region, and VPC, and I'm the only one making changes.
You should check the CloudTrail logs for any modifications made to the listener rule. I've set up quite a few OIDC ALBs, and this issue isn't common. It's possible a partial update is causing the problem, so keep an eye there!
Thanks for the tip! I checked the CloudTrail logs, but couldn't find any modifications aside from my own. No error events either.
I get that, especially since this is a temporary setup. But once you enter the credentials in the listener rule and save it in the console, you can't access it again.