I'd like to secure the REST-backend of our mobile app using [OpenID Connect](https://connect2id.com/learn/openid-connect). In short, users of the app should authenticate themselves (username/password) before fetching sensitive data over the REST backend (multiple services). 

After initial authentication they should receive an id/access token that they then can use for service-communication for the remainder of their app session. It is very important that i get this ID token since it contains info that is needed by the backend.

As an Identity Provide for implementing this scenario I'd like to use [KeyCloak](http://keycloak.org). However, I am unsure about the best auth flow to implement. I read [this](https://stackoverflow.com/questions/24047047/does-openid-connect-support-the-resource-owner-password-credentials-grant/24050911#24050911) and [this](https://stackoverflow.com/questions/24047047/does-openid-connect-support-the-resource-owner-password-credentials-grant/24050911#24050911) stackoverflow posts but I am still unsure if my desired solution is valid/safe/acceptable.

From what i've read about openID Connect the recommended openID Connect auth flow is the "3-legged **authorization code flow**" which involves:

1. redirecting the user to the login page of the Identity Provider (in my case KeyCloak) for authentication (for example login form).
2. after successfull authentication the IP then redirects the user back to the app along with an auth code passed as request parameter.
3. the app can then fetch the id/acccess tokens from the IP by passing this authentication code to the "standardized" token endpoint.

This all sounds very well for a browser-based web app, but in our app we would like to avoid the external login page and instead have a "local" in-app login page so to not break the user exprience too much. Also, our app has a feature that keeps you "logged in". In this case the user logs in only once and all tokens are then fetched in the background by the app when it is started.

So, based on our requirements I found [this](http://blog.keycloak.org/2015/10/getting-started-with-keycloak-securing.html) blog post, that uses a 2-legged **Resource Owner Credentials flow** approach that allows the app to authenticate itself AND collect the tokens in ONE request, without the need for navigating to the keycloak login page.

I tested this and this solution seems to provide exactly the functionality we need. Also, in our case the app and KeyCloak (=Self-Issued OpenID Provider) are solely used internally and belong to the same legal entity.

**Is it, in our use-case, allowed to use the 2-legged approach, and if not, why not? Does this approach impose some security risks that the 3-legged approach does not?**

I really hope to hear from you guys!

**Update 16-10-2018:** Wow guys, I found a very interesting tutorial-presentation (<https://www.youtube.com/watch?v=996OiexHze0>) from Nate Barbettini that covers oauth, openid connect and the type of authentication flows in very clear terms but also very in-depth. I'd recommend everybody to view this preentation before venturing further in the complex world of authorization/authentication using ouath/openid connect.

Regards,

Kim
The Netherlands