Why isn't Application ID a secret?

Question

Imagine my tenant has a registered app A with Sites.ReadWrite.All delegated permission, granted with admin consent. This is a desktop app that users in my organization will download and use to automate some tasks related to their data.

App A has an Application ID hanging around since it's not considered a secret. What if a user learns this ID and use it to build an app B? She won't need to ask tenant admins to register her app because she "stole" an ID already. And this ID will grant her app the same permissions as app A, including the admin consent, meaning users of app B will probably never be aware of that.

Isn't that a security issue with public Application IDs? Is there a way to avoid that scenario?

Answer 1

Hello Bats,

Yes, it is a potential security issue if someone obtains the Application ID of a registered app with delegated permissions and uses it to create a new app with the same permissions. To avoid this scenario, you can use Azure Active Directory (Azure AD) Application Registration with a client secret instead of a public Application ID.

When using a client secret, the app needs to authenticate with Azure AD using a combination of its Application ID and a secret key. This secret key is known only to the app and the Azure AD tenant, and it is never shared or transmitted over the network. This provides an additional layer of security as an attacker would need to know the client secret to use the registered app's permissions, not just the Application ID.

To use client secrets, you will need to create an Azure AD Application Registration with a client secret and grant it the necessary permissions. Then, your app A will use the client secret to authenticate with Azure AD and access the required resources.

Overall, while public Application IDs themselves are not necessarily a security issue, it's important to implement strong security measures around your Azure AD applications to prevent unauthorized access and misuse.

If this answers your question, please be sure to le me know

Answer 2

Oh I see, well, for desktop/native/mobile apps, you can authenticate using a client secret without disclosing it to the users by using the OAuth 2.0 client credentials flow. This flow allows an application to authenticate with Azure AD using its own credentials (i.e., a client ID and client secret) instead of relying on a user's credentials.

Here's how the flow works:

1. The application sends a request to Azure AD to obtain an access token by including its client ID and client secret in the request.
2. Azure AD verifies the client ID and client secret and returns an access token if they are valid.
3. The application uses the access token to access protected resources in your organization's tenant.

To use the client credentials flow, you will need to register your desktop/native/mobile app with Azure AD using the App Registration Portal. During registration, you will create a client ID and client secret for your application. You can then use these credentials to authenticate your application using the client credentials flow.

It's important to note that the client credentials flow is only appropriate for confidential client applications where the client secret can be securely stored on the client device. If the client secret is compromised, an attacker could use it to access your organization's resources. Therefore, you should ensure that your client secret is stored securely on the client device and not accessible to unauthorized users.

Answer 3

Yes, it can be a security issue having a public Application IDs, and contrary to what @Ayomide Oluwaga suggests, there is really no way to ensure your Application ID will not be retrieved by someone once they have access to your client application. Not only your Application ID will be embedded in your app and available to anyone who knows what to look for, this ID is also disclosed in other places that are accessible to many users, such as some configuration pages in the Azure Portal. It can never be assumed to be a secret.

Microsoft itself recognizes that you can't hide things from users in a native app in this article when explaining what a client_secret is:

The client secret that you created in the app registration portal for your app. It shouldn't be used in a native app, because client_secrets can’t be reliably stored on devices. It's required for web apps and web APIs, which have the ability to store the client_secret securely on the server side.

Whether this is a serious security issue depends on your specific scenario. Remember that you can only get away without a client secret if you are using delegated permissions, so your native app can only do what a user running your app can do anyway using their browser. If you really can't afford letting others piggyback on the delegated permissions your app has been granted, the only solution is to build a server-side app.