SMAauth

SMAuth is a simple mobile (and desktop) apps authentication schema. SMAuth is most suitable to run over HTTPS.

The whole idea here is to keep the client out of persisting the username/password and instead persist a token that will expire.

SMAuth is more suitable for Mobile and Desktop applications where the Resource owner (who know the username/password) is the client himself.

Overview

• The Mobile/Desktop Application (client) send to the server username, password and deviceId (UDID for Mobile, MAC Address for Desktop apps). (Auth service)
• The server try authenticate the client and if authenticated, it returns the sessionId, else it returns 401 (UNAUTHORIZED).
• The client store the sessionId to communicate with the server for subsequent requests (Invoke service).
• If the client doesn't communicate with the server for n time or if n time have passed (depending on the SESSION_TIMEOUT_SCHEMA more on it later) the server will send 401 (UNAUTHORIZED).
• The client may remove the persisted sessionId.

Details

• Service consist of two services Auth and Invoke.
• Auth is responsible for authenticate the user using username, password and deviceId combination.
• Auth parameters: username, password and deviceId.
• The Server will authenticate the client until session timeout.
• The authentication means the server will check the username and password, and if valid, it will save the current sessionId with the deviceId in memory/file/database where the key is sessionId and value is deviceId and return the sessionId to the client.
• since the sessionId is unique, this will guarantee that each client will have its own sessionId/deviceId combination saved on the server.
• The session time out controlled by the SESSION_TIMEOUT_SCHEMA.
• SESSION_TIMEOUT_SCHEMA is either FIXED or PER_USAGE. FIXED means after n time the session will be revoked no matter if the user use the session or not. PER_USAGE act exactly HTTP Session.
• Invoke is responsible of invoking the business methods after the client has been authorized.
• Invoke parameters: sessionId (should send as cookie under the name "JSESSIONID") and deviceId.
• The client need to send the same deviceId that is used in Auth request with each subsequent Invoke requests.
• Only one Mobile Device (Identified by deviceId) can have the same sessionId. If two mobile devices with the same Device Id (which will never happen) send two Auth requests to the server, the server will revoke the auth of the former one.

Participants

Although it is a very simple idea, but I'd like to mention that I am not the only idea owner, we are three behind this idea, although for now I am the implementer. It is me, Moutaz and Esmat.