Are there security concerns exposing the clientId and tenant in client side code when using adal/adal-angular.js

3
votes

I'm in the process of implementing AAD single sign on in our application and we will be using the adal.js/adal-angular.js library with our MEAN stack application. Part of initializing the library is to call init() and provide the tenant and clientId

  adalProvider.init(
  {
    tenant: "mycompany.onmicrosoft.com",
    clientId: "05bdd8d7-XXXX-XXXX-XXXX-5f2769f8b9b6"
  },
  $httpProvider
  );

for example.

If someone views the source and takes the tenant and clientId can they use that somehow in their own application maliciously?

Does AzureAD check the URL the request came from and block it if it's not the configured login url?

Seems as though the clientId is more like a public key but if the only 2 things needed for an app to trigger authentication with AzureAD is the tenant and clientId and those are exposed client side in source code that someone could use them to create a phishing site X or to grab id_tokens if the request is redirected back to their site X rather than the original site

Does Azure rely on the configured settings in the application setup and protect against this?

I'm still getting a grasp on the OpenID Connect and OAUTH 2.0 finer points so forgive me if this question has an obvious answer.

1
angularjsadaladal.js

1 Answers

7
votes

Adal.js uses the Implicit flow (as per OpenID connect / oAuth 2 specifications) and exposing the ClientID (and tenant id of AAD) doesn't pose any security risk.

While registering the Clients in Azure AD administration panel, we specify a Redirect URI for the client. This is the Application URL for which users will get redirected after successful authentication.

  • So even if a malicious client tries to use your clientid and tenant id, the users will be redirected back to the registered URI(which is your app) after authentication and not to the malicious site
  • In implicit flow the application doesn't collect any username / password, IDP/OP (i.e AAD) manages this part - so user credentials won't be compromised as well

**For other flow types (Authorization code, Client credentials,etc) we have something called client-password along with ClientID. This shouldn't be exposed to public clients.