3

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.

Dhodgin
  • 468
  • 4
  • 8

1 Answers1

7

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.

Karthik
  • 3,075
  • 3
  • 31
  • 61
  • Thanks. I read about the Implicit grant flow and had configured the manifest a few times in my sample apps to allow it on AAD but I didn't really undertsand what it mean't. After checking the RFC for oauth 2.0 its very clear now. https://tools.ietf.org/html/rfc6749#section-1.3.2 Basically, implicit grant is intended for client side web applications like single page apps and the access token is sent immediately and the authorization code is skipped. This results in less redirects and overhead and a better user experience. – Dhodgin Jun 14 '16 at 14:36
  • 1
    Pretty much there. There are few more differences. I have summarized the important ones in this answer - http://stackoverflow.com/a/35548940/1371639 – Karthik Jun 14 '16 at 21:42