Just wrapping up my second day on Azure AD. I went bazinga with the 5 grant types.
- Authorization Code
- Implicit Grant
- Resource Owner Credentials
- Client Credentials
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.