Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Create Mock endpoint for AAD Token Generation for Local Development #2373

Open
marvinbuss opened this issue Mar 1, 2024 · 0 comments
Open

Comments

@marvinbuss
Copy link

marvinbuss commented Mar 1, 2024

Which service(blob, file, queue, table) does this issue concern?

blob, file, queue and table

Which version of the Azurite was used?

v3.29.0

Where do you get Azurite? (npm, DockerHub, NuGet, Visual Studio Code Extension)

Docker and Visual Studio Code Extension.

What's the Node.js version?

Not applicable

What problem was encountered?

For consistency reasons, the goal is to use OAuth authentication when developing locally as well as when running the code in Azure.
Therefore, we were running Azurerite with OAuth and HTTPS. Azurerite then requires passing a Bearer token to its endpoint.

In our case we were using the azure-identity library and the ClientSecretCredential classes. This however requires a valid client ID, client secret and tenant ID to be passed to the credential. For local development, this is not desired as developers should just interact with Azurite and may not even have a valid Azure Account or service principal to generate a token.

What could be done is to override the authority parameter of ClientSecretCredential to make sure it does not call https://login.microsoftonline.com/<tenant-id>/v2.0/... to generate a token but some mock endpoint. Now, the customer could create a mock API endpoint which creates additional effort.

The ask is whether Azurerite could offer another endpoint to mock the token generation as well to overcome the need for actual credentials when developing locally.

Steps to reproduce the issue?

If possible, please provide the debug log using the -d parameter, replacing <pathtodebuglog> with an appropriate path for your OS, or review the instructions for docker containers:

Not applicable

Have you found a mitigation/solution?

Today, local development has to rely on shared storage keys, which should be avoided.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant