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.