По какому принципу реализована единая аутентификация для нескольких приложений таких как Google Apps или Microsoft Office?
С превеликим удовольствием прочитал ответ-лекцию на вопрос Что именно идентифицирует посетителя сайта?. По пути, эта лекция отвечает на вопрос: "Какие стратегии аутентификации/авторизации наиболее популярные?" с примерным описанием алгоритмов. Ну а в этом вопросе я бы хотел рассмотреть более сложный случай - единая аутентификация на несколько приложений.
Допустим, мы разрабатываем аналог Google Apps или Microsoft Office. Наши приложения наподобие Microsoft Word (допустим, N-Docs) или Google Spreadsheets (скажем, N-Spreadsheets) можно скачать в виде нативных приложений или пользоваться урезанными веб-версиями. Поскольку эти приложения от одного производителя, то можно организовать единый центр аутентификации/авторизации.
Вопрос такой: какая стратегия аутентификации подойдёт, чтобы авторизация в одном приложении автоматически выполняла авторизацию во всех приложениях от этого же производителя?
Однозначно можно сказать, что такие возможно, потому что Google это как-то удалось (в случае веб-приложений точно, и, с большой вероятностью, в случае с нативными Andorid-приложениями). Но какая стратегия аутентификации тут используется?
- В случае веба, у нас куки хранятся отдельно для каждого сайта, и приложения у нас будут на разных доменах или поддоменах.
- В случае нативных приложений, у нас для каждого приложения будет отдельная папка внутри системной директории, а к папкам других приложений так просто доступа не получить.
Ответы (1 шт):
Очевидно, что для этого нужно, чтобы у приложений было общее хранилище конфигурации и информации об авторизации в частности.
В вебе, если у вас все продукты находятся на поддоменах, то им можно писать одну глобальную куку, которую всем будет видно по маске типа *.mysite.com. Так же есть уже упомянутая в комментариях технология Single Sign On (SSO) вики и на хабре. Кратко смысл там в том, что есть один сервер аутентификации, которому доверяют все остальные ваши приложения посредством сертификатов.
В любой ОС есть масса вариантов, куда это можно положить: как минимум директория пользователя. Ее могут читать и писать любые приложения запущенные от его имени как в windows так и в linux.
В частности в Windows есть папка appdata, которую могут читать все на свете. То же самое с веткой реестра HKEY_CURRENT_USER\Software\
В Linux общепринятой практикой является хранить данные по пути ~/.config/program_name а в MacOS вроде как в users\shared но насчет последнего не совсем уверен.
В обобщенном виде создаете там каталоги \vendor_name\program_name1, \vendor_name\program_name2 и т.д. и храните любые данные которые хотите шарить между приложениями в \vendor_name\. Само собой там не стоит хранить чувствительные данные в открытом виде, а только в зашифрованном, чтобы только ваши приложения смогли ими воспользоваться.
В андроиде есть специальные инструменты AccountManager и Keychain для хранения учетных записей и сертификатов. В iOS и macOS так же есть Keychain.