Yii ApiAuth Extension ¶
Authenticate a (REST) client through Http Authentication Methods like Http Digest or Http Basic (or implement your own authentication scheme)
Most webservers, like Apache or IIS support different types of HTTP authentication, but they can be difficult (if not impossible) to integrate with a custom user account source, especially one that is implemented in Yii. This extension uses only Yii, PHP and MySQL and should be easy to integrate in an existing Yii based Authorization scenario.
Even though this extension can be used for virtually any authentication scenario, it is mostly suitable for automation, for example in REST requests. Hence it's name apiAuth.
Yii comes with an extensive built in authorization scheme and many great extensions like Rights, Auth or yii-user that you can use alongside this extension. @see http://www.yiiframework.com/doc/guide/1.1/en/topics.auth
- For server-to-server communication (REST API's)
- Secure: supports Digest authentication (used by default) or Basic authentication, which is less secure, but can be very usefull (and mainly faster) when you're already protected by SSL.
- Easy to implement: intuitive yii-like filters & rules for controllers
- Focus only on authentication. Leave authorization to other (or already implemented) components/extensions
- Yii 1.1.12 or newer (at least 1.1.13 when supporting qop: auth-int, older versions might work, not tested)
- PHP 5.3 or newer
- A database system like MySQL (other database systems might work, not tested).
See the README on GitHub.
Important Notes ¶
To quote section 4.14 from RFC 2617:
By modern cryptographic standards Digest Authentication is weak. But for a large range of purposes it is valuable as a replacement for Basic Authentication. It remedies some, but not all, weaknesses of Basic Authentication. Its strength may vary depending on the implementation. In particular the structure of the nonce (which is dependent on the server implementation) may affect the ease of mounting a replay attack. A range of server options is appropriate since, for example, some implementations may be willing to accept the server overhead of one-time nonces or digests to eliminate the possibility of replay. Others may satisfied with a nonce like the one recommended above restricted to a single IP address and a single ETag or with a limited lifetime. The bottom line is that *any* compliant implementation will be relatively weak by cryptographic standards, but *any* compliant implementation will be far superior to Basic Authentication.