Authentication/Authorization of Tracker event streams

How are we supposed to secure the Collector? I have my android tracker and it is streaming events into my Scala collector. There’s the option of choosing HTTPS but, how do I validate the requests that are coming?
Is there a way to setup http basic authentication(using clientid/secret) or JWT token based authentication? If yes how should I go about it and is it good idea or not?
I want to make sure that I am getting requests only from my partner apps.

Hey @shailesh17mar - it’s an interesting one. Can I ask - what is the exact problem you are trying to solve? Is it a bad actor inspecting your Android apps to find the endpoint and then sending fake data? Or something else?

Of course any secret you embed into the app will be visible by a bad actor as well - but perhaps there’s another approach I am missing?

Edit I forgot we have a ticket to brainstorm ideas for this too: Placeholder for Verified Events #1139

Yeah, I am trying to solve Bad actor inspecting my android app or somehow if anyone got hold of the end point then is there any way to secure it?

Do your users have to authenticate into your Android apps, or can they use them anonymously?

They can use it anonymously as well.

I’m also interested in this.

For client-side apps sending data about user interactions, I’m not particularly concerned about authenticating the incoming events. However it would be nice if there was a way to ensure that only authenticated server-side applications could send events to the collector.

Maybe there could be basic authentication based on the app id or something.

I suppose it’d be possible currently by inspecting the request with another service before it hits the collector. However then that service would have to be scaled independently.

Hey @bryce - thanks for bubbling this thread up again! We are working on an RFC for Authenticated Events - hope to publish this soon…

1 Like

Hi Alex - great news !!

Hi @alex, are there any updates on server side authorization, was not able to see anything in the docs, maybe missed something, if so, could you point me in the right direction, thanks!

Authenticated events never made it to RFC however there is a reasonable alternative for server side events. If you attach a context/entity to your events that contains a “public key”, then you can validate this key in the JavaScript enrichment, if the key isn’t valid then you can reject the event within the JavaScript enrichment.

We might revist authenticated events some time in the future but it isn’t on our roadmap in the near future.

1 Like

Nice alternative @PaulBoocock.

@PaulBoocock do you think the idea of reusing website or mobile login auth in the Snowplow event stream is plausible or a red herring?

There are certainly some possibilities here. Already you could send auth tokens to the collector as a context and validate them with the JS Enrichment or the API Enrichment - this would be powerful for authenticated users, you could simply pass the auth token and enrich the event with user data based on the auth token as well as further authenticating the event for logged in users. I proposed something similar with the reCaptcha v3 enrichment RFC, where is calls the reCaptcha API to validate the data attached to each event.