] Authentication finally failed for null from 10.0.252.44:58696
```
I guess that seems pretty clear - it says there’s no `preferred_username` in the JWT token served (I had explicitly set `http_authenticator.config.subject_key` to it’s default value), and I guess this is the problem.
I presume this should be set with a non-changeable ID for that user (e.g. username, or something similar if username is changeable).
I think the correct value here is probably `cognito:username`. Looking online, apparently a username can be re-used later if freed up. If that is a problem then `sub` should be used which is a UUID and supposedly always unique (i.e. can’t be reused later of course, unlike `cognito:username`).
I’ll give this a try tomorrow.
My OpenID experience is minimal but I have used OAuth many times. Is `preferred_username` a common field? It’s definitely not one of the mandatory ones (I’m not sure if there is a mandatory OpenID Connect claim that fills the “username”/“user id” role?)
_ **Links** _
AWS doc showing some of the JWT fields:
[How can I decode and verify the signature of an Amazon Cognito JSON Web Token?](https://aws.amazon.com/premiumsupport/knowledge-center/decode-verify-cognito-json-token/)
AWS support thread discussing `sub` and `cognito:username`:
[Cognito User Pool field “sub” unique ?](https://forums.aws.amazon.com/thread.jspa?threadID=248829)
---
### Author:  [@mudboyzh](https://forum.opensearch.org/u/mudboyzh)
#### Post date: [July 30, 2021, 8:17am UTC](https://forum.opensearch.org/t/openid-login-loop-openid-aws-cognito/6635/4 "2021-07-30T08:17:44Z")
In my case, the JWT token doesn’t has the key: ‘preferred\_username’.
So I removed the subject key in config.yml and it works for me.
---
### Author:  [@nick\_cloud](https://forum.opensearch.org/u/nick_cloud)
#### Post date: [July 30, 2021, 8:31am UTC](https://forum.opensearch.org/t/openid-login-loop-openid-aws-cognito/6635/5 "2021-07-30T08:31:11Z")
I had evidently misremembered what the docs said, as it does say it’ll use “the subject” (the “sub” claim) if not present - it merely mentions that “preferred\_username” is a common claim that some IdP provides use.
The literal text:
> The key in the JSON payload that stores the user’s name. If not defined, the [subject](https://tools.ietf.org/html/rfc7519#section-4.1.2) registered claim is used. Most IdP providers use the `preferred_username` claim. Optional.
I did try this at one point, but I must have had a different error at the same time. I think this will likely boil down to the mistake I made with the logging config resulting in no useful logging, then various retries with different configs not noticing the real issue.
I’ll try adjusting the config soon.
---
### Author:  [@damo](https://forum.opensearch.org/u/damo)
#### Post date: [September 8, 2021, 7:32pm UTC](https://forum.opensearch.org/t/openid-login-loop-openid-aws-cognito/6635/6 "2021-09-08T19:32:45Z")
FYI, I dont think this was preferred\_username issue? I encountered this error every morning: my elasticsearch cluster goes offline periodically, when everything comes back online, kibana is in exactly the same loop. _subject\_key: preferred\_username_ has always been set in eg, elasticsearch/securityconfig/config.yml.
In this loop state, i’m not seeing any traffic hitting, Keycloak/sso.
In this state, I completely stop my es cluster, same login URL going around.
Restarting kibana (container) fixes issue.
---
### Author:  [@aamarques](https://forum.opensearch.org/u/aamarques)
#### Post date: [October 1, 2021, 10:00am UTC](https://forum.opensearch.org/t/openid-login-loop-openid-aws-cognito/6635/7 "2021-10-01T10:00:12Z")
@nick_cloud did you solve the infinite loop ?
Thanks
---
### Author:  [@nick\_cloud](https://forum.opensearch.org/u/nick_cloud)
#### Post date: [October 1, 2021, 10:42am UTC](https://forum.opensearch.org/t/openid-login-loop-openid-aws-cognito/6635/8 "2021-10-01T10:42:31Z")
Sorry, I genuinely thought I had replied to this thread already and asked for it to be closed.
In an unrelated turn of events I had to migrate from OpenSearch to Elastic-co Elasticsearch. Therefore I never actually resolved this, sorry. I do use OIDC on Elasticsearch and Kibana though, and did not experience these issues - but that’s not to say that perhaps I hadn’t made a dumb configuration mistake on the OpenSearch instance.
I see you have a similar thread for Keycloak - there were some other Keycloak threads previously that I found when I created this post.
Sorry I can’t really help further, as I never actually resolved the issue. What is clear though is that multiple people are having this issue, and OpenSearch has made connecting OIDC simpler than Elasticsearch by using the `.well-known` discovery document instead of configuring multiple properties, and so you’d think this would work more easily - which leads me to suspect that something isn’t quite correct here (or at least isn’t obvious) in OpenSearch.
---
### Author:  [@aamarques](https://forum.opensearch.org/u/aamarques)
#### Post date: [October 1, 2021, 11:12am UTC](https://forum.opensearch.org/t/openid-login-loop-openid-aws-cognito/6635/9 "2021-10-01T11:12:13Z")
Thanks for your answer.
There’s something happening with the OIDC configuration callback using keycloak to authenticate on Google. The google authenticator works very well but the f\*\*\* infinite loop drives me crazy.
I have other posts but no opensearch support on that. Maybe the hard configurations are better than the automatic ones.
Good luck 🙂