Azure AD ( Day #2) -Taking the right flow

Just wrapping up my second day on Azure AD.  I went bazinga with the 5 grant types.

  1. Authorization Code
  2. Implicit Grant
  3. Resource Owner Credentials
  4. Client Credentials
  5. Hybrid

Each flow fulfills a specific usage scenario but since  that I’ve been requested to investigate how we could have a customized UI for a login page using native client and Azure AD, I covered the Resource owner credentials.

We want to provide a better user experience on mobile devices – instead of taking the user to a login dialog in a web browser and so on, the user will simply enter his or her username and password directly in the application and login.

The problem with this scenario ( Resource Owner Credentials)  is that there is no way for my API server to securely verify the client_id of the app. If I include a client_secret in the app code/package, then it’s exposed to anyone who installs the app, so requiring a client_secret wouldn’t make the process any more secure. So basically, any other app can impersonate my app by copying the client_id.

Even if we decided that it’s OK to embed the client secret in the app, it’s still just wrong to handle the user credentials.  The whole purpose of having a browser that popup is simply just to avoid that?  You don’t want to be responsible for having comprise the user credentials.

I wonder how Facebook, Twitter and other smaller-yet-very-big social network companies deal with this problem in their mobile applications.

Advertisements