Introduction
Between the hyped AI announcements at this year’s annual Microsoft Build tech conference are some less headline-worthy hidden gems. In particular, Microsoft’s message distribution service Azure Event Grid was announced to have SAS token authentication support now in public preview.
Overview
This blog will focus on the now three authentication types now supported by Azure Event Grid:
- Microsoft Entra ID (Formerly Azure AD)
- Access Key
- SAS token authentication (Now in preview)
Many Azure services such as Azure Storage have had SAS token authentication for some time now. But there are some interesting caveats to consider when choosing the right authentication for Azure Event Grid.
Authentication using Access Keys
Access keys are essentially master/admin passwords: using them grants you full access, much more than you should need for most cases and therefore violating the principle of least privileges.
One benefit is they are the simplest authentication to use, since because they have full access to an Azure resource. As a developer you never need to worry about not having enough access to that resource. Additionally access keys are automatically generated when Azure resources are first created.
However if an access key is leaked then anyone with that access key has full access to that resource. Furthermore they are long-lived credentials as well, which can be convenient for developers but again has problematic security implications.
Imagine you were processing sensitive personal identifiable information (PII) information via Azure Event Grid, then someone with an access key could have full access to that resource and steal that confidential information.
Unfortunately some third party systems which integrate with Azure resources only support access keys as the only valid authentication mechanism, so in that case using them is unavoidable. But in most other cases, the other two options are preferable.
Authentication using Shared Access Signature (SAS) Tokens
If access keys are like using a mop to paint a portrait, then Shared Access Signature (SAS) tokens are like using a paintbrush to paint the finer details: the mop will get the job done if you don’t care about the end result.
Unlike access keys, SAS tokens can satisfy the principle of least privilege by assigning exactly as much permission as needed before generating it. One important option is to alter the start and expiry datetimes of each token, which means each token can be as short-lived as you need. Another is the depth of resource access, for example you can create SAS tokens at a topic level which will work for all underlying subscriptions or at the subscription level so that the same SAS token won’t authenticate against other subscriptions for the same topic.
Figure 1: Example of SAS granularity options when generating tokens for Azure Storage, since UI for Azure Event Grid isn’t available yet
SAS tokens are generated via an algorithm using an access key. Once they are generated, they cannot be individually invalidated without regenerating the access key used in the generation of that key (this is the signing key option in Figure 1). For example, if you generated 5 SAS tokens using key1, and you found out that one SAS token was leaked, then to prevent the leaked token from being used you must regenerate key1 which would subsequently invalidate all 5 SAS token.
For Azure Event Grid, with SAS token authentication being in public preview it’s expected that core functionality works. However features such as Azure Portal functionality will take some time. As a result, there are a few caveats to be mindful of:
- Currently you must generate Event Grid SAS tokens programmatically, but you can safely assume that once this feature is out of preview you will be able to generate SAS tokens in the Azure Portal which is available for other Azure products.
- The actual granularity you can set an Event Grid SAS token is still very limited, especially when compared to Figure 1, where for example SAS tokens can restrict allowed IP addresses which enhances security. As per Authenticate Azure Event Grid clients using access keys or shared access signatures – Azure Event Grid | Microsoft Learn, the only granularity that is available are:
- Which resource to authorise: whether at a custom topic, domain, partner namespace, namespace or subscription level
- Expiration time
By design, SAS tokens and access keys both suffer from the same problem of managing expiring authentication, which is where Microsoft Entra ID managed identity authentication comes in.
Authentication using Microsoft Entra ID
Microsoft Entra ID (formerly Azure AD) is a cloud-based identity and access management service. Using it would mean having a separate dedicated authentication service rather than use access keys and SAS tokens which come out of the box of the Azure resource used.
One of its core functionalities is managed identity: Microsoft manages the identity of the Azure resource, so you don’t have to worry about expiring authentication tokens or managing passwords. However, this functionality is limited to Azure resources (or on-premise resources via Azure Arc), such as authenticating an Azure Function App to connect to an Azure Event Grid.
If you had to integrate non-Azure products such as AWS Lambda to Azure Event Grid, then you could instead create an application security principal using Microsoft Entra ID. However, application Security Principals require you to manage certificates or client secrets, although they both expire similar to SAS tokens and need regular rotation. So it’s generally advised that where possible, use managed identity to minimize the need for authentication maintenance.
There are some use cases where using Microsoft Entra ID is overkill. For example, if you wanted to allow an external service to temporarily subscribe to events from an Azure Event Grid topic, then providing a Shared Access Signature (SAS) token would be more practical. With a SAS token, you can grant specific access to the event subscription for a limited time before the token expires.
On the other hand, if you were to grant access via managed identity, you would need to add the external service to your Microsoft Entra ID tenant, assign the necessary permissions via roles, and then revoke access afterward, which could be cumbersome and unnecessary for temporary access.
Conclusion
The inclusion of SAS token authentication brings Azure Event Grid closer to the variety of authentication methods available for other Azure products. As with many technological decisions, it’s important to understand each method’s use case carefully so that you can weigh each of their pros and cons in order to make an informed decision.