ACR Authentication Options

Question

Our .NET service is currently authenticating and pulling images from isolated ACR using an app registration with a username and password. We are considering using dSMS certificates instead. The plan is to obtain an access token from AAD, exchange it for an ACR refresh token, and use this token for authenticating and pulling images from ACR.

However, we would like to avoid adding dependencies on AAD (ESTS), and we are considering whether it's possible to use a dSTS-based token instead of an ESTS token for this process.

We have the following questions:

1. How does the username and password-based ACR authentication work behind the scenes? Does it involve or bypass AAD?
2. Is it possible to use dSTS-based tokens for ACR authentication? Is there a way for us to have a dSTS dependency for ACR authentication?

Any guidance on this would be greatly appreciated.

Answer 1

Hi Yuxuan Li,

Welcome to the Microsoft Q&A Platform! Thank you for asking your question here.

Here's an answer to your questions regarding Azure Container Registry (ACR) authentication options:

How does the username and password-based ACR authentication work behind the scenes? Does it involve or bypass AAD?

When you authenticate to ACR using a username and password (e.g., via an app registration), Azure Active Directory (AAD) is involved behind the scenes. The process works as follows:

AAD (via the Enterprise Token Service or ESTS) validates the provided credentials.

AAD then issues an OAuth access token.

This token is exchanged for an ACR refresh token, which is used to authenticate and pull images from the registry.

So, the username and password-based flow relies on AAD for authentication and does not bypass it.

Please refer to the document below for more details.
Authenticate with an Azure container registry

Is it possible to use dSTS-based tokens for ACR authentication?

Currently, Azure Container Registry does not support dSTS (Device Security Token Service) tokens for authentication. ACR's token issuance and validation process is tightly integrated with AAD and uses ESTS (Enterprise Token Service) for token management. Therefore, it is not possible to use dSTS-based tokens to authenticate against ACR.

Please refer to the document below for more details.
Authenticate with an Azure container registry
Azure Container Registry authentication with service principals

If you have any further queries, do let us know. If the comment is helpful, please click "Upvote".

Answer 2

Hello @yuxuan li ,

Thank you for your question, let me answer your questions as below:

1. How does the username and password-based ACR authentication work behind the scenes? Does it involve or bypass AAD?

When you use a username and password generated by Azure Container Registry (ACR), it does not directly involve Azure Active Directory (AAD) for each authentication request. Instead, ACR provides an admin account with a username and password that can be used for direct authentication.

Here’s how it works:

1. Admin Account: ACR allows you to enable an admin user account, which provides a username and password specifically for the registry.
2. Direct Authentication: This username and password can be used directly with Docker commands (e.g., docker login) to authenticate and interact with the registry.
3. Is it possible to use dSTS-based tokens for ACR authentication? Is there a way for us to have a dSTS dependency for ACR authentication?

Currently, ACR primarily supports authentication through AAD tokens. The available methods include:

• Individual login with Microsoft Entra ID: Using personal or service principal credentials.
• Service principal: For headless authentication scenarios.
• Managed identities: For Azure resources

There is no direct support for using dSTS-based tokens for ACR authentication. ACR relies on AAD for token issuance and validation, and there isn’t a documented method to replace this with dSTS tokens.

Given your requirements to avoid dependencies on AAD (ESTS), you might consider the following alternatives:

• Service Principal with Certificates: Instead of using username and password, you can use a service principal with certificate-based authentication. This enhances security and can be managed more easily3.
• Managed Identities: If your service is running on Azure, using managed identities can simplify the authentication process without needing to manage credentials directly1.

If avoiding AAD entirely is a strict requirement, you might need to explore other container registry solutions that support different authentication mechanisms.

Would you like more details on any of these alternatives or have other questions?

Answer 3

Thank you @Sai Krishna Katakam and @Ammar-Abdelqader01 for your insights! I really appreciate your help.

However, I noticed there seems to be a bit of a difference in your answers. One mentions the authentication using username and password will involve AAD, while the other suggests it will bypass AAD. Could you help clarify this for me so I can understand the best approach?