Been doing some reading regarding OAUTH2.
So...
Authorisation Code Grant: Is for users who want to access MY application/API through a third party application. Example: A user through Flicker wants to access MY photo printing API. In this case Flicker will do all the redirection and the OAUTH2 flow with MY servers. Access token is provided and 3rd party application can use MY API as needed. The application developer will need to register to get the client id and client secret.
Implicit: Same as above except the mobile/app doesn't have a back end server to safekeep the client secret. The mobile app will handle redirect and OAUTH2 flow. Access token is provided and 3rd party application can use MY API as needed. Refresh token not supported. The application developer will need to register to get the client id.
Resource Owner Password Credentials Grant: In this case, this is MY mobile/web app that I distribute to my users through the typical iTunes/Play stores. The users strictly use MY app to do their day to day stuff. MY mobile/web app will ask the user for Username/Password and post them to MY back end where it will authenticate and then provide back the access token.
Client credentials grant: This case is used for application to do internal machine to machine stuff. I.e: MY App1 accessed MY App2, in the back end somewhere.
For now I do not foresee sharing my API with 3rd parties and my users will install MY app through iTunes/google play. I suppose that Password Credentials is good for me right now. Eventually if I want to open up my API to the rest of the world I will have to implement Authorisation Code Grant
As I searched around for this subject, I came across this link: https://alexbilbie.com/guide-to-oauth-2-grants/ which has a nice decision flow.