[OAuth2 Provider] Encryption of Tokens in DB

Forge Component
Published on 2019-11-18 by Leonardo Fernandes
2 votes
Published on 2019-11-18 by Leonardo Fernandes

I've been looking at the 2.0 version of this application and very much appreciate the amount of effort put forward here.  

I did have a question as to the reason the encryption of the access and refresh tokens was removed and allowed to be stored in plaintext in the database?  This seems to go against best practices of keeping them confidential in transit and in storage.  

That's a good question! Short answer: I had no time to re-implement it.

Long answer: there were a few problems with that logic:

  1. OAuth2 Provider version 0.9.1 was not compatible with the latest version of CryptoAPI. Namely, CryptoAPI had some breaking changes on version 2.0.0, and removed some APIs for deterministic encryption that were used by OAuth2 Provider.
  2. The encryption took advantage of OutSystems' private key. That key is meant to prevent data tampering, but it shouldn't be used to secure sensitive information. See below the private key on one of my sandbox environments - as you can see it's stored in base64 and when decoded it's only 16 bytes in length.

  3. There's no way to change or revoke the private key. If the OutSystems private key is leaked (just like mine leaked in the picture above), then the encryption would be defeated.

If I had time, what I would do is use a non-reversible function (hash+salt) to secure the storage of the ClientSecret. That's similar to how the Password field of the user is stored. In fact, we could use the same action from the Users module (EncryptPassword) to do that.

This particular feature was low in my priority list because we are using full database encryption.

It's not a big feature, if you or anyone else wants to contribute. Just the UI would need to change a little, and the logic that validates the ClientSecret.

Chris, I've published a new version that implements my suggestion above.

That's great!  I'll take a look.