Я занимаюсь разработкой приложения SaaS поверх PaaS (Google App Engine). Мои SaaS будет иметь два пользовательских интерфейса:Рекомендации по проверке подлинности для SaaS over Paas (GAE) Сценарий
- Веб-интерфейс
- Mobile App на основе
Веб будет навороченный, тогда как мобильное приложение будет иметь существенные и/или часто используемые функции.
Мобильное приложение будет ссылаться на службы RESTful для выполнения бизнес-логики.
Этот SaaS будет нацелен главным образом на физических лиц с помощью мобильных приложений; однако может существовать случай использования, когда эти лица могут образовывать группу и действовать как компания. Итак, учитывая это, я рассматриваю два объекта: Account (Tenant) и User. Я рассматриваю возможность установления отношений «многие ко многим» между этими двумя объектами, поскольку один пользователь может быть частью нескольких учетных записей (маловероятно, но не может быть исключен), и, конечно, одна учетная запись может иметь несколько пользователей.
Я хотел бы знать, лучшие практики для проверки подлинности по такому сценарию:
- Должен ли я использовать при условии аутентификации Google, или я должен реализовать свою собственную проверку подлинности? (Я все еще изучаю предложение OAuth и Google для аутентификации.)
- Я думаю, что для веб-интерфейса, имени пользователя и пароля через SSL было бы достаточно. Но, не уверен, можно ли это применить к мобильному приложению?
- Могу ли я избежать ситуации, когда мне нужно хранить учетные данные в мобильном приложении?
Заранее благодарим за любую помощь, которую вы можете предоставить по этому вопросу.
A
Благодарим за ответ, который значительно упрощает аутентификацию в этом сценарии. Однако у меня есть вопрос в отношении вызова службы RESTful. Как мобильное приложение может безопасно называть услугу RESTful? Я рассматриваю двухногий OAuth, но затем он добавит еще один учетный список в список, не так ли? Каково было бы ваше предложение? Спасибо. A. – user2663512
Я не специалист по OAuth (но я предполагаю, что это связано с двухфакторным auth?). В принципе, вы собираетесь использовать HTTPS. Тем не менее, он очень смущен, чтобы оставить какой-либо чувствительный материал в URL-адресе для запросов GET. Один общий метод проверки подлинности RESTFUL, похоже, основан на токенах, как указано здесь: http: //stackoverflow.com/questions/9201755/restful-service-authentication – Zerkz