1

I have been doing some research about using OAuth2.0 on our mobile application, but I'm really having trouble deciding whether OAuth2.0 really is the best choice.

Since we are not interacting with any 3rd party, we don't really have to go through the Authorization stage to authorize the third party resource.

One other requirement for our app is that a user should stay logged in indefinitely.

So my focus is on the next step. But my research so far tells me that OAuth workflow is really not that secure. A refresh token can be easily captured by connecting your device through a proxy like Fiddler.

I mean if someone is going to spend the effort to connect to a proxy, chances are they are willing to spend the effort to capture the refresh token, client secret and client id.

PKCE extension only limits the impact to possibly a single user.

So in my mind, using OAuth 2.0 is really not more secure than the traditional way of storing a session token, once you deactivate a token, security risk is mitigated. Blacklisting a refresh token still gives attacker some time (however many minutes is left on their JWT token)

It introduces all the complexity of refreshing a token, and dealing with token change when the app has been offline for a while etc...

So my question is: for a mobile app that keeps a user logged in indefinitely, is there a point in using OAuth2.0?

Improve this question
3
  • You need some sort of credential to present to whatever service you interact with. Either you send you send the user's password every time or you send some sort of token. If you don't interact with any remote services then you don't need authentication at all.
    – Miles Budnek
    Aug 8 '19 at 1:29
  • If your app connects to your own API, then OAuth doesn't really do anything for you. Where OAuth shines is when your app should connect to someone else's API.
    – MechMK1
    Oct 9 '20 at 14:48
  • @MechMK1 that's not really something you can claim like that. it depends on usecase and thread model... I agree that it offers more when you use it for allowing others to use your api. But Oauth 2 can also help with single access point. limiting attack surface.
    – LvB
    Oct 9 '20 at 17:21
1

OAuth2 is a way of storing a session token.

It is, however, standardized and the the threat model is well documented. Even though OAuth2 was indeed designed for 3rd-party access to APIs, it is still relevant in 1st-part scenarios.

Regarding mobile applications and authentication UI, there are 2 ways of doing it:

  • using a native UI that sends the credentials (eg. login + password) to the backend to retrieve that session token. This can be either the OAuth2 Resource Owner Password Credentials or any other custom protocol
  • redirecting to the browser (browser-view) using the OAuth2 authorization code flow

In the latter case:

  • you enable SSO with other web or native applications using the same authentication service
  • you have to keep in mind that any application on a mobile can claim a custom redirect URI. This is why you still need the authorization page (so that the user can understand he's authorizing for the correct app, and not a malicious one).
  • also, PKCE helps with preventing token theft between the browser-view and the application

Note in addition that:

  • you can roll your refresh tokens on each token request (making the previous refresh token invalid)
  • the request for new tokens (on /token) ought to be done on HTTPS. It is then not possible to steal a refresh token
  • you don't necessarily have to use JWT access tokens if your security requirements demand immediate revocation of tokens

If your authentication scheme is simple, why not stick with a home-made session token solution. However, if it gets more complex, you might end up with shooting yourself in the foot and introducing security vulnerabilities that you would have avoided using standard OAuth2 servers and libraries.

Improve this answer
7
  • 1
    The only thing I dislike about this answer is the last paragraph. The reasons listed after the first sentence are exactly why the author should not use a home-made solution. Otherwise, this is an excellent write-up.
    – oxr463
    Aug 8 '19 at 12:38
  • 1
    Well, if you go with native UI just forwarding the username & password to get a long-lived token, then I don't see additional risks with not using an OAuth2 server (and ROPC flow). IT security is also about costs vs benefits, and deploying an OAuth2 server just for that would be overkill.
    – Tangui
    Aug 8 '19 at 13:38
  • Thanks, Tangui and Lucas, I appreciate the discussion. My main point about mobile is that it IS indeed easy to (not sure if we are using steal in the same sense) obtain the Refresh token. You simply hook up your device to proxy like Fiddler, and you can monitor all the web traffics, by installing the Fiddler certificate on your device, you can decode all the traffic back and forth. That's why I don't think even PKCE really makes it that secure.
    – swu
    Aug 8 '19 at 13:55
  • Well this is called TLS interception. If your company is doing it, first it's a serious security and privacy breach, then you must have signed a document that you allow them to do that, and to finish no worries, TLS1.3 will no longer allow doing these nasty things. But we're in a edge case where your company intentionally decides to weaken TLS and for ALL CREDENTIALS.
    – Tangui
    Aug 8 '19 at 17:59
  • Also you should be aware that, when using native UI, there is no way to know if the calling application is yours or a malicious one, except if you manage to register the device one way or another (which involves some physical exchange most of the time, like flashing a QR-code sent by mail).
    – Tangui
    Aug 8 '19 at 18:00

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.