1

I am building an authentication system to be used within a company's private network. I do not administer this network, and I know very little about the setup, but my basic understanding is you must be on a local machine or VPN in to access it.

The system/services consists of:

  • An OAuth server that uses JWT's as access_tokens
  • A private multi-page javascript application served up by a PHP backend
  • A set of private APIs
  • A public application that will utilize our internal services (OAuth server and API's)

For users of the public application I intend on storing their access and refresh token within a server side session, and all communication to our API's will be done from the backend.

For users of our private network (employees) I've opted to store their short lived access_token (10 minutes) AND refresh token (1-4 weeks) inside of cookies. The cookies are set as HttpOnly, secure, and SameSite=lax. I'm still struggling with the most secure way to use these cookies to authenticate users across all applications and APIs. Here are the two ideas I have at the moment:

  1. Originally I just wanted all apps/services to simply accept the cookie as a valid authentication method. but I now understand this leaves me open to potential CSRF. So I would have to implement some type of stateless CSRF protection.

  2. My second plan was to only allow the content serving applications to accept the cookie as an authentication method. Which would limit CSRF vulnerabilities to application content only. I would then pass the JWT to the application by embedding it into the actual HTML page, which could then be sent through Authorization headers to the APIs. I realize this is not secure storage of a JWT, and it could be compromised with CSRF. But my thinking was that being an internal network, the JWT's are essentially useless to anyone on the outside.

Are these designs insecure? Particularly the second one, which involves embedding access_tokens into the html/javascript page? Is there a better approach that I am missing?

  • 1
    Without trying to sound condescending in the slightest, if you consider yourself a "beginner when it comes to security", then you might not be the right person for the job of designing a company-wide authentication system from scratch. Security is hard, and it only takes one subtle design flaw to give an attacker full access to your company infrastructure. I would highly recommend you not to design such a critical piece of infrastructure yourself and outsource it to professionals with more experience. – MechMK1 Sep 25 '19 at 13:21
  • Point taken. I realize I am not the most qualified for this job, although I am the only one capable of it in this small company with limited budget. I will bring it up, but for the time being I will have to continue trekking along. – Matt Sep 25 '19 at 13:32
  • I understand that small companies don't have the budget for such things usually, but your boss needs to understand that this is a big risk that they are taking. Especially since flaws in the solution usually can't be detected without proper monitoring, so you further risk running into arguments such as "It has been working fine so far, so why bother?". – MechMK1 Sep 25 '19 at 13:38
  • Tell your boss that the limited budget will be even more limited when (note: when, not if) a flaw on the authentication process leads to privilege escalation, code execution and a ransonware is deployed. – ThoriumBR Sep 25 '19 at 16:02
  • Well for my own understanding and learning purposes then, could I please get some insights into why the above is insecure? – Matt Sep 25 '19 at 16:30
0

If you have done some design work, the best would be now to do some Threat Modelling session, where you could identify all possible flaws. AuthN and AuthZ design is hard and requires experience.

I will not do the Threat Modelling session for you as 1) I do not know all the context and requirements 2) this is not a place for that. But from my experience, I can give you some advice.

First, please remember about the Security in Depth principle which states you should secure your solution on every layer. There is nothing worse than to follow the Security by Obscurity with the private area. You cannot rely on that it is not visible for public users or is not accessible, as this is in private network. If the public application is somehow connected with private backend/API and private app is using the same backend API, you should consider both at the same security level.

Second, try to design a solution where you never send the security token (access or refresh) to the user-agent (browser) as this is mostly considered insecure. Securely storing tokens at the client-side is very hard to achieve. If you design the web app with a PHP backend, stay with the tokens at the backend and use it from there. This is correct for both public and private app.

You have not wrote explicitly that you will be using the OAuth2 and OpenIdConnect so if you consider using access token please remember about those specifications and strictly follow those during implementation. Use certified software for AS and if you have possibility certified client's libraries. OpenId Certification

| improve this answer | |

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.