This article shows you how to connect to Azure Blob Storage by using the Azure Blob Storage client library for Java. Once connected, use the developer guides to learn how your code can operate on containers, blobs, and features of the Blob Storage service.
Add azure-sdk-bom to take a dependency on the latest version of the library. In the following snippet, replace the {bom_version_to_target} placeholder with the version number. Using azure-sdk-bom keeps you from having to specify the version of each individual dependency. To learn more about the BOM, see the Azure SDK BOM README.
Add the following dependency elements to the group of dependencies. The azure-identity dependency is needed for passwordless connections to Azure services.
com.azure.storage.blob.specialized: Contains classes that you can use to perform operations specific to a blob type (For example: append blobs).
Authorize access and connect to Blob Storage
To connect an app to Blob Storage, create an instance of the BlobServiceClient class. You can also use the BlobServiceAsyncClient class for asynchronous programming. This object is your starting point to interact with data resources at the storage account level. You can use it to operate on the storage account and its containers. You can also use the service client to create container clients or blob clients, depending on the resource you need to work with.
You can authorize a BlobServiceClient object by using a Microsoft Entra authorization token, an account access key, or a shared access signature (SAS). For optimal security, Microsoft recommends using Microsoft Entra ID with managed identities to authorize requests against blob data. For more information, see Authorize access to blobs using Microsoft Entra ID.
To authorize with Microsoft Entra ID, you'll need to use a security principal. Which type of security principal you need depends on where your app runs. Use the following table as a guide:
An easy and secure way to authorize access and connect to Blob Storage is to obtain an OAuth token by creating a DefaultAzureCredential instance. You can then use that credential to create a BlobServiceClient object.
Make sure you have the correct dependencies in pom.xml and the necessary import directives, as described in Set up your project.
The following example uses BlobServiceClientBuilder to build a BlobServiceClient object using DefaultAzureCredential, and shows how to create container and blob clients, if needed:
// Azure SDK client builders accept the credential as a parameter
// TODO: Replace <storage-account-name> with your actual storage account name
BlobServiceClient blobServiceClient = new BlobServiceClientBuilder()
.endpoint("https://<storage-account-name>.blob.core.windows.net/")
.credential(new DefaultAzureCredentialBuilder().build())
.buildClient();
// If needed, you can create a BlobContainerClient object from the BlobServiceClient
BlobContainerClient containerClient = blobServiceClient
.getBlobContainerClient("<container-name>");
// If needed, you can create a BlobClient object from the BlobContainerClient
BlobClient blobClient = containerClient
.getBlobClient("<blob-name>");
public static BlobServiceClient GetBlobServiceClientSAS(String sasToken) {
// TODO: Replace <storage-account-name> with your actual storage account name
BlobServiceClient blobServiceClient = new BlobServiceClientBuilder()
.endpoint("https://<storage-account-name>.blob.core.windows.net/")
.sasToken(sasToken)
.buildClient();
return blobServiceClient;
}
To learn more about generating and managing SAS tokens, see the following articles:
For scenarios where shared access signatures (SAS) are used, Microsoft recommends using a user delegation SAS. A user delegation SAS is secured with Microsoft Entra credentials instead of the account key.
public static BlobServiceClient GetBlobServiceClientAccountKey(String accountName, String accountKey) {
StorageSharedKeyCredential credential = new StorageSharedKeyCredential(accountName, accountKey);
// Azure SDK client builders accept the credential as a parameter
BlobServiceClient blobServiceClient = new BlobServiceClientBuilder()
.endpoint(String.format("https://%s.blob.core.windows.net/", accountName))
.credential(credential)
.buildClient();
return blobServiceClient;
}
You can also create a BlobServiceClient object using a connection string.
public static BlobServiceClient GetBlobServiceClientConnectionString(String connectionString) {
// Azure SDK client builders accept the credential as a parameter
// TODO: Replace <storage-account-name> with your actual storage account name
BlobServiceClient blobServiceClient = new BlobServiceClientBuilder()
.endpoint("https://<storage-account-name>.blob.core.windows.net/")
.connectionString(connectionString)
.buildClient();
return blobServiceClient;
}
For information about how to obtain account keys and best practice guidelines for properly managing and safeguarding your keys, see Manage storage account access keys.
Important
The account access key should be used with caution. If your account access key is lost or accidentally placed in an insecure location, your service may become vulnerable. Anyone who has the access key is able to authorize requests against the storage account, and effectively has access to all the data. DefaultAzureCredential provides enhanced security features and benefits and is the recommended approach for managing authorization to Azure services.
Configure the JVM TTL for DNS name lookups
The Java Virtual Machine (JVM) caches responses from successful DNS name lookups for a specified period of time, known as time-to-live (TTL). The default TTL value for many JVMs is -1, which means that the JVM caches the response indefinitely, or until the JVM is restarted.
Because Azure resources use DNS name entries that can change, we recommend that you set the JVM TTL value to 10 seconds. This configuration ensures that an updated IP address for a resource is returned with the next DNS query.
To change the TTL value globally for all applications using the JVM, set the networkaddress.cache.ttl property in the java.security file.
networkaddress.cache.ttl=10
For Java 8, the java.security file is located in the $JAVA_HOME/jre/lib/security directory. For Java 11 and higher, the file is located in the $JAVA_HOME/conf/security directory.
Build your app
As you build apps to work with data resources in Azure Blob Storage, your code primarily interacts with three resource types: storage accounts, containers, and blobs. To learn more about these resource types, how they relate to one another, and how apps interact with resources, see Understand how apps interact with Blob Storage data resources.
The following guides show you how to access data and perform specific actions using the Azure Storage client library for Java:
Start here and learn how you can get the full power of Azure with your Java apps - use idiomatic libraries to connect and interact with your preferred cloud services, including Azure SQL and NoSQL databases, messaging and eventing systems, Redis cache, storage and directory services. As always, use tools and frameworks that you know and love – Spring, Tomcat, WildFly, JBoss, WebLogic, WebSphere, Maven, Gradle, IntelliJ, Eclipse, Jenkins, Terraform and more.
Build end-to-end solutions in Microsoft Azure to create Azure Functions, implement and manage web apps, develop solutions utilizing Azure storage, and more.