DEV Community

Discussion on: Apache Pulsar OAuth2 dev setup with Docker and KeyCloak

Collapse
 
fjod profile image
Michael

This will sound stupid, but can I use auth0.com/ instead of KeyCloak ?

Collapse
 
_hs_ profile image
HS

Should be possible. OAuth2 is the protocol used in the end so any provider would work. Just grab the correct parameters for issuer URI and such and you're good to go.

Collapse
 
fjod profile image
Michael

Thank you. Can you provide some more guidance on this topic? There are only 2 docs about pulsar ouath2, this article and pulsar.apache.org/docs/en/next/sec... . So I have jwt token in my client and return it to broker on demand. I need to authenticate broker on the same ouath2 server, so it can validate client's token? Also I must include role field in client's jwt so broker can grant some permissions? I dont understand the role of broker's authentication on oauth server.

Thread Thread
 
_hs_ profile image
HS

This is a bit different approach than that. Think of it as Facebook or Google apps. You create a client app on the OAuth2 side like you would for an app that uses Facebook to login. So you have client ID and a secret with other necessary info like provider URL and such. That you store either in file like I made in this example or in other forms if you have more experience with service registries and such. That file is NOT a JWT. That is something like a username and a pass for applications to login to auth service. After setting it up with Pulsar including public key and such Pulsar brokers will contact the auth server for JWT for internal usages. From the consumer perspective you need yet another OAuth2 app or for playing around use the same one as for Pulsar. What happens now is that your app goes to OAuth2 server and asks for a JWT then sends that JWT when communicating with Pulsar brokers. Public key is used to verify JWT because Pulsar doesn't support yet JWKS. If you don't know much about JWKS think of it as providing a way for services to verify token locally by downloading those public keys on startup instead of having them in files. So your consumers will authenticate with auth0 and use JWT given by auth0 to login to Pulsar. Then Pulsar verifies it by public key so it knows it's valid JWT but also gets claims for it and then checks if role is good enough to listen to requested tenant or namespace or topic.

Bottom line no users are used but apps behave like users in their special way. Brokers and others need to communicate internally so they use client app to get that JWT but it's not used for much more than that. At least that I got from their docs and my really limited knowledge of OAuth2. I think they will try to provide more robust approach like with the JWKS but until then you need that public key inside of the pulsar or direct link to someplace where pulsar can fetch it. Example is file://auth0.com/mysomething/.../publickey. However I never tested it