How to Encode IoT Hub SAS Key to Base64 in .NET nanoFramework?

Hello Dharmesh Joshi,

Welcome to Microsoft Q&A and Thank you for reaching out,

In Azure IoT Hub / DPS The Primary Key you copy from the Azure portal is already Base64-encoded

So in most cases: You do NOT need to Base64 encode it again, You can use it directly as-is

Why this causes confusion

It’s technically possible to Base64 encode a string in .NET nanoFramework like this:

using System;

However, this is usually unnecessary and incorrect for IoT Hub, because:

• The portal already gives you a Base64 string
• Encoding it again leads to double encoding, which will cause authentication failures

Correct approach for IoT Hub / DPS

If you copied the key from Azure Portal

Just use it directly:

string primaryKey = "<YOUR_IOTHUB_PRIMARY_KEY>";

If you’re using nanoFramework DPS sample:

Pass it directly to:

• DeviceAuthenticationWithRegistrySymmetricKey.KeyAsBase64String

When generating SAS tokens (important distinction)

Here’s the correct flow:

1. Decode the Base64 key

byte[] keyBytes = Convert.FromBase64String(primaryKey);

1. Generate HMAC-SHA256 signature

using (var hmac = new System.Security.Cryptography.HMACSHA256(keyBytes))

1. Encode the signature to Base64

    string signature = Convert.ToBase64String(signatureBytes);

1. URL encode the result

string encodedSignature = System.Net.WebUtility.UrlEncode(signature);

Base64 encoding is applied to the signature, not the original key

When would you encode the key yourself?

Only if:

• You are starting with a raw (non-Base64) key, or
• You generated the key programmatically

This is not the case for standard IoT Hub keys from Azure

Azure IoT Hub primary keys are already Base64-encoded

Don’t encode them again (avoids double encoding issues)

Decode them when generating SAS tokens

Encode only the generated signature, not the original key

The primary key provided by Azure IoT Hub is already Base64-encoded, so you don’t need to encode it again in .NET nanoFramework.

While it is technically possible to Base64 encode a string using Convert.ToBase64String, doing so on the IoT Hub primary key will result in double encoding and cause authentication issues.

When using DPS (for example, with DeviceAuthenticationWithRegistrySymmetricKey), you can pass the key directly as the Base64 string.

If you are generating a SAS token, the correct approach is to first decode the primary key using Convert.FromBase64String, then use it to compute the HMAC-SHA256 signature, and finally Base64 encode the generated signature.

So in most scenarios, no additional Base64 encoding of the primary key is required.

Please refer this

Convert.ToBase64String: https://docs.microsoft.com/dotnet/api/system.convert.tobase64string

Encoding.UTF8.GetBytes: https://docs.microsoft.com/dotnet/api/system.text.encoding.utf8

DeviceAuthenticationWithRegistrySymmetricKey.KeyAsBase64String: https://learn.microsoft.com/dotnet/api/microsoft.azure.devices.client.deviceauthenticationwithregistrysymmetrickey.keyasbase64string

I Hope this helps. Do let me know if you have any further queries.

If this answers your query, please do click Accept Answer and Yes for was this answer helpful.

Thank you!

Hello @Dharmesh Joshi ,

welcome to this moderated Azure community forum.

It's nice to see you try out the .Net nanoFramework for connecting constrained devices to the Azure IoT Hub.

Using a Device Provisioning Service is a wise choice to be prepared for future needs (like switching to another IoT Hub or future Azure IoT Hub features).

I expect you already generated a (individual enrollment) device registration in the Device Provisioning service?

If so, just use those credentials in the code.

Once your device connects to the DPS, the secrets are checked and a linked IoT Hub is appointed to the device automatically. The device will then connect to the IoT hub until that connection is rejected. Your device will restart the enrollment again and the DPS will make a choice on providing an (other) IoT Hub.

So, just copy the DPS enrollment secrets and you are good to go.

In a more production-like situation, using certificates is recommended.

If the response helped, do "Accept Answer". If it doesn't work, please let us know the progress. All community members with similar questions will benefit by doing so. Your contribution is highly appreciated.

In Azure IoT, the device’s symmetric key (primary/secondary) is already represented as a Base64 string. For .NET (including nanoFramework) the SAS key parameter should be that Base64 string as-is, not a further-encoded value.

For example, in the .NET client libraries the symmetric key is passed and stored as a Base64 string via properties such as KeyAsBase64String on DeviceAuthenticationWithRegistrySymmetricKey and ModuleAuthenticationWithRegistrySymmetricKey.

So, to supply the SAS key in nanoFramework:

1. Take the device’s primary (or secondary) key exactly as shown in the IoT Hub device identity (it is already Base64).
2. Use that value directly where the SDK expects the Base64 SAS key.
3. Do not re-encode it; only decode it from Base64 when computing HMAC-SHA256 signatures (for example, when generating SAS tokens or derived keys).

When generating SAS tokens or derived device keys, decode the Base64 key first, then compute the HMAC-SHA256, and finally Base64-encode the result, as shown in the symmetric key and SAS token documentation.

References:

• Symmetric key attestation
• Control access to IoT Hub with shared access signatures
• DeviceAuthenticationWithRegistrySymmetricKey.KeyAsBase64String Property
• ModuleAuthenticationWithRegistrySymmetricKey.KeyAsBase64String Property