1

Can PKCE be implemented with both server and client generating public and private keys? Is it worth it? What I think is this flow:

  1. Client generates private and public key
  2. Client sends public key to server
  3. Server generates private and public key, generates random secret and encrypts secret with clients public key
  4. Server sends back to client encrypted secret and servers public key
  5. Client decrypts secret with his secret key, encrypts it again with servers public key and sends encrypted secret back to server
  6. Server decrypts secret with his private key and check if generated and now decrypted secret are the same

Am I missing something? Is this bad approach? Is this encryprtion/decryption/generating keys heavy to compute?

Fran Turkovic
  • 97
  • 11
  • I would strongly suggest moving this to [security.se] (by copy / delete). It does ask if it is possible to implement this, but it seems more about oauth-2 than programming. – Maarten Bodewes Jun 26 '22 at 13:20

1 Answers1

1

Your algorithm seems to be as secure as the PKCE standard. I don't think there's any additional value in encrypting the random strings. You also add one roundtrip to the server, as in PKCE it is the client who generates the initial random string.

Encrypting consumes resources and it's simple to implement it wrong. You also need support for encryption algorithms on both the server and the client side. Thus, I think it's just redundant to try to add that encryption to a proven standard.

Michal Trojanowski
  • 10,641
  • 2
  • 22
  • 41
  • Thanks for answering. How am I adding one roundtrip more? I have 2 roundtrips, just like Auth0 has. In standard PKCE you also need support for algorithms on both server and client since you need to hash random string in client and in the end on the server to verify. – Fran Turkovic Jun 27 '22 at 14:07
  • 1
    Yeah - I misread that. You are not adding a round-trip, but changing the place where the random string is generated. In standard PKCE you `can` hash the random string. This means that 1) it's not mandatory, and if a client is not able to hash it, it doesn't have to do it, and 2) it's hashing, not encrypting. Hashing is way simpler than encryption and you will find better support for sha256 than for encryption algorithms. – Michal Trojanowski Jun 28 '22 at 06:57