Come impedisco agli utenti di utilizzare le mie app iOS a meno che non siano state autenticate su un server?

0

Ho cercato di trovare una risposta a questa domanda per un po 'di tempo, ma i miei sforzi sono stati infruttuosi. Ho trovato diversi articoli e domande sull'autenticazione offline, ma questi riguardano principalmente la memorizzazione delle credenziali di accesso localmente dopo che un utente ha già effettuato l'accesso una volta online.

Il motivo per cui voglio implementare questo sistema è che alcuni gruppi dovrebbero avere accesso gratuito alle mie applicazioni, mentre altri che non rientrano in questi gruppi dovrebbero pagare per utilizzare queste applicazioni. Per quanto ne so, questo non è supportato dall'app store. Inoltre, alla fine la serie di applicazioni dovrebbe supportare altri dispositivi, quindi ha senso avere un servizio di accesso comune.

Queste applicazioni non hanno bisogno di risorse da un server. Il server viene usato solo per autenticare l'utente.

Quando un utente avvia un'applicazione, deve accedere prima che possa utilizzare l'app. L'autenticazione avviene su un server ed è già ordinata. La domanda è come posso limitare l'uso dell'applicazione, che è già installata sul dispositivo quando viene richiesto all'utente di accedere. Se si trattava di un'applicazione web, avrei memorizzato un cookie di sessione che viene poi utilizzato ogni volta che viene richiesta una risorsa . Nel mio caso tutte le risorse sono già presenti sul dispositivo, quindi se qualcuno è abbastanza testardo sarà in grado di utilizzare l'applicazione senza prima effettuare il login, ma non voglio che sia troppo facile. Se esiste un equivalente offline di un cookie di sessione che posso utilizzare per verificare che l'utente abbia effettuato l'accesso mentre l'app viene utilizzata, sarebbe l'ideale. Non sto memorizzando informazioni sensibili nelle applicazioni né sarebbe una catastrofe se qualcuno dovesse accedere senza prima accedere a un account, ma vorrei sapere se c'è un buon modo per risolvere questo problema.

  • Quando gli utenti lanciano le mie applicazioni dovrebbero essere richieste per accedere
  • Dopo aver effettuato l'accesso gli utenti dovrebbero essere in grado di utilizzare l'applicazione, e non dovrebbe essere troppo facile aggirare il processo di accesso

Non sto chiedendo dettagli, ma ho raggiunto un punto morto e mi piacerebbe sapere su eventuali tecnologie o tecniche che potrebbero aiutare.

    
posta Slick Vick 08.08.2017 - 10:33
fonte

1 risposta

1

Penso che tu abbia o complicato troppo il problema nella tua testa (pratica comune per noi sviluppatori) o hai un difetto di progettazione nel tuo sistema. Potrebbe essere entrambi.

La tua domanda afferma:

How do I prevent users from using my iOS apps unless they have been authenticated on a server?

La risposta è: non consentire l'avvio dell'app finché un utente non ha effettuato l'accesso. Quando avvii l'app, avvialo direttamente alla schermata di accesso. Ma sembra che tu abbia già questo posto:

When a user launches an app they must log in before they can use the app

Quindi la tua domanda sembra essere:

how I can restrict use of the application...?

I tuoi account utente devono avere ruoli. Al minimo, un ruolo utente gratuito e premium.

In caso di autenticazione avvenuta con successo, l'utente dovrebbe ottenere un token che gli consente di utilizzare l'app. Ai fini di questa discussione, dirò "accesso illimitato all'app" per evitare la complessità di sbloccare solo questa funzione o quella funzione, che è completamente possibile a seconda della tua architettura.

Il token non deve solo consentire l'accesso all'app ma anche un'opzione di scadenza, ma dipende da te. (Se un utente gratuito è perennemente libero, e un utente premium è una tassa una tantum produce una licenza perpetua, quindi le scadenze non sono necessarie).

Una volta che l'utente esegue il login per la prima volta, il server di autenticazione utente emetterà un token in base al ruolo e allo stato. Se sono utenti liberi, riceveranno questo token, che fornisce loro un accesso illimitato all'app. Se sono utenti premium, il server tratterrà il token a meno che il premio non sia stato pagato.

Anche se il metodo di implementazione è un po 'fuori portata per security.stackexchange.com, farò qui una versione semplificata perché penso che faccia parte delle basi della tua domanda originale.

La complicazione arriva a questa domanda: come pagano i tuoi utenti premium per sbloccare l'app? Non puoi avere un'app gratuita e a pagamento perché tutti dovrebbero scaricare solo quella gratuita e non pagare mai.

Rimani solo con l'opzione di una singola app e modificando il ruolo utente in base a uno stato a pagamento (o anche a un abbonamento).

Da quando lo hai pubblicato su iOS, farò riferimento a Acquisti in-app . L'app deve essere gratuita per impostazione predefinita con le opzioni di acquisto in-app. Quando un utente gratuito scarica l'app, può richiedere il suo account gratuito (o, se appartengono a un determinato gruppo che ha un codice coupon, ecc ... hanno bisogno dell'opzione di inserirla, che cambierà il loro ruolo sul server a un ruolo utente libero).

Altrimenti, puoi sfruttare i pagamenti in-app per aggiornare l'account a una versione premium / sbloccata.

Detto questo, avere un'app "gratuita" e quindi richiedere immediatamente un codice di sblocco o un acquisto in-app sarà un'implementazione "ad alta frizione".

Se hai deciso di utilizzare una versione gratuita ea pagamento nell'app store. La versione gratuita richiederebbe semplicemente un codice promozionale per attivare l'abbonamento gratuito. Oppure, in alternativa, dovrebbe aspettare che il tuo personale approvi il nuovo utente. (Un sacco di lavoro per un'app gratuita).

La versione a pagamento funzionerebbe subito dopo il download. Qui, stai limitando l'implementazione "high friction" agli utenti che stanno ottenendo comunque roba gratis. Gli utenti a pagamento hanno una transazione regolare come burro.

The authentication takes place on a server and is already sorted

Se il tuo server di autenticazione non supporta i ruoli, allora questo non è ordinato, che potrebbe essere un difetto di progettazione che deve essere rivisitato. Soprattutto se si considera che se al momento non si dispone di ruoli utente, è necessario disporre di un codice che richieda l'API di Apple per lo stato di sottoscrizione o che abbia un codice che riceve un evento quando è stata pagata una sottoscrizione / commissione per modificare il ruolo di un utente.

    
risposta data 08.08.2017 - 12:13
fonte

Leggi altre domande sui tag