OpenID Connect Authentication Flow (using KeyCloak) in a Mobile App + REST Backend

Question

I'd like to secure the REST-backend of our mobile app using 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. However, I am unsure about the best auth flow to implement. I read this and this 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 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

Answer 1

I believe Resource Owner Credentials flow should be avoided unless really needed AND the client app and environment are under your own full control. You may have full control over the app but you cannot control the phone OS (security updates, ...)

This blog post goes over the various problems. I do not fully agree with all the points mentioned in that post but I quote a few relevant ones:

• Flies in the face of the OAuth best practice guidelines (RFC8252)
• Public client applications cannot keep a secret and therefore cannot authenticate themselves
• Significantly increases the attack surface on user credentials (if the client is compromised, so is the user's entire account)

Also here is an excerpt from O'Reilly book Getting Started with OAuth 2.0 by Ruan Boyd:

When Should the Resource Owner Password Flow Be Used? Because the resource owner’s password is exposed to the application, this flow should be used sparingly. It is recommended only for first-party “official” applications released by the API provider, and not opened up to wider third-party developer communities.

If a user is asked to type their password into “official” applications, they may become accustomed to doing so and become vulnerable to phishing attempts by other apps. In order to mitigate this concern, developers and IT administrators should clearly educate their users how they should determine which apps are “official” and which are not.