I am designing a webapp / mobileapp security stream where there are no passwords, only an authentication token sent to the phone via sms. The flaws in this?
Plan:
- The phone receives an sms link with a built-in invitation marker
http://domain.com/invite/ABCD - The user clicks, goes to the web application, which asks the user to install the mobile application (through a deep link that transfers the same token
myapp://invite/ABCD - When the application is downloaded, the
ABCD invitation token is sent to the server and exchanged for auth token and session token . auth token is stored permanently in local storage in the application.session token used for consecutive api calls and is valid for 24 hours, then auth token will be used again for exchange for a new session token
+---+ | | +---------+ <---------------------------------------------------+ | | Invite | | S | | Link | send invite | E | | rec'd | +---------+ +--------+ token | R | | via | |WebApp: | | +-----------------------> | V | | SMS | |deep | | ios App| | E | | +-> |linked +-> | | receiv auth & | R | | (token) | |to mobile| | | session token | | +---------+ |app | | | <----------------------+ | | |(install)| | | | | | | | | use session token | | | | | | for all api calls | | +---------+ +--------+ +---------------------> +---+
Questions:
- Is it safe to transfer the token through a deep link?
- Look at the other flaws of this scenario?
- Do I need an auth / session command? The rationale was that the session expires 24 hours after it was deployed over the network, but with more than ssl, maybe I only need an authentication token, which is stored forever, and is also used for api auth?
source share