Search code examples
securityencryptionjwtaesrsa

How to do a Secure Authorization with RSA, AES and JWT?

First of all, let me explain what I imagine to do:

Let's imagine Bob want to get Authorization from Alice (Classic Example), in my example Alice is a server.

Let's imagine too that Bob and Alice already got an RSA key pair (4096).

So Bob's steps to do would be:

  1. Sign credits (Plaintext) with SHA512 and his private Key
  2. Encrypt Signed Data and Credits with AES CBC 256
  3. Encrypt AES Key with RSA
  4. Sending Datas to Alice

So Alice would do the steps above from in reverse to decrypt it and verify it's from Bob.

After Alice verifies that it's Bob, she generate a JWT Token and Sign this with her Private Key and return it in the response header authorization.

The JWT got a TTL of 3600.

So far so good but my question is now how do we protect the JWT from getting stolen ?

Sure it's Signed so it cannot be modified (Except if the attacker got the private key from server but my god then it's anyways over).

Let's imagine he would be able to break the HTTPS and stealing the token, put it in his Header and so he can Trick Alice to believe him until it expires and he need to send the credits again.

I was thinking about two Options:

Option 1: Always sending credits and decrypted to verify Bob.

But this would be costing Huge Perfomance each time of request and the benefits from JWT gets lost.

Option 2: Sending a Unique ID and confirm its from Bob's Device (Encrypted, so same Problem like Option 1)

What could we do to protect that?

Maybe I'm overthinking too much, like always, but I would really like to know what in that case would be a "Best Practice".

Thank you already for your Answers

Solution

  • So far so good but my Question is now how do we Protect the JWT from getting Stoled ?

    As you already found out, it's https

    Lets Imagin he would be Able to Break the HTTPS and stealing the token

    If someone is able to break HTTPS then we have a much bigger issue then a stolen header. By default you could trust https (except special cases in some countries)

    Let's assume the channel is not secure, you may for example sign every message separately (with an unsecure channel it's not enough to secure just a header).