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

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.

Leave a Comment

Hata!: SQLSTATE[HY000] [1045] Access denied for user 'divattrend_liink'@'localhost' (using password: YES)