After reading both articles I walked away with the assumption that for any new mobile app, the best practice is to ALWAYS use the Authorization Code Flow with PKCE. However, I’m wondering if there are other scenarios where other flows are appropriate (or even considered a best practice) for a mobile app.
Consider this scenario: the architecture for my app includes both a mobile app and an API.
Would the API then be considered a confidential application allowing me to use the Resource Owner Password Flow and make use of a native UX (rather than a browser-based UX)? The Resource Owner Password Flow article says:
“…the Resource Owner Password Flow should only be used when redirect-based flows (like the Authorization Code Flow) cannot be used.”
My question to this above statement is: Why? If my API is a trusted part of my overall system, and is considered a confidential application, then what additional security risks am I opening myself up to by using the Resource Owner Password Flow?
Thanks @dan.woda for the article. What I am still trying to wrap my head around though is why do the vast majority of mobile apps use a native login UX? This includes the most popular and widely used apps in the world. It can’t be that all these apps are security risks, right? I’m just referring to plain old username/password - no SSO or social identity providers or anything like that. How are all these existing apps able to securely implement a native UX?
There are two primary reasons companies choose the embedded/ROPG login for mobile:
UX
Infinite Session
UX developers are often opposed to opening the login screen in a browser, as they cannot control the UX as well as in the app itself.
Using old style refresh tokens, a user can log in once and then never has to enter credentials again. With Auth Code + PKCE the session will expire and a user will have to enter their credentials (not biometrics, their actual credentials).
There is a reason to choose the Auth Code + PKCE flow besides security: an Auth0 session is used for other things. For example, a bank had a mobile and a web app, and only the web app supported buying Certificates of Deposit. They wanted to be able to open the web app from the mobile app just for this feature and have the user be logged from the web app. This didn’t work because they used embedded login on the mobile app and so had no session. It would have worked without change if they had used the Auth Code + PCKE on the mobile app.
I do see what you’re saying about the additional benefits of Auth Code + PKCE when it comes to things like SSO. But, my use case is much simpler, and I don’t require SSO, and I actually do have the 2 primary reasons you mentioned to use ROPG - UX & Infinite Session.
I have a couple more questions:
When a company chooses embedded/ROPG - how do they address the associated security risks? The vast majority of apps are built with embedded UX, so they must be doing something to address the associated security concerns?
When you say “Infinite Session” with ROPG - are you referring to the use of a JWT refresh token to keep the user logged in?
What is the difference between an “old style refresh tokens” and a JWT refresh token?
Hi @jrp-23
I don’t have a quick answer to your first question, sorry.
For #2, yes, I mean a non-expiring refresh token.
For #3, “old-style” mean non-expiring, “new style” means expiring. I don’t think ANY refresh token is a JWT.
Can we have the longer discussion surrounding my 1st question? This is really the most important question in this thread - as I see the industry ignoring the best practice of using a browser-based UX. This is completely confusing to me, and leads me to view a browser-based UX as a competitive dis-advantage. Companies are constantly building new apps with embedded UX. They’re either assuming the risks, or mitigating them somehow?