2

I'm trying to build a single sign on system that connects app A to B and B to A. Unfortunately, the option to use OpenID/OAuth/SAML is not possible right now, so I am building a basic solution myself, here's how it goes:

  1. User logs in to App A
  2. User clicks on "Go to App B" link
  3. Server for App A generates a JWT token containing the user ID and expiry date, saves a hashed output of this string in a shared location (like Redis) and redirects to App B's endpoint along with the token
  4. App B hashes the token it received and checks if it matches the hash that's in the database. If it matches, then it checks to see if the token has expired and rejects/accepts the request based on the evaluation.
  5. App B makes a call back to App A along with the token and a "SUCESS" message.
  6. App A again hashes the token and checks in the database to see if the two hashes match. If they do, then App A issues a temporary authentication token to the client.
  7. For all future requests to App B, App A passes along the temporary token (which App B validates against a secret key) and App B grants the request (if not expired and rejects if expired)

This is the approach that has been implemented and functional, but I wanted to know how secure is the logic. Do you see any obvious security concerns with this implementation?

|improve this question
  • Sorry, but I don't understand, what's the role of App B server? Currently it seems like Server A generates JWT, and then you use Server B to validate the JWT, which is useless, since if server A generated it, it must be valid. JWT are also supposed to be stateless, you don't need to share anything with server B for it to be able to validate the JWT, they both just need the secret key. I feel like there's something lacking from your explanation, but I think that JWT definitely being misused here. – FINDarkside Apr 22 '18 at 10:08
  • This seems a bit over-complicated. Can you prehaps explain what is the reasoning behind each step, as I believe you could stop after step 4 (+ verify the token based on secret before checking hash). – Peter Harmann Apr 22 '18 at 12:47
  • @FINDarkside App A can request data from App B's server, which means that App B should know that the request for data is genuine. The idea is that once the first transfer of control from A to B has been approved, a temporary, trustable auth token should be generated and used with each data request that is sent to B. Using the token to validate the request would be simpler than regenerating the token from A and re-validating it on B's side. – DemCodeLines Apr 22 '18 at 16:16
  • @Peter Harmann please see the comment above. – DemCodeLines Apr 22 '18 at 16:17
  • 1
    You could just create the JWT on server A, and then when the user sends it to server B, the server validates it with the private key which is used on both of the servers. So in my opinion you could already stop after step 3 unless you're doing something wrong. There's no need for server B to access any shared database, that's the whole point of JWT, to be stateless. If you wish to do it the way you're currently doing, I don't see much benefit of using JWT over a simple session token. – FINDarkside Apr 22 '18 at 17:24
1

As the colleagues have pointed out, your SSO logic is sound here. To improve it a bit and make it faster perhaps, you may end at Step 3 as long as you use the private key in Server B to validate the JWT generated by Server A.

Of course, we are assuming a few things here at each step, for example:

  1. Encryption => we are assuming the whole system is using a robust encryption mechanism to pass these JWT tokens back and forth and are safe from prying eyes.

  2. Server A and Server B validates input from each other - in other words, Server B does not implicitly trust that Server A will always send JWT tokens, because requests/responses can be intercepted.

  3. Denial of Service Attacks - the system can fend off these attacks.

  4. Speed - sufficiently fast

  5. Alert admin of other security attacks

|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.