Erstellen einer API für mobile Anwendungen - Authentifizierung und Autorisierung

Übersicht

Ich bin auf der Suche zu erstellen, die eine (REST) - API für meine Anwendung. Die erste/primäre Zweck werden für die Nutzung von mobile apps (iPhone, Android, Symbian, etc.). Ich habe auf der Suche in verschiedene Mechanismen für die Authentifizierung und Autorisierung für web-basierte APIs (durch das Studium von anderen Implementierungen). Ich habe meinen Kopf gewickelt, um die meisten der grundlegenden Konzepte, bin aber noch auf der Suche nach Anleitung in ein paar Bereichen. Das Letzte, was ich tun möchte, ist neu erfinden das Rad, aber ich bin nicht auf der Suche nach einem standard-Lösungen, die genau meinen Kriterien (wie auch immer, meine Kriterien, meine fehlgeleitet, so fühlen sich frei, um Kritik, als auch). Darüber hinaus möchte ich die API für alle Plattformen/Anwendungen verbraucht es.

oAuth

Ich werde gehen Sie vor und werfen meinen Einwand, oAuth, da ich weiß, dass wird wahrscheinlich die erste Lösung angeboten. Für mobile Anwendungen (oder genauer nicht-web-Anwendungen), scheint es einfach falsch, sich auf die Anwendung verlassen (gehen Sie zu einem web-browser) für die Authentifizierung. Darüber hinaus gibt es keine Möglichkeit (ich bin mir bewusst,) für den browser, um die Rückkehr der callback an die Anwendung (besonders cross-platform). Ich weiß, ein paar apps, die das tun, aber es fühlt sich einfach falsch und gibt eine Pause in der Anwendung UX.

Anforderungen

  1. Benutzer gibt Benutzernamen/Passwort in der Anwendung.
  2. Jeden API-Aufruf wird ermittelt, indem die aufrufende Anwendung.
  3. - Overhead ist auf ein minimum reduziert und die auth Aspekt ist intuitiv für Entwickler.
  4. Der Mechanismus ist sicher für die end-Benutzer (Ihre Zugangsdaten werden nicht ausgesetzt) als auch dem Entwickler (Ihre Bewerbungsunterlagen werden nicht aufgedeckt).
  5. Wenn möglich, nicht https erforderlich (keine harte Anforderung).

Meine Aktuellen Gedanken über die Umsetzung

Einem externen Entwickler Anfrage ein API-Konto. Sie erhalten eine apikey und apisecret. Jede Anfrage erfordert mindestens drei Parameter.

  • apikey - gegeben, um Entwickler bei der regisration
  • timestamp - Doppel als einen eindeutigen Bezeichner für jede Nachricht für einen bestimmten apikey
  • hash - der hash der timestamp + die apisecret

Den apikey ist erforderlich, um die Anwendung zu identifizieren, die das ersuchen gestellt. Der timestamp wirkt ähnlich wie die oauth_nonce und vermeidet/mildert replay-Angriffe. Der hash wird sichergestellt, dass die Anfrage wurde tatsächlich ausgegeben vom Inhaber der angegebenen apikey.

Für authentifizierte Anforderungen (diejenigen gemacht, die auf den Namen eines Benutzers), ich bin immer noch unentschlossen zwischen gehen mit ein access_token route oder einen Benutzernamen und ein Kennwort-hash-combo. So oder so, irgendwann wird ein Benutzername/Passwort-Kombo benötigt. Also, wenn Sie es tut, wird ein hash aus mehreren Informationen (apikey, apisecret, timestamp) + das Passwort verwendet werden würde. ich würde gerne feedback zu diesem Aspekt. FYI, Sie hätten hash des Passwortes, da ich nicht speichern Sie die Kennwörter in meinem system ohne hashing.

Fazit

FYI, dies ist nicht eine Anforderung für den Aufbau/Struktur der API in der Regel nur zu behandeln, wie die Authentifizierung und Autorisierung von ausschließlich innerhalb einer Anwendung.

Zufällige Gedanken/Bonus-Fragen

Für APIs, die nur verlangen, einen apikey als Teil der Anforderung, wie verhindern Sie, dass jemand anderes als der apikey Besitzer in der Lage, Sie zu sehen, die apikey (da in Klartext gesendet) und übertriebene Anforderungen an, schieben Sie Sie über Nutzungsbeschränkungen? Vielleicht bin ich auch nur über das denken, aber nicht sollte es etwas sein, zu authentifizieren, dass ein entsprechender Antrag wurde überprüft, um die apikey Besitzer? In meinem Fall war der Zweck der apisecret, es wird nie angezeigt/übertragen ohne Hash.

Sprechen von hashes, was über md5-vs-hmac-sha1? Ist es wirklich wichtig, wenn alle Hash-Werte sind mit ausreichend langen Daten (ie. apisecret)?

Ich hatte zuvor erwägt, ein pro Benutzer/row Salz auf meiner Benutzer-Passwort-hash. Wenn ich das, wie könnte die Anwendung in der Lage sein zu erstellen, eine passende hash-ohne zu wissen, das Salz, das benutzt?

InformationsquelleAutor der Frage jsuggs | 2010-10-18

  1. 42

    Den Weg bin ich darüber nachgedacht, den login-Teil, das in meinem Projekte ist:

    1. vor dem login der Benutzer fordert eine login_token vom server. Diese werden generiert und auf dem server gespeichert, auf Anfrage, und wahrscheinlich haben eine begrenzte Lebensdauer.

    2. login das Programm berechnet den Hashwert des Benutzer-Passwort, dann hasht das Passwort mit der login_token um einen Wert, Sie dann wieder sowohl die login_token und der kombinierte hash.

    3. Überprüft der server die login_token ist eine, die es erzeugt hat, entfernen Sie es aus der Liste der gültigen login_tokens. Der server verbindet sich dann seine gespeicherten hash das Passwort des Nutzers mit der login_token und sorgt dafür, dass Sie mit der vorgelegten Kombination token. Wenn es passt, haben Sie authentifiziert den Benutzer.

    Vorteile sind, dass man nie speichern das Kennwort des Benutzers auf dem server, das Passwort wird nie im Klartext übertragen, ist den Hashwert des Kennworts werden nur im Klartext übertragen auf Konto erstellen, (obwohl möglicherweise gibt es Möglichkeiten das zu umgehen), und es sollte sicher sein von replay-Attacken, da die login_token entfernt von der DB im Einsatz.

    InformationsquelleAutor der Antwort Michael Anderson

  2. 12

    Das ist eine ganze Menge von Fragen in einer, ich denke, nicht wenige Menschen haben es nicht geschafft, alles zu Lesen bis zum Ende 🙂

    Meine Erfahrung mit web-service-Authentifizierung ist, dass Menschen in der Regel overengineer es, und die Probleme sind nur das gleiche, als würden Sie stoßen auf eine web-Seite. Möglich sehr einfache Möglichkeiten würden von https für die Anmeldung Schritt zurück ein token, erfordern, dass Sie mit zukünftigen Anforderungen. Sie können auch http-basic-Authentifizierung, und geben Sie nur Sachen in den Kopf. Für zusätzliche Sicherheit drehen/verfallen die Token Häufig, überprüfen Sie die Anforderungen, die aus dem gleichen IP-block (dies könnte ein Durcheinander, wenn Sie als mobile bewegen sich die Nutzer zwischen den Zellen), verbinden Sie sich mit API-key oder ähnliches. Alternativ können Sie die "request key" Schritt oauth (jemand schlug vor, diese in einer vorherigen Antwort bereits und es ist eine gute Idee) vor der Authentifizierung der Benutzer, und die erforderlichen Kennzahlen zu generieren, die access token.

    Eine alternative, die ich nicht verwendet haben noch, aber ich habe gehört, eine Menge über so ein Gerät-freundliche alternative zu oAuth ist xAuth. Haben Sie einen Blick auf Sie und wenn Sie es dann ich wäre wirklich daran interessiert zu hören, was Ihre Eindrücke sind.

    Für Hash-sha1 ist ein wenig besser, aber nicht bekommen, hing über es - was die Geräte können problemlos (und schnell in einer performance Sinn) umzusetzen, ist wahrscheinlich gut.

    Hoffe, das hilft, viel Glück 🙂

    InformationsquelleAutor der Antwort Lorna Mitchell

  3. 9

    Twitter adressiert die externe Anwendung ein Problem in oAuth unterstützen Sie eine Variante, die Sie anrufen xAuth. Leider gibt es bereits eine Vielzahl anderer Programme mit diesem Namen, so kann es verwirrend sein, um sich zu Sortieren.

    Protokoll ist oAuth, außer es springt der request-token-phase und einfach sofort Fragen ein access-token-pair-Mädchen nach Erhalt einen Benutzernamen und ein Passwort. (Ab Schritt E hier.) Diese ersten request-und response - gesichert werden müssen - es sendet den Benutzernamen und das Kennwort in Klartext und den Empfang der access token und token secret. Sobald der access-token-paar konfiguriert wurde, ob das erste token exchange wurde über die oAuth-Modell oder die xAuth-Modell ist irrelevant sowohl für die client-und server für den rest der Sitzung. Dies hat den Vorteil, dass Sie bereits vorhandene oAuth-Infrastruktur und haben fast die gleiche Implementierung für mobile - /web - /desktop-Applikationen. Der größte Nachteil ist, dass die Anwendung Zugriff auf die client-Benutzer-Namen und Passwort, aber es erscheint wie Ihre Anforderungen Mandat dieser Ansatz.

    In jedem Fall, ich möchte die Stimme Ihrer intuition und von mehreren anderen Beantworter hier: versuchen Sie nicht, um etwas neues aufzubauen, von Grund auf. Sicherheits-Protokolle können leicht zu starten, aber immer sehr schwer gut zu tun, und desto mehr verwickelte Sie werden weniger wahrscheinlich, Ihre Drittanbieter-Entwickler werden in der Lage sein zu implementieren, ist gegen Sie. Deine hypothetische Protokoll ist sehr ähnlich zu o(x)Auth - api_key/api_secret, nonce, sha1-hashing - aber anstatt in der Lage, verwenden Sie eine der vielen vorhandenen Bibliotheken Ihre Entwickler gehen zu müssen, Rollen Sie Ihre eigenen.

    InformationsquelleAutor der Antwort lantius

  4. 8

    So, was Sie nach ist eine Art von server side authentication-Mechanismus, der sich um die Authentifizierung und Autorisierung Aspekte einer mobilen Anwendung?

    Angenommen, dass dies der Fall ist, dann würde ich den Ansatz wie folgt (aber nur 'cos ich bin ein Java-Entwickler, so dass ein C# - Kerl würde es anders machen):

    Die RESTful authentication and authorisation service

    1. Dies funktioniert nur über HTTPS zu lauschen.
    2. Es basiert auf einer Kombination von RESTEasySpring Security und CAS (für single-sign-on für mehrere Anwendungen).
    3. Es funktioniert mit beiden Browsern und web-fähigen client-Anwendungen
    4. Wird es einen web-basierten account-management-Schnittstelle, um Benutzern zu erlauben, Bearbeiten Sie Ihre details, und die admins (für Besondere Anwendungen) zu ändern Berechtigungsstufen

    Der client-Seite security library/application

    1. Für jede unterstützte Plattform (z.B.
      Symbian, Android, iOS etc) erstellen
      geeignete Implementierung der
      Sicherheit Bibliothek in der nativen
      die Sprache der Plattform (z.B. Java,
      ObjectiveC, C, etc)
    2. Der Bibliothek
      verwalten soll die HTTPS-Anforderung
      Bildung über die verfügbaren APIs
      für die angegebene Plattform (z.B. Java
      verwendet URLConnection etc)
    3. Verbraucher über die Allgemeine Authentifizierung und
      authorisation library ('cos
      alle es der ist), wird der code zu einem bestimmten
      interface und wird nicht glücklich sein, wenn es
      jemals ändert, so stellen Sie sicher, es ist sehr
      flexibel. Folgen Sie vorhandene design
      Entscheidungen, wie z.B. Spring Security.

    So, jetzt der Blick von 30.000 Fuß abgeschlossen ist, wie tun Sie gehen über es zu tun? Nun, es ist nicht schwer, Sie zu erstellen Sie eine Authentifizierungs-und Zulassungsverfahren auf der Grundlage der aufgeführten Technologien auf der server-Seite mit einem browser-client. In Kombination mit HTTPS, die frameworks bieten einen sicheren Prozess auf der Grundlage einer gemeinsamen token (in der Regel präsentiert sich als ein cookie) generiert durch den Authentifizierungsprozess und immer dann verwendet, wenn der Benutzer etwas tun möchte. Dieses token wird Ihnen präsentiert von der client an den server, wenn keine Anfrage erfolgt.

    Im Falle des lokalen mobilen Anwendung, es scheint, dass Sie nach einer Lösung, die Folgendes macht:

    1. Client-Anwendung hat einen definierten Access Control List (ACL) controlling-runtime-Zugriff auf Methodenaufrufe. Zum Beispiel, für einen gegebenen Benutzer können Lesen, eine Sammlung von einer Methode, sondern Ihre ACL erlaubt nur den Zugriff auf Objekte, die ein Q im Namen, so dass einige Daten in der Sammlung ist quiety zog durch das security-interceptor. In Java-diese ist unkompliziert, verwenden Sie einfach das Spring Security-Anmerkungen zu dem Aufruf-code und implementieren Sie eine geeignete ACL-Antwort-Prozess. In den anderen Sprachen, Sie sind auf Ihre eigenen und wahrscheinlich müssen boilerplate Sicherheits-code, der Anrufe in Ihrer Sicherheit Bibliothek. Wenn die Sprache unterstützt AOP (Aspekt Orientierte Programmierung), dann verwenden Sie es in vollen Zügen für diese situation.
    2. Der security-Bibliothek speichert die vollständige Liste der Zulassungen in den privaten Speicher für die aktuelle Anwendung, so dass Sie nicht haben, um verbunden bleiben. Abhängig von der Dauer der login-session, könnte dies ein einmaliger Vorgang, der nie wiederholt wird.

    Was auch immer Sie tun, versuchen Sie nicht, erfinden Sie Ihr eigenes security-Protokolloder verwenden Sie die Sicherheit durch Verschleierung. Sie werden nie in der Lage zu schreiben, einen besseren Algorithmus für diese, als diejenigen, die derzeit verfügbar sind und kostenlos. Auch, die Menschen Vertrauen bekannten algorithmen. Also, wenn Sie sagen, dass Ihre Sicherheits-library enthält die Autorisierung und Authentifizierung für lokale mobile Anwendungen mit einer Kombination von SSL, HTTPS, SpringSecurity-und AES-verschlüsselte Token dann wirst du sofort haben creditibility in den Markt.

    Hoffe, dass dies hilft, und viel Glück mit Ihrem Unternehmen. Wenn Sie möchten mehr info, lass es mich wissen - ich habe geschrieben durchaus ein paar web-Anwendungen auf Basis von Spring Security, ACLs und ähnliches.

    InformationsquelleAutor der Antwort Gary Rowe

  5. 3

    Super spät zur party, aber ich wollte, um zu werfen in einige weitere Punkte zu berücksichtigen für Interessierte in dieser Ausgabe. Ich arbeite für ein Unternehmen, mobile API security Lösungen ( approov ), so ist dieses ganze Gebiet ist durchaus relevant zu meinen Interessen.

    Mit zu beginnen, ist die wichtigste Sache zu prüfen, wenn Sie versuchen, um zu sichern eine mobile API ist wie viel es Wert ist. Die richtige Lösung für eine bank, die anders ist, die richtige Lösung für jemanden, der nur Dinge zu tun, für Spaß.

    In der vorgeschlagenen Lösung, die Sie erwähnen, sind mindestens drei Parameter notwendig:

    • apikey - gegeben, um Entwickler bei der Registrierung
    • timestamp - Doppel als einen eindeutigen Bezeichner für jede Nachricht für einen bestimmten apikey
    • hash - der hash der timestamp + die apisecret

    Die Implikation von diesem ist, dass einige API-Aufrufe kein Benutzername/Passwort erforderlich ist. Dies kann nützlich sein für Anwendungen, bei denen Sie nicht wollen, zu zwingen, ein login (Browsen in online-shops beispielsweise).

    Dies ist ein etwas anderes problem für den, der für die Authentifizierung des Benutzers und ist mehr wie die Authentifizierung oder die Bescheinigung der software. Es gibt keine Benutzer, aber Sie immer noch wollen, um sicherzustellen, dass es keine bösartigen Zugriff auf Ihre API. So verwenden Sie Ihre API-Geheimnis der Zeichen, die dem Verkehr und den code identifizieren und den Zugriff auf die API als echte. Das potenzielle problem mit dieser Lösung ist, dass Sie dann verschenken, das Geheimnis in jeder version der app. Wenn jemand extrahieren können, das Geheimnis Sie können der Nutzung Ihrer API, die Identität Ihrer software, sondern tun, was Sie wollen.

    Zu begegnen, die Bedrohung gibt es ein paar Dinge, die Sie tun können, je nachdem wie wertvoll die Daten sind. Verschleierung ist ein einfacher Weg, um es schwieriger zu extrahieren, das Geheimnis. Es gibt tools, die das für Sie tun, um so mehr für Android, aber Sie haben noch zu haben-code, generiert den hash und einer ausreichend qualifizierten Person kann immer nur die Funktion aufrufen, die die hashing-direkt.

    Andere Weise zu mildern gegen die übermäßige Nutzung einer API, ist keine Anmeldung erforderlich ist, um Gas der traffic und potenziell identifizieren und blockieren von verdächtigen IP-Adressen. Der Aufwand, den Sie gehen wollen, wird weitgehend davon abhängen, wie geistige Werte Ihrer Daten.

    Darüber hinaus können Sie leicht den Einstieg in die Domäne meiner täglichen Arbeit. Trotzdem, es ist ein weiterer Aspekt der Sicherung von APIs, die halte ich für wichtig und wollte fahne auf.

    InformationsquelleAutor der Antwort ThePragmatist

Schreibe einen Kommentar