enigma: How to sign and verify tokens or let's use HMAC-SHA256

[aeneasr]

Right now, tokens are going to be saved as a hashed version. I think there should be one more step.

Issuance:

1. Create random > 128bit key
2. Create signature by hashing the key with a secret encryption key using HMAC-256)
3. Use the signature as primary key for the request session end persist it in the store
4. Issue {base64_encode(key)}.{base64_encode(signature)} to client

Validation:

1. Decode base64 values
2. Validate that key matches signature the key and the secret encryption key
3. Look up key claims (e.g. expiration date or response types) in the store using the signature
4. Finish request

The secret encryption key should in fact be {global-secret}-{app-secret} making client validation easier and automaticall revoking tokens when secrets are changed.

This has upsides:

• We could preemptively discgard any tokens that have an invalid signature (and thus remove database workload).
• Resource servers could validate the tokens if they know the secret key without establishing a network connection.
• An attacker knowing the secret encryption key would still not be able to restore a token's key from it's signature.
• An attacker would require the secret encryption key and have somehow gain write permissions on the database to forge and inject a valid token or authorize code.
• If the secret encryption key is believed to be compromised, changing it will invalidate all tokens including those who are possibliy forged
• If the mechanism for generating the secret key is believed to be weak, it can be replaced with a new one making all old and insecure tokens invalid
• If the client secret is changed, all of it's tokens bekome invalid giving the power to handle and invalidate lost client credentials in a timely fashion.

It should be noted that the secret encryption key is replaceable. Clients are expected to handle revoked tokens if they implement OAuth2. Replacing the current secret encryption key with a new one would render all previously generated tokens to become invalid. Clients should handle this by re-authorizing.

The more I think about this, the more I like this idea.

[danielchatfield]

I know you've closed this but thought I'd add my 2¢.

Could you not support the use of an asymmetric signature scheme? You could have systems that need to check the validity of a token but shouldn't be trusted with the key that can sign them.

[danielchatfield]

Example use case: you might want a high performance proxy to drop all requests with invalid tokens to mitigate a DDoS attack but would not want the secret to be on an internet facing box.

[danielchatfield]

Just to be clear, I think HMAC-256 is perfectly fine but would like the interface to be provided in a way such that it would be easy to swap it for an asymmetric DSA.

[aeneasr]

Definitely appreciate the cents :)

Yes, I think it is a good idea to support different token generation strategies. This is already possible, because Enigma is an interface and the authorize code plugin uses that interface, not a concrete implementation of it. You can switch the code generation strategy (and later access token / refresh token) easily by replacing the dependency in your fosite factory method.

It should however be noted that cryptographic token validation on the resource provider side does not equal token validation by lookup. OAuth2 was designed with revokable tokens in mind, which always requires a database lookup. It fits however very nicely in to your use case:

Example use case: you might want a high performance proxy to drop all requests with invalid tokens to mitigate a DDoS attack but would not want the secret to be on an internet facing box.

Thanks for your input, I really appreciate it!

[aeneasr]

Check out the factory method of the authorize endpoint in the tests. I think this is what you asked for, isn't it? :)

[danielchatfield]

Looks good to me :)

[aeneasr]

Awesome, closing this then :)

[aeneasr]

I just stumbled upon https://tools.ietf.org/html/rfc6819#section-5.1.4.1.5

5.1.4.1.5. Use of Asymmetric Cryptography
Usage of asymmetric cryptography will free the authorization server
of the obligation to manage credentials.

[aeneasr]

JWT are encoded as a JSON object that is used as the payload of a JSON Web Signature (JWS) structure or ...
Source

And JWS support assymetric algorithms like RS256.

@danielchatfield what do you think of using JWT instead of DSA for your use case?

Also take a look at #16

[danielchatfield]

👍