Лучший способ беспрепятственной и тихой аутентификации со вторым веб-приложением при входе в первое?

Question

Стороннему приложению (A) необходимо связать пользователей с нашим приложением (B) и войти в систему за кулисами.

Оба приложения работают независимо со своими системами аутентификации. Пользователи имеют общий уникальный идентификатор, но имеют разные токены аутентификации (имя пользователя / пароль / ключ и т. Д.) В каждом приложении.

Два усложняющих фактора:

1. Один пользователь приложения B может связываться с двумя пользователями приложения A (например, обе учетные записи в приложении B будут перенаправлять и входить в одну учетную запись приложения A)
2. Пользователь приложения B может фактически не иметь никаких существующих токенов авторизации, только его личная запись и идентификатор пользователя, но мы все же хотим иметь возможность войти в систему, если они поступают из приложения A.

Моими первыми мыслями были OAuth - но я не думаю, что это сработает, поскольку некоторые пользователи не имеют учетных записей приложения B и, следовательно, не смогут войти в систему, чтобы предоставить доступ приложению A (см. Пункт 2 выше).

Самый простой способ, который я придумал, это:

1. Каждое приложение имеет предварительный общий ключ, например, "LOLS"
2. Общий алгоритм хеширования генерирует независимые идентичные токены, например хеш (PSK + UID)
3. Приложение B хранит хешированные токены для каждого пользователя
4. Приложение A отправляет POST с UID и хэшированным токеном в приложение B, которое использует его для идентификации и аутентификации пользователя

Проблема в том, что это ужасно небезопасно. Любой, кто знает предварительный общий ключ (любой системный администратор) и идентификатор пользователя (еще раз, любой системный администратор), сможет аутентифицироваться как ЛЮБОЙ пользователь, что недопустимо.

У кого-нибудь есть решения? Я бы предпочел существующие стандарты, но я открыт для индивидуальных реализаций. На самом деле мы не можем ничего сделать для приложения B, кроме как заставить их использовать любой предоставляемый нами API.

Answer 1

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

Вы создаете веб-сервис для звонков. Это может быть то, что вы заблокируете, как вам нравится, в том числе путем ограничения доступа к их IP-адресу на брандмауэре. Они отправляют UID на ваш веб-сервис, который вставляет в таблицу на вашем конце и возвращает какой-то случайный токен (мы случайно сгенерировали guid). Ваша таблица связывает токен с UID (в текстовом виде), который они отправили, и с датой.

Их приложение отправляет вам случайный токен вместо UID, вы используете его для поиска UID и отметки времени, чтобы убедиться, что срок действия случайных токенов истек через минуту или около того. Даже если кто-то просматривает вашу таблицу каким-либо образом, чтобы получить список недавно предпринятых UID, он не позволяет им аутентифицироваться, если только они не могут выполнить его очень быстро !