Разработвам собствено приложение за iOS, което използва някои уеб услуги, предоставени от моя бекенд сървър. Някои услуги се нуждаят от удостоверяване на потребителя и изискванията са удостоверяването да се извършва или от потребителски акаунт, създаден директно на сървъра, или с Facebook, или с Twitter.
За да опростят нещата, създателите на бекенд сървъра са решили, че сървърът ще извършва удостоверяване от страна на сървъра с FB или Twitter (или разбира се използва свой собствен механизъм за удостоверяване, ако потребителят избере да влезе директно с акаунта на сървър) и ми върне собствен токен за достъп на сървъра, след като удостоверяването е успешно, независимо от това кой поток (FB/Twitter/собствен) е следвало.
Така че текущият поток на удостоверяване изглежда така:
- Отварям уеб изглед от собственото приложение за iOS с URL адреса на страницата за вход. Страницата има бутон "Вход с FB" и "Вход с Twitter", както и малък формуляр за потребител/пропуск за директно удостоверяване.
- Ако потребителят избере „Вход с FB“, сървърът пренасочва уеб изгледа към страницата за удостоверяване на FB приложението, където потребителят трябва да въведе своите идентификационни данни за FB. Същото се случва и с Twitter.
- URL адресът за пренасочване на FB/Twitter е зададен директно към сървъра, така че след като FB/Twitter успешно удостовери потребителя, той изпраща токена за достъп до сървъра. Сървърът създава нова потребителска сесия, генерира свой собствен маркер за достъп и го изпраща към URL адреса за пренасочване на собственото приложение.
- Ако потребителят въведе директните идентификационни данни на сървъра във формуляра, сървърът просто създава потребителската сесия, своя маркер за удостоверяване и го изпраща към URL адреса за пренасочване.
- Родното приложение наблюдава уеб изгледа чрез своя делегат и непрекъснато търси предварително дефинирания URL адрес за пренасочване (нещо като
http://myserver.com/authentication_success/?authToken=xyz). Ако заявката, предадена вshouldStartLoadWithRequest, съответства на този модел, тя извлича authToken и затваря уеб изгледа. - Маркерът за удостоверяване ще бъде предаден на всяка заявка за услуга, която се нуждае от удостоверяване на потребителя.
Въпросът ми е: валидна ли е тази архитектура и дали ще бъде приета от Apple? Притеснението ми е, че тъй като в определен момент потребителят може да бъде помолен да въведе своите идентификационни данни за Facebook в моя уеб изглед, теоретично бих могъл да получа достъп до паролата му за FB чрез делегата. Може ли това да е причина да отхвърлите приложението?
Намерих този документ: https://developers.facebook.com/docs/facebook-login/login-flow-for-web-no-jssdk/, което говори за това, че може да искате да използвате базирано на браузър влизане за „поток на влизане, използващ изцяло сървърна страна код“. Може ли моят случай да се приложи към този случай?
