I'm following these:
and have created a secret.key like below using https://mkjwk.org/ to match the example in the first URL above:
According to https://auth0.com/blog/navigating-rs256-and-jwks/ because this is an HS type:
"Simply put HS256 must share a secret with any client or API that wants to verify the JWT"
So I naively assumed to use the "k" as the secret to sign the JWT on the server issuing the JWT to use in the password field of any XMPP client (stanza.io and pidgin on the desktop).
What am I misunderstanding? I have confirmed ejabberd starts up correctly with (via ejabberdctl live and loglevel 4):
auth_method: [jwt, ldap]
jwt_key: /opt/ejabberd/conf/secret.jwk
and that I can still authenticate with a password in our Directory Server, but I can't with the JWT. I don't think I'm generating it correctly because I'm just signing it like a normal shared key JWT.
Thanks, Gavin.
I was able to authenticate using jwt token, signed the JWT using "k", placed key set `
"keys": [
{
"kty": "oct",
"use": "sig",
"kid": "",
"k": "",
"alg": "HS256"
}
]
` in secret.jwk. And after passing jabber id & jwt token in strophe.connect() it got connected. this is the backend configuration I had
`auth_method: [jwt, sql]
jwt_key: /usr/local/etc/ejabberd/secret.jwk
default_db: sql
new_sql_schema: true
sql_type: mysql
access_rules:
jwt_only:
deny: admin
allow: all
local:
allow: all
c2s:
deny: blocked
allow: all
announce:
allow: admin
configure:
allow: admin
muc_create:
allow: all
pubsub_createnode:
allow: local
trusted_network:
allow: loopback
jwt_auth_only_rule: jwt_only`