4

Say I have an application written in some language and framework (Python + flask, for instance), and have a great deal of the functionality requiring login, and authentication via JWT.

Now I want to create a new module built as an app, possibly made in with different tools (django, for instance, or maybe even in a different language), in its own small separate project. This new mini app, which is more a module than a complete app, will receive some information from the user that was entered in the other app, but also was thinking about sending in the token, so that the user doesn't have to login again into this new "app". In essence, upon a certain condition being met, the user will be redirected to a new page (which is where the new app comes in) while sending the necessary authentication information and some other information. I have never done this before, but I believe/hope I could find a way to do it.

Would this be a sane/safe way of constructing this application, or am I exposing my system to great dangers? If the latter, what is the worst thing an attacker could do? Basically, is this in violation of any principles of security?

  • This problem is related to dev/architecture aspects more than security. I believe you will get more attention on stackoverflow than here – elsadek Jan 13 '16 at 18:29
  • If you're ever sending information that could be used to compromise someone's account, make sure the connection is over TLS/SSL. – sethmlarson Jan 13 '16 at 20:04
  • Are both flask and django running on the same domain? – Jonathan Jan 13 '16 at 20:07
  • I feel the question is on-topic, if you ignore the specific technological aspects. Security architecture certainly is a thing, and especially authentication / identity management architectures. – Steve Dodier-Lazaro Jan 13 '16 at 22:25
  • To clarify, yes, they're on the same domain. The tools, languages and frameworks are irrelevant. My question is there at the end: What risks will there exist from passing authentication tokens around between apps? Is this a no-no? – bitterman Jan 14 '16 at 0:10
2

Sounds like you're trying to implement something like single sign-on between two of your apps. In this case, you should be able to without any significant security issue.

Instead of authenticating with login credentials, you could have App B authenticate with App A's session ID. Obviously give the ID the same protections you'd give login creds, i.e. only send it over HTTPS.

The server behind App B still has to verify the authenticity of the session ID by checking it against the server for App A. As long as the authentication done in App A and session management done in both apps is consistent and robust, there shouldn't be any security issue.

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.