Questions around OAuth Token Hashing

we are trying to implement hashing token for extra security as per below link

https://docs.apigee.com/api-platform/security/oauth/hashing-tokens

Please provide me the inputs on below questions

1) What is the verification working mechanism for this Technique. is Hashed token sent back to the client?

2) What Algorithm is recommended to use from SHA256, SHA384 & SHA512

3) Is there any Performance impact by applying hashing mechanism?

Solved Solved
0 6 464
1 ACCEPTED SOLUTION

1) What is the verification working mechanism for this Technique.

The verification is: the client sends the token, Apigee hashes the received token, and then performs a lookup using the resulting hashed value. If the resulting hashed value is found, the token is known. Then normal validation of the token proceeds: check for expiry, check for API Product match, check scope, and so on.

2) What Algorithm is recommended to use from SHA256, SHA384 & SHA512

Currently I know of no difference in the security of these hashes. Any of them are fine. If it were me I would use SHA-256, a hash which is well-tested and well-vetted, and for which there are no known weaknesses. There is a very low risk of hash collisions. SHA-256 is used extensively in many different systems. It seems a safe choice here. If any of that changes, you would be able to swap to a different hash later.

3) Is there any Performance impact by applying hashing mechanism?

We expect a negligible performance impact, even at high scale. The major performance impact associated with verifying a token is the lookup and I/O. That logic remains consistent, whether you are using hashed tokens or not. The major change when using hashed tokens is the computation of the hash. Computing a single SHA-256 hash will contribute very little to the overall cost of verifying a token.

View solution in original post

6 REPLIES 6

1) What is the verification working mechanism for this Technique.

The verification is: the client sends the token, Apigee hashes the received token, and then performs a lookup using the resulting hashed value. If the resulting hashed value is found, the token is known. Then normal validation of the token proceeds: check for expiry, check for API Product match, check scope, and so on.

2) What Algorithm is recommended to use from SHA256, SHA384 & SHA512

Currently I know of no difference in the security of these hashes. Any of them are fine. If it were me I would use SHA-256, a hash which is well-tested and well-vetted, and for which there are no known weaknesses. There is a very low risk of hash collisions. SHA-256 is used extensively in many different systems. It seems a safe choice here. If any of that changes, you would be able to swap to a different hash later.

3) Is there any Performance impact by applying hashing mechanism?

We expect a negligible performance impact, even at high scale. The major performance impact associated with verifying a token is the lookup and I/O. That logic remains consistent, whether you are using hashed tokens or not. The major change when using hashed tokens is the computation of the hash. Computing a single SHA-256 hash will contribute very little to the overall cost of verifying a token.

Thanks for your inputs @Dino-at-Google

Also please provide inputs on below item.

As per Apigee documentation oAuth token hashing @ edge level protection in case of Database security breach , in same case how to protect Consumer id & Secret ?

If you configure Apigee to hash tokens, Apigee does not also has the Consumer ID and secret.

If you are concerned with the integrity of the ID and Secret, you can avoid the use of the secret entirely by converting the grant type for your OAuth tokens.

For example, you could replace the ID/Secret model (as defined in RFC 6749) to a model that relies on a Public/Private keypair (as defined in RFC 7523). In this model, Apigee would store only the Public key. The client itself would be the only actor that possesses the private key. So any breach at Apigee would not disclose secrets.

I've previously produced a screencast and example on RFC 7523-style grants.

@marshg@google.com and @Rod Simpson FYI

Having said all of that, if you have concerns about a "database security breach" , I suggest that you review the Data Processing and Security Terms (DPST) document from Google, which describes the steps we take to protect the integrity of systems that host Apigee.

Hi @Dino-at-Google

Can you please specify which policy performs the actions ""The verification is: the client sends the token, Apigee hashes the received token, and then performs a lookup using the resulting hashed value"?

Currently we have implemented the oUATH hashing for OPDK and after successful execution of 'VerifyAccessToken' policy ( with non-hashed token), the resulting value of the variable 'apigee.access_token' is changed to a hashed token value, is this expected behavior?


This is currently posing a problem as it fails for our custom cache lookup policy which relies on non-hashed token reference ("flow.oauth.access_token")

yes this is the expected behavior.

If you need to use the actual unhashed token, then you will want to use ExtractVariables to get the bonafide token from the Authorization header, and use THAT to perform the cache lookup.

I am not sure if you can use ExtractVariables to set apigee.access_token. That variable may be readonly. But it's worth a try. That would let you get the actual token in the variable you expect. Effectively subverting the whole point of token hashing, but anyway, that seems to be what you want.