I have been reading a lot about OAuth 2 flow recently, and I wanted to ask if this is applicable to the app that I am building, and what type of security I should be using.


  1. We have a native ios/android and angular SPA app.
  2. We build/own/control our own backend apis, and only our frontend apps can(should) communicate with these apis.
  3. User logs in on a form, we validate credentials on backend, and return a JWT back, which is then used for subsequent requests. Access to most apis is restricted to logged in users, other apis are open to the net to allow users to register.

I cannot see a use case here for OAuth here, however, everything I am reading seems to suggest that it is required. We will not be delegating access to third party systems, we simply only want to validate our own customers, and only allow them to access our apis via our front end apps, after they have logged.

Is the approach I have outlined which we are currently doing correct, or do I need to implement OAuth Authorization Code flow, and if so can you please explain why ?

2 Answers 2


seems to suggest that it is required

do I need to implement OAuth Authorization Code flow ... ?

I suppose that your understanding of software development is not correct.

Who requires you to implement that?

As far as I understand you control both sides - client and server. Then it is you who decides what should be done. If you develop software for some customer and this customer gave you the list of requirements, and this includes OAuth2, then it is really required. Or you are developing clients (mobile, SPA) for some existing server application which only supports OAuth2. Then you are really required to implement OAuth2. Otherwise it is not required. It is up to you what authentication mechanism you implement.

What should you do? Take several solutions and compare them from different points of view: Security risks (what are possible attacks, how probable they are, what can be the costs in case of successful attack), the complexity and the costs of implementation of each method, the costs to maintain it, the costs of support, usability, performance, how much money you can actually spend on it, etc. Then you will see what is the optimal solution in your case.


There is no THE best practice. I have to repeat that: it depends on the context, it depends on what are your risks, on what are you requirements to usability, on what price can you pay, etc. This is very naive to look for simple answer.

  • In many companies the best practice is to use simple one step login where each application is itself responsible for the authentication. Any login issues are analyzed and resolved much quicker than in case of other solutions.
  • In many companies the best practice is to have a separate service for authentication, e.g. based on OAuth or based on JWT.
    • In many companies the best practice is to use 2F authentication based on OTP token like RSA SecureID token.
    • In many companies the best practice is to use 2F authentication based on authenticator app like MS authenticator or Google authenticator.
    • In many companies the best practice is to use 2F authentication based on tokens like YubiKey or Titan.
    • In many companies the best practice is to use 2F authentication based on photo TAN.

There is no THE best practice.

One of the very secure methods is using of 2F auth. with RSA SecureID or YubiKey. Are you or your customers ready to buy an RSA SecureID or YubiKey for every user? To pay for corresponding infrastructure? To pay for support (you need a stuff that will support users, answer their questions, analyze their cases, reset their blocked accounts, etc.)

Is it too expensive to you? This is important constraint. Then write that in your question, that your budget is limited with X USD

I mentioned usability. Is it too complex for your users? Do they want to have simpler login process? Then 2F is not for you. But again, write that in your question that usability has very high priority.

Do your users need SSO? If they do, then with OAuth or JWT you have SSO out-of-the box (the amount of code to implement is relatively small), where as with other mechanisms you have to implement much more. So OAuth or JWT can be preferable in such case.

What is your requirement on performance? Depending on your requirements and your infrastructure it can be that OAuth is too slow for your requirements. Test it on your real environment with some realistic load (number of users per second). Then you will see if OAuth fits your performance requirements.

  • @John: I have update my answer. Your question is very broad. You didn't define what you mean by secure. Probably you suppose that there is the only definition of secure. But that is not true. Just an example. A multi factor authentication that includes iris recognition, fingerprint scanner, SecureID token and password is more secure than authentication that uses only OAuth. But do you have budget for such authentication? You have not defined what budget per user you have. --> Please do that. Define how much budget you have...
    – mentallurg
    May 17, 2020 at 22:58
  • @John: ... The same about other points: For every my question extend your question and tell us what requirements regarding this you have. Then it will be easier to say what approach in your specific case could be optimal.
    – mentallurg
    May 17, 2020 at 23:01
  • @John: To I didnt need you to tell me that I define the requirements - but we need to know the requirements be able to answer the question.
    – mentallurg
    May 17, 2020 at 23:03
  • @John: If you have further questions, I'd suggest we continue that in the chat: chat.stackoverflow.com/rooms/214081/….
    – mentallurg
    May 17, 2020 at 23:09

Plain oAuth is used for delegating access, i.e. user X authorizes app A to act on their behalf when talking to your server. Since you state that this is not needed, plain oAuth isn't useful to you.

The authentication use case can be addressed by a protocol called OpenID Connect (OIDC). Implementing OIDC versus a proprietary authentication scheme is of a benefit if you want to standardize the authentication-specific interaction between client and server in a portable, interoperable way. You can use libraries that other people wrote and benefit from security research that has been done. OIDC is a superset of oAuth, i.e. oAuth 2.0 capabilities are integrated with the protocol itself. You can run an authorization code flow in OIDC and it'll look like oAuth but with tighter choreography and an additional token for authentication.

Choosing a particular flow in OIDC has security implications. The trade-off here is value of assets available to the attacker if access to your application if breached versus the cost of attack. Plain oAuth has holes, OIDC fixed some of them but many gaps remain. The Authorization Code flow assumes that a client such as your mobile app can protect a secret that it can then use for communication between between itself and the Authorization Server. This requirement leads to a very broad discussion of "what if" which boils down to a risk assessment of your particular app/assets/business.

Work is ongoing in OIDC universe to revise the spec and/or issue more guidance to protect implementers. A good read of a real-world OIDC application is a Financial-grade API (FAPI) profile developed by a working group under the umbrella of OpenID Foundation, it contains many examples of attacks and countermeasures.

  • I have taken a look at OIDC as well, which seems to be the authn flow on top of the OAuth2 authz flow. In my case, I'm not authorizing other apps to get access to my apis or customer data, only my own app, and even that, after the user has logged in and authenticated. What is confusing me is if OAuth2/OIDC is still applicable. Because the PKCE flow, which people suggest for native apps, is granting other apps access to your customer data which is not what I'm doing. Mine is a simple case of, the user logs in to the app, and once authenticated, can then do whatever he wants in the app.
    – John
    May 18, 2020 at 18:34
  • If you're comfortable with your implementation of authN/authZ and you don't anticipate having clients other than your own app, then you don't need oAuth or OIDC
    – identigral
    May 19, 2020 at 16:44

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .