This document describes a mechanism to authenticate user using one time tokens (auth_code) generated by APG [1] which are used as a new password for a new session delivered to a user over 3rd party or own communications channels (ie. email, Jabber, Twitter, OpenID).
Other goals are to skip registration process, provide an user an OpenID, be an OpenID relying party and to implement OAuth authentication for REST APIs.
This document is a specification for a project of Marek Kuziel called djauthy, however could be used by other web developers who would like to explore new ways of authentication for the Internet.
djauthy was presented for the first time at the April 2008 Python Meeting in Christchurch, New Zealand.
It is up to user to consider any security risks of anything following. There are security concerns for any of covered ways of communication between the relying party and one time token provider.
Be aware of potential man-in-the-middle attacks, phishing attacks, etc. It is called simple authentication for a reason.
Use at own risk.
Implementations of OpenID Provider and Relying Party and OAuth could be found on the Internet.
APG generated auth_code based implementations send a message containing the auth_code to the user and replace user's password with the auth_code.
auth_code should be valid only for a certain period of time. This period should be configurable for each implementation and have a prefix DJAUTHY_EXPIRY_TIME_[IMPLEMENTATION_NAME]
To obtain the auth_code user must provide an id.
Then we perform check if user exists and an account discovery (see discovery section).
In case the id does not exists in the system, new internal user is created and message about creating of the new user is send.
User is presented auth_code form. Form element used should be a password input field.
When user enters auth_code into the form and submits the form auth_code is treated as user's password and normal authentication happens.
Any authentication mechanism that is able to (communicate with | send message to) user could be used.
Note: we need more implementations.
Purpose of discovery is to increase usability and simplify the authentication process.
We could have two modes available as option DJAUTHY_MODE
Authentication imeplementations should be configurable into multi-factor authentication levels.
Configurations could be stored in a database and integrated with permissions / groups mechanism.
MultiFactorConf model of configuration should be something like
MultiFactorUser model should be model for verification
Verification of each factor should be stored in MultiFactorUser model.
Cron job is needed to remove not valid records in MultiFactorUser model. Expired records should be removed.
If any of configured permissions/groups is required we check againts user's records in MultiFactorUser model and if everything seems valid we allow them to perform the action.
Authentication of a user happens through one of the user's accounts.
When user comes for the first time and her account does not exist in the system a new inactive user and inactive user account is created. If possible user is informed via message.
After successful authentication user is activated in model User and system also activates user's account
User models is Django django.contrib.auth.models.User model.
Accounts are user's accounts for each imlpementation. User can have many account of each implementation.