We are excited to release SlashID analytics and webhooks, providing greater visibility and actionable insights into your authentication flows. In this blog post, we will showcase our new features and how you can use them by answering four questions: why, what, how, and when.

The Why

If you’re reading this, there’s a good chance that authentication is a core step of your business logic, whether you’re selling products or controlling access to sensitive information and systems.

Having deep and instant visibility on which users login at the time they login can make a great difference to your business, and you may wish to take specific actions in response to specific user behaviors.

SlashID analytics does just this: with first-party visibility into your authentication flows, you can get crucial insights into the experience of your user base on your platform.

These are just a few example use cases for SlashID analytics:

• Monitor authentication failures to redirect users to appropriate support channels
• Welcome new users with personalized messages and flows when they register for the first time
• Keep audit trails for compliance purposes
• Monitor the success of marketing campaigns that use DirectID

There are many more, and as a result we have designed our analytics to be flexible, while maintaining a straightforward developer experience.

Our analytics events include a correlation ID that you can use to tie together events from a single browser session, to follow each step of your users’ journey through your authentication and onboarding flows.

The What: SlashID Events

SlashID exposes analytics information through events – simple messages telling you that something happened. For example, the AuthenticationSucceeded event indicates that a user successfully logged in to your application.

All of our events are defined using protobuf, which we publish in our documentation. You can download these definitions and use them to generate code for handling events, or simply use them as reference.

Our initial release includes a few core events that cover the key steps of identity and authentication:

• Authentication Succeeded
• Authentication Failed
• Person Created
• Virtual Page Loaded

We will be adding more in the near future to further enrich your analytics.

The How: Webhooks

You can consume SlashID events by registering webhooks for your organization. You can create a webhook with two simple API calls:

1. Create a webhook with a target URL
2. Specify a trigger for that webhook (for example, an AuthenticationSucceeded event)

Each webhook can have multiple triggers, and multiple webhooks can consume the same trigger, so you’re free to configure your webhooks in whatever way suits your requirements. Once you have registered your webhook, it will be called on each relevant trigger.

For step-by-step instructions, read our webhooks guide.

Security First

One of the key aspects of handling webhooks from any provider is security – you must verify that the webhook request originated from a trusted provider, and that the content has not been tampered with. Unfortunately, not all providers make this possible, and when they do, the process is rarely straightforward. At SlashID we take a security-first approach, so we made webhook verification easy and safe.

The common approach to webhook verification is to send a request with a JSON payload, with a signature embedded somewhere in the request. The signature is based on some concatenation of the JSON body, the URL, and possibly other information, and the process of generating/verifying the signature is often based on a shared secret. This makes your life difficult in myriad ways: you need to manage a secret; you need to either re-implement the verification logic or depend on a library from the provider (assuming they publish one in the language you use); and you’ll probably need to reimplement it anyway for testing. On top of this, there’s no standard for signing HTTP requests, so each provider has their own way of doing it. In one word, it’s a nightmare.

At SlashID, we use a JSON Web Token (JWT) – just like for our authentication tokens. JWTs are a well-known and widely used standard for securely exchanging information between parties, and pretty much every language has at least one library for handling them. The request body of the webhook call is a signed and encoded JWT. To verify a SlashID webhook call, simply retrieve the verification key and use your library of choice to check the signature and get the JWT payload. Once decoded, you can check the content of the webhook is what you expect. Easy.

The decoded payload includes some metadata about the call (such as your organization ID and timestamps), and a field called trigger_content, with information about whatever triggered the webhook. For an event, this would be the contents of the event, as in our event definitions. For more detail, see our webhooks guide.

The When: Event Publishing

SlashID publishes events in response to user interactions with your frontend using the SlashID SDK, and from our backend. In most cases events are published automatically and asynchronously behind the scenes, so you don’t need to worry about them. If you want to keep track of page views (for example to monitor the progress of your users through the funnel), the VirtualPageLoaded event should be published by calling the corresponding method in the SDK. If you are building a single page application, this method can be called every time client side navigation happens.

Summary

With this release, you can use webhooks to consume SlashID analytics events. We will be adding more events and features in the near future, so stay tuned for release announcements.

Ready to try SlashID? Sign up here!

Is there a feature you’d like to see, or have you tried out analytics and have some feedback? Let us know!