An Authentication Hub - A brief summary

Guilherme Alves — Mon, 03 Aug 2026 23:55:18 +0000

In this article, you will learn how an Authentication Hub works.

To start, let’s define what an Authentication Hub is: imagine your company has various types of applications, such as accounting systems and identity management systems, among others. You need to grant access to these applications to each employee, but each individual should only access the ones relevant to their role. And that is what an authentication hub does.

An Authentication Hub centralizes authentication and authorization, ensuring that users can only access the resources they are permitted to use. Access decisions are typically based on Role-Based Access Control (RBAC), where permissions are assigned according to a user's role (for example, Accountant or HR Manager), and can be further refined using Attribute-Based Access Control (ABAC), which evaluates additional attributes such as department, location, employment status, time of day, or device compliance.

To build a secure Authentication Hub, we need a trusted key management system. In this article, we will use Azure Key Vault as the reference implementation.

The core idea is to issue digitally signed JSON Web Tokens (JWTs) that allow applications to verify a user's identity without storing authentication state. The private signing key is securely protected inside Azure Key Vault and never leaves the service. Applications validate the token using the corresponding public key

Since public keys cannot be used to generate valid signatures, they can be safely distributed through the JWKS endpoint.

Ensuring that the token was issued by a trusted authority and has not been tampered with.
Flow

An important aspect of this architecture is key rotation. Cryptographic keys should never remain valid indefinitely. Azure Key Vault allows signing keys to be rotated periodically, reducing the impact of a compromised key and following security best practices. During rotation, new tokens are signed with the new private key, while previously issued tokens remain valid because their corresponding public keys continue to be published through the JWKS (JSON Web Key Set) endpoint until all older tokens have expired. This enables seamless key updates without interrupting authenticated sessions.

Conclusion

Building an Authentication Hub around industry standards such as OAuth 2.0, OpenID Connect, JWT, and JWKS provides a secure, scalable, and maintainable authentication architecture. By keeping private keys inside a dedicated vault service and distributing only public keys for validation, applications can authenticate users efficiently without exposing sensitive cryptographic material.

Although this article used Azure Key Vault as the reference implementation, the same architecture can be applied to virtually any enterprise-grade key management solution, such as HashiCorp Vault, AWS KMS, Google Cloud KMS, or other Hardware Security Module (HSM)-backed services.

WebRTC - onicecandidate curiosity

Guilherme Alves — Tue, 30 Dec 2025 17:03:31 +0000

If you start to work with WebRTC you'll notice that onicecandidate returns many types of candidates, I was wondering what are they, because in my case the connection involves only 2 phones, but I receive many other candidates.
If you work with this event you'll probably code something like this:

Which represents the phase that you see other candidates in the server.
According to MDN It does : "fired to indicate that a new candidate has been gathered. This candidate needs to be delivered to the remote peer over the signaling channel your code manages."

Okay, now if we look to the logs, we'll see something like this :

And here comes my questions. What I discover after reading the docs is that this other candidates are simply other routes from the same phone (or any device) to ensure that the connection will occur.

Why do several appear :

The device has multiple interfaces (Wi-Fi, phone, IPv4, and IPv6), and each interface generates a "host" candidate.
The STUN server map uses the public IP/NAT and generates "srflx" (server-reflexive) type candidates.
If there is a TURN, "relay" candidates appear.
ICE can also generate "prflx" candidates during P2P checks.

Expected behavior :

ICE will try all options and choose the one that works best; manual filtering is not necessary in most cases.

In this phase you must send this candidate (which will be picked automatically) to your backend server (probably a WebSocket). MDN docs also said the same:

In my case I'm sending a webrtc_ice_candidate type message to indicate that a new candidate has gathered.

DEV Community: Guilherme Alves

An Authentication Hub - A brief summary

Conclusion

WebRTC - onicecandidate curiosity