Дмитрий Энтелис

1) Если хочется хранить токены в памяти - можно взять Redis, он отлично для этого предназначен.
Из мемкеша будут периодически теряться данные и придется городить огород с хождением в sql.

2) Стоит это все делать или нет - зависит от Ваших объемов и самого сервиса, насколько введение такой авторизации его ускорит. В неком сферическом случае я бы не парился если rps меньше 200-300

DevMan

Профукал телефон/номер/вырубился роуминг (или его вообще нет) - давай досвидания.

Как показывает практика - это вообще не проблема.
Номер телефона восстановить гораздо проще чем украденную почту.

Я вижу несколько других проблем:
1) Затраты на отправку смс. Авторизация это достаточно частое событие в общем случае, смс надо будет слать много.
2) Пользователи с опаской относятся к идее ввода на сайты чего либо пришедшего по смс, все эти истории с подписками чему то научили все таки.
3) Долгий процесс авторизации. Пока смс придет, пока юзер перепишет код. Если такие условия будут на каком то обычном сайте - я как пользователь плюнул бы и ушел.

В целом я не вижу причин почему авторизацию надо делать именно через одноразовый код.
Если приложение с повышенными требованиям по безопасности - нужно использовать и логин пароль, и одноразовый код (т.к телефон могут украсть и авторизироваться)
Если приложение обычное - лучше использовать вход по номеру телефона и паролю, а смс использовать для восстановления пароля или отправки пароля при регистрации.
PS

авторизован, ip занесен в базу, зашел с того же автоматом авторизован, нет отправляем новый код

Лучше ставить куку и проверять её наличие, дополнительно сверяя IP если кука есть.
UPD
Kostik_1993 , DevMan : подтверждение любых критический действий через смс с одноразовым кодом - давным давно стандарт в банковской индустрии и понемногу проникает в остальные. Двухфакторная авторизация (по желанию пользователя в не критичных случаях и принудительно - в критичных), восстановление пароля - отличные кейсы для смс.

По сути у нас сейчас нет способа иначе проверить пользователя.
Или приложение на ios с биометрией, или одноразовые смс.
При выборе нормального оператора связи - номер телефона это единственный способ связи с пользователем который пользователь не может неосознанно потерять на долгое время.

Пользователь вам отправляет свой логин/пароль.
Вы по нему генерируете случайный токен, кладете его в базу, отправляете пользователю.
Для полного счастья хорошо всю работу с api вести через https, в этом случае без серьезной подготовки никто этот токен не украдет.
Мне кажется что в 99% случаев этого вполне достаточно.

Альтернативное решение - не использовать токен, а использовать в каждом запросе хеш, генерящийся на основе данных запроса и пароля пользователя (при этом сам пароль не передается)
условно что то вроде

$hash = md5($password . "method=users&rand=23084723984623947&limit=10");
$url = 'http://api.site.ru/users?rand=23084723984623947&limit=10&'.$hash;

Даже если запрос будет скропрометирован - максимум что получится сделать это его повторить.
С учетом того что при определенных методиках генерации rand можно сказать что rand должен быть уникальным для пользователя к примеру за месяц - получаем достаточно надежную историю.
И да, это велосипед, как это называется правильно к сожалению не знаю, думаю другие подскажут :)