-1

Even though I'm working within .Net Core, this question is generally applicable to other platforms as well.

My question is to do with: Using a framework (such as IdentityServer) to manage implementation for Auth (Authentication/Authorisation) -- Vs -- rolling out your own implementation by following protocols. In this scenario, the 'rolling out your own' option wouldn't rely on any middleware to manage auth - all the required endpoints/services/data-access would be self managed.

Specifically, I'd like to know: assuming you have followed the protocol specs, what are the security concerns when rolling out your own implementation?

Edit 1: For further context, the only thing in question that requires implementation here, is a microservice responsible for authenticating using the OAuth authorisation code flow and nothing more. No sessions, as there’s no associated website with ‘protected resources’ and no ‘currently logged in user’. As per the authorisation code flow:

Authenticate: Endpoint to login and redirect to return url with authorisation code.

Question 1: Even if I use a framework, I still have to verify the client against those registered in my database, present the view with the login form, use CSRF action filters, validate input against my user database, and store the authorisation code in my database against the authenticated user for token exchange later. So what further security concerns arise from not using a framework?

Authorise: Endpoint to receive authorisation code and respond with tokens.

Question 2: Even if I use a framework, I still have to lookup the code in my database, check if it’s expired, store the access/refresh tokens in my database, and respond with the generated tokens. So again, what further security concerns arise from not using a framework?

Ash
  • 111
  • 6

2 Answers2

3

Security concerns are always very relative.

The major risk of rolling your own is doing a worse job than known good established frameworks. Which happens to be very common.

If you know what you are doing, understand the requirements, implementation details, are aware of security implications and have done your threat assessment, and have the time/budget/will to roll your own, then I see no issues with that.

Pedro
  • 3,911
  • 11
  • 25
  • Thanks for that. Among all the items you've listed, it's really the security implications that I'm most interested in, could you expand a bit more on that? As in, what could some of these security implications be? I realise it's relative like you say, but an example or two would go a long way in me understanding. – Ash Apr 30 '20 at 00:15
  • How long is a piece of string? Off the top of my head... There's simple aspects like session management, uniqueness, scope and lifetime of session cookies, simultaneous sessions, session tear-down at logout, preventing fixation, etc. If you're using a more complex authentication/brokering model like oauth, there's even more to worry about. Then there's the thorny issue of input validation, ensuring that interaction with other services is parametrised, etc. Access control wise you need to verify every single task on the server side against the user of the established session. ... – Pedro Apr 30 '20 at 09:16
  • I’ve edited my question to provide a more specific context. Are these still issues? – Ash Apr 30 '20 at 10:34
  • You can't have authentication without session control. It can be client-side or server-side but this is required to maintain authenticated state across multiple pages. Have you considered for how long those authorisation codes should be valid? Do you have in mind which frameworks exist and what they can do for you? You are facing as many security concerns as your code misses security features that a given framework might have - I don't think you can have an answer any more specific than this. Ultimately you can do a better job than the code in a framework. But also you can do a worse one. – Pedro Apr 30 '20 at 10:43
  • When I say no sessions, I mean no further session info other than that prescribed by the OAuth protocol itself. With the auth code flow, a session is completely defined by the tuple {auth code, access token, refresh token}, or am i mistaken? If you have further session info then that’s outside the scope of OAuth. And if I’m managing that tuple myself anyway even with using a framework, what exactly is the framework providing to me to realise OAuth? – Ash Apr 30 '20 at 11:30
  • As for how long...whatever the spec prescribes. Everything would be based on what the spec prescribes. In my experimentation with frameworks, they seem to offer about 99% of features that I don’t want and only about 1% actually has anything to do with the OAuth protocol itself. Which is all great, except the time taken to configure that 1% and make sure the other 99% doesn't somehow badly affect it, is more than the time needed to implement that 1% myself by following the spec. – Ash Apr 30 '20 at 11:36
0

Generally, the risks of doing something yourself is that you might screw it up. The risk of using someone else's implementation is that they screwed it up. Do you think it's more likely that you are more knowledgeable on the topic of authorization than whoever implemented the already available solution? If so, go ahead.

Why you might not want to roll your own:

There are plenty of reasons why you might want to go with a tried-and-true solution for authorization. First and foremost, it already exists. Just download it and it's ready to go.

Secondly, such a project will already have had it's fair share of bugs and bug fixes - including security critical ones. The longer the project has existed, the more eyes will have looked over it and the less likely it is that a critical bug is being overlooked.

Your project on the other hand is likely in-house only, so the amount of people looking over the codebase is magnitudes smaller - and thus your risk of a critical bug slipping by is higher.

During development of the already-existing solution, a lot of knowledge about proper authorization has been obtained by those developers, which may include things you don't foresee yet. After all, it is hard to know what you don't know yet. As a result, your developers will spend quite some time doing research and not actively developing your product.

Furthermore, using a third-party solution means you don't actively need to maintain the codebase for it, meaning your developers can focus more on your own solutions.

Why you might want to roll your own:

Your business could be in a niche in which you have very specific requirements and a one-size-fits-most solution just doesn't cut it. It would be easier to build something made-to-fit than to hammer something already existing into shape. Even then, it remains up to you whether the above-mentioned upsides of using an already-existing product outweigh the benefits of having a custom-made solution for your requirements.

As you see, all the indicators point towards using an already-made solution. If you wish to roll your own, you should have a very good argument for doing so. (This assumes production use. Implementing your own for the sake of learning is of course perfectly fine.)

  • Thanks for taking the time to post a descriptive answer. You mention "Just download it and it's ready to go". I have hardly come across any libraries that make it this easy. Take for example https://github.com/panva/node-oidc-provider and https://github.com/t1msh/node-oauth20-provider. Where does one even begin with these? I know how the OAuth flows work but these libraries make no sense to me. – Ash Jun 25 '21 at 09:48
  • Is it reasonable to assume that I'm more likely to miss a critical functional or security issue trying to configure something that doesn't make sense as opposed to self-implementing using understood protocols? And would this be a sufficient reason to roll your own? – Ash Jun 25 '21 at 09:49
  • For example, what are the security vulnerabilities (other than those mentioned) with simply doing this? https://thecodebarbarian.com/oauth-with-node-js-and-express.html – Ash Jun 25 '21 at 09:57