Um, eek?<p>You can't safely use SHA256 in that construction. The hash is simply the value of the SHA256 internal state after the last block. An attacker can take that hash and resume "hashing" from that point, adding additional data to the original data.<p>That attack is called "length extension", and it's the reason we have the HMAC construction. Here, I think you want the HMAC-SHA256 of the filter and user ID, with the API key as the HMAC key.
I suggest you investigate oAuth instead of rolling something yourself. That's how Google, Facebook, and Twitter solve this problem. Pick whichever version suits your needs,<p><a href="http://oauth.net/core/1.0a/" rel="nofollow">http://oauth.net/core/1.0a/</a> (2009)<p><a href="http://oauth.net/2/" rel="nofollow">http://oauth.net/2/</a> (2012)
I just use the normal cookie sessions over HTTPS. Rolling your own encryption just seems like a bad idea, and I don't understand why people do it.
Sounds like this is not an <i>authentication</i> but an <i>identification</i> protocol applied for a very limited API calls rate-limiting use case. While there are some question about this use case as well (e.g. it there is a DOS attack possible against legitimate clients if the secured_api_key is leaked), it might be practical and acceptable in some limited set of cases.<p>The danger here is that the same protocol will be used for access control use cases for which it is not suitable (for a variety of reasons). A very good documentation (including thread modeling with attack vectors analysis) should be added to make sure this kind of mis-use does not occur. I would also change the title since it is too ambitious and misleading.
Sounds like you've implemented a type of JWT: <a href="http://openid.net/specs/draft-jones-json-web-token-07.html" rel="nofollow">http://openid.net/specs/draft-jones-json-web-token-07.html</a>
This is what the implicit grant is for in OAuth: <a href="http://tools.ietf.org/html/rfc6749#section-1.3.2" rel="nofollow">http://tools.ietf.org/html/rfc6749#section-1.3.2</a>
I believe Keen.io does something very similar to this as well. iirc they use hashed API keys with some user ID in order to show user specific metrics.<p>I always thought there approach was interesting. Kudos for coming up with something very similar.