OAuth 2.0 Integration


Erfahren Sie, warum unsere Zwei-Faktor Authentifizierung die Beste ist und Sie die Sicherheit Ihres Unternehmens upgraden sollten. Für Entwickler haben wirhier Informationen zusammengetragen.

Erfahren Sie mehr über Inhouse-Installationen und Ihre individuelle Firmen-App mit Ihrem Corporate Design.

Downloaden Sie das Plugin kostenlos in der Cloud für bequemen und sicheren Schutz.


Viele Webseiten und Anwendungen bieten die Möglichkeit seinen Account mit einem Facebook/Google/Twitter etc. Account zu verbinden um zum Beispiel automatisch Tweets zu schreiben, Freundeslisten zu importieren oder sein Profil mit Informationen zu füllen. Diese Webseiten und Anwendungen nutzen den Authentifizierungs- und Authorisierungsstandard OAuth 2.0 (RFC 6749).

Wenn eine Website die Dienste einer anderen verwenden möchte – also zum Beispiel Bitly in Ihrem Twitter-Stream postet –, sollte sie OAuth verwenden, anstatt nach dem Passwort zu fragen. Bei OAuth handelt es sich um ein Authentifizierungsprotokoll, mit dessen Hilfe Sie die Interaktion zwischen zwei Anwendungen erlauben können, ohne Ihre Zugangsdaten preiszugeben.

Inhaltsverzeichnis

    Das SecSign ID Plugin bietet eine echte Zwei-Faktor-Benutzerauthentifizierung (2FA). 2FA fügt eine zusätzliche Sicherheitsschicht hinzu, indem es das mobile Gerät des Nutzers als zusätzlichen physischen Token mit in die Authentifizierung einbindet.

    Fragen?Kontaktieren Sie uns, wenn Sie Hilfe beim Setup des SecSign ID Plugins brauchen oder Ihnen ein Plugin für eine andere Programmierumgebung fehlt.

    1. Funktionsweise von OAuth 2.0

    OAuth2.0 ist ausschließlich zur Autorisierung bestimmt, nicht zur Authentifizierung. Allerdings muss sich der Nutzer dem Provider gegenüber authentifizieren bevor er die Autorisierung vornehmen kann. Die Authentifizierung ist also ein wesentlicher Schritt im Ablauf der Autorisierung, den OAuth aber nicht übernimmt.

    In einer OAuth-Transaktion gibt es drei Hauptbeteiligte:

    1. Nutzer (User)
      Der Endnutzer oder die Entität, ist der Besitzer der betreffenden Ressource
    2. Client (OAuth Consumer)
      Die Anwendung oder App, welche die Ressource nach Autorisierung nutzen möchte
    3. Server (OAuth Provider)
      Die Entität, welche die betreffende Ressource zur Verfügung stellt, bzw. hostet

    Dieses Konstrukt wird auch als „OAuth Love Triangle“ bezeichnet.

    1.1 Ablauf der Authorisierung

    In unserem Beispiel ist Alice der User, Bitly der OAuth Consumer und Facebook der OAuth Provider, auf dem sich die sichere Ressource von Alice befindet (ihr Facebook-Profil). Alice möchte sich bei Bitly mit ihren Facebook-Daten registrieren. So funktioniert’s:

    Schritt 1: Der User äußert seine Absicht

    Alice (Nutzer): ”Hi Bitly, ich möchte, dass du alle Information die du zur Registrierung brauchst aus meinem Facebook Profil holst.“
    Bitly (OAuth consumer): “Super! Ich bitte gleich um die Genehmigung.”

    Schritt 2: Der Consumer erhält die Genehmigung

    Bitly: „Facebook, ein User möchte, dass ich seine Profil-Daten für eine Registrierung abfrage . Kann ich einen Abfrage-Token haben?“
    Facebook (OAuth Provider): „Natürlich. Hier sind ein Token und ein Geheimnis.“

    Das Geheimnis wird benötigt, um gefälschte Abfragen zu verhindern. Der Consumer verwendet das Geheimnis, um jede Abfrage zu signieren. So kann der Service Provider überprüfen, ob die jeweilige Abfrage auch wirklich von der Consumer-Anwendung kommt.

    Schritt 3: Der User wird zum Service Provider weitergeleitet

    Bitly: „OK, Alice. Ich leite dich jetzt an Facebook weiter, damit du die Aktion bestätigen kannst. Nimm diesen Token mit.“

    Wäre Bitly ein unseriöser Anbieter, könnte er ein Popup-Fenster verwenden, das zwar genau wie Facebook aussieht, aber eigentlich eine Phishing-Seite ist, mit dem er die Zugangsdaten von Alice in Erfahrung bringen kann. Stellen Sie stets sicher, dass es sich bei der URL, an die Sie weitergeleitet werden, wirklich um den Service Provider handelt (in diesem Fall Facebook).

    Schritt 4: Der User gibt seine Erlaubnis

    Alice: „Facebook, ich möchte diesen Abfrage-Token autorisieren, den Bitly mir gegeben hat.“
    Facebook: „OK. Nur zur Sicherheit: Du möchtest Bitly die Erlaubnis dazu geben, auf folgende Daten deines Facebook Kontos zuzugreifen? Emailadresse, Name etc..“
    Alice: „Ja!“
    Facebook: „OK. Du kannst zu Bitly zurückkehren und ihm sagen, dass er seinen Abfrage-Token jetzt verwenden kann.“

    Schritt 5: Der Consumer erhält einen Zugangs-Token

    Bitly: „Facebook, kann ich diesen Abfrage-Token gegen einen Zugangs-Token tauschen?“
    Facebook: „Sicher. Hier sind der Zugangs-Token und das Geheimnis.“

    Schritt 6: Der Consumer greift auf die geschützte Ressource zu

    Bitly: „Ich möchte gern die Profildaten von Alice haben. Hier ist mein Zugangs-Token!“
    Facebook: „Hier sind die Daten von Alice …“

    bitlylogin

    contiuneasalice

    1.2 Grant Types

    Consumer Anmeldedaten

    Der Consumer muss zuvor beim Provider registriert werden. In der Regel müssen grundlegende Informationen beim Provider hinterlegt werden, wie Anwendungsname, Webseite etc. Darüber hinaus muss für Web-Server, Browser-basierte oder mobile Anwendungen eine URI (TLS gesichert) registriert werden, welche den Benutzer nach erfolgreicher Bestätigung beim Provider zurück zum Consumer leitet. Nach der Registrierung des Consumers, erhält man üblicherweise die öffentliche Client ID und ein Geheimnis. Diese Daten werden unter anderem dafür genutzt um API-Zugriffsrechte auf Seiten des Providers zu steuern.

    Der erste Schritt des OAuth2 Autorisierung ist die Genehmigung des Benutzers zu erhalten. Für Browser-basierte oder mobile Anwendungen wird dies in der Regel durch die Anzeige eine Schnittstelle mit dem Service für den Nutzer erreicht. OAuth 2 bietet hierfür einige „Grant Types“ für verschiedene Anwendungsfälle:

    Berechtigungscode

    Beim Berechtigungscode loggt sich der Benutzer beim OAuth Provider ein und gibt seine Daten frei. Mit dem Zurückleiten zum Consumer schickt der Provider einen Berechtigungscode. Dieser fungiert gemeinsam mit der Client-ID und dem entsprechenden Passwort als Zugangsdaten. Auf Basis dieser Informationen stellt der OAuth Provider ein Zugangstoken bzw. Access-Token aus.

    Implicit

    Die implizite Berechtigung unterscheidet sich nur unwesentlich vom Zugang über den Berechtigungscode, ist allerdings im Kommunikationsprozess weniger aufwändig. Nach dem Einloggen in den OAuth Provider erhalten Sie direkt den Autorisierungscode samt Zugangstoken.

    Passwort

    Passwortfreigabe durch den Besitzer der Daten: In diesem Fall würden Sie dem Consumer direkt die Zugangsdaten zum Provider überlassen. Dieses Verfahren ist sehr risikobehaftet und erfordert ein hohes Maß an Vertrauen gegenüber dem Consumer.

    Client Credentials

    Dieses Szenario wird eingesetzt, wenn die Consumer-Anwendung Zugriff auf Informationen auf dem OAuth Provider benötigt, die keinen Besitzer haben.

    1.3 Access Token: Bearer oder MAC?

    Most OAuth implementations are based on the OAuth2.0 Bearer-token (RFC Standard). The OAuth2.0 Bearer-token profile offers a simplified regulation for authentication.

    Die meisten OAuth Implementierungen basieren auf dem OAuth 2.0 Bearer-Token (RFC Standard). Das OAuth 2.0 Bearer Token-Profil bringt eine vereinfachte Regelung für die Authentifizierung. Diese Spezifikation beschreibt, wie Bearer (=Inhaber) Token in HTTP-Anfragen zu nutzen sind, damit auf OAuth 2.0 geschützte Ressourcen zugegriffen werden kann. Der Bearer-Token muss über SSL/TLS gesichert werden, wenn also HTTPS keine Option ist, dürfen Bearer-Token nicht verwendet werden. Stattdessen können MAC-Token genutzt werden. Primäres Ziel des MAC-Tokens ist es, die HTTP-Authentifizierung zu sichern, wenn SSL/TLS nicht genutzt werden kann.

    OAuth 2.0 hat im Wesentlichen drei Phasen:

    1. Genehmigung anfordern (Authorization Grant)
    2. Austausch des Authorization Grant für einen Access-Token
    3. Zugriff auf die Ressourcen mit dem Access-Token

    Wo kommt also der Token-Typ zum Einsatz?

    Beispiel für eine Antwort mit dem Access-Token (Bearer):

    Der access_token identifiziert den MAC Schlüssel (=MAC-Schlüssel-ID), welcher dazu verwendet wird, den MAC-Wert der Anfrage zu berechnen. Der eigentliche Schlüssel bleibt dem Consumer, im Gegensatz zum Bearer-Token-Profil, verborgen. Der Server weist typischerweise eine bestimmte Laufzeit zu jedem Satz von MAC-Anmeldeinformationen.

    Beispiel für eine Antwort mit dem Access-Token (Mac):

    Der MAC-Zugriffstoken hat zwei zusätzliche Attribute: mac_key und mac_algorithm. Der mac_key ist ein gemeinsamer symmetrischer Schlüssel, mac_algorithm beschreibt den zu nutzenden Algorithmus.

    In Schritt 3. wird mit Hilfe des Access-Tokens eine bestimmte Ressource angefordert.

    Mit dem Bearer-Token muss lediglich der Access-Token vom Autorisierungsserver aus Schritt 2 übergeben werden:

    Beim MAC-Token-Profil muss der Consumer ein paar mehr Informationen mit auf den Weg schicken:

    1. id ist die MAC Schlüssel Kennung bzw. der Access-Token aus Schritt 2
    2. ts ist der Zeitstempel der Anfrage (verstrichene Sekunden ausgehend von einem fixen Zeitpunkt, Integer). Dieser Wert ist einzigartig unter allen Anfragen mit dem gleichen Zeitstempel und Mac Schlüssel Kennung
    3. Nonce ist eine eindeutige Zeichenfolge, die vom Consumer generiert wird. Der Wert ist einzigartig in allen Anfragen mit dem gleichen Zeitstempel und MAC-Schlüssel-ID -Kombination
    4. mac wird vom Consumer aus dem MAC Algorithmus und des MAC Schlüssels berechnet

    Der mac Wert ist eine konstante, reproduzierbare Verkettung von mehreren HTTP-Anfrage-Elementen in einem einzigen String. Er wird aus folgenden Informationen berechnet: Zeitstempel der Anfrage, dem nonce Wert, der HTTP-Anfragemethode (HEAD,GET, POST etc.), die HTTP Anfrage URI (definiert in RFC2616 Punkt 5.1.2.), Hostname, Port, Wert des optionalen request header field attribute „ext“.

    Jedes dieser Elemente wird gefolgt von einem Zeilenvorschubzeichen (%x0A). Anschließend wird der String mit Hilfe des unter mac_algorithm angegebenen Algorithmus gehasht.

    Die Implementierung mit dem MAC-Token-Verfahren ist um einiges aufwändiger für den Consumer als auch für den OAuth Provider. Das Profil stellt aber eine Methode zur Verfügung, wenn der Schlüssel nicht direkt, wie beim Bearer-Token Verfahren, übertragen werden kann. Ist eine Übertragungssicherheit mittels SSL/TLS gewährleistet, wird meist der simple Bearer-Token bevorzugt..

    2. Vorteile und Nachteile

    In unserem Beispiel musste Alice ihre Facebook-Zugangsdaten gegenüber Bitly nie preisgeben. Sie delegierte den Zugang einfach auf sichere Weise über OAuth. Alice kann sich jederzeit bei Facebook anmelden, die von ihr erteilten Zugangsrechte überprüfen und Tokens für bestimmte Anwendungen aufheben, ohne dadurch andere zu beeinträchtigen.

    OAuth ermöglicht zudem detaillierte Berechtigungsstufen. So kann sie beispielsweise Bitly die Berechtigung erteilen, auf Ihrem Facebook-Konto zu posten, den Zugriff auf LinkedIn jedoch auf „Nur lesen“ beschränken.

    OAuth ist eine robuste Lösung für browserbasierte Anwendungen und eine enorme Verbesserung gegenüber der HTTP Basic Authentication. Allerdings gibt es auch bei OAuth einige Stolperfallen in der Entwicklung des Consumers oder des Providers, welche das System verletzlich und angreifbar machen.

    Im Normalfall hat die Third-Party-App bzw. der Consumer niemals Zugriff auf die Login-Credentials des Nutzers auf dem Provider. Trotzdem können unter Umständen aber sehr sensible Nutzerdaten übertragen werden. Ein Beispiel für die Übertragung solcher Daten wäre eine Bank-App. Es können Kontonummern, Adressen und Transaktionen eingesehen werden oder Transaktionen gestartet werden. Bei diesen Informationen muss erstens sichergestellt werden, dass die Übertragung abgesichert ist und die App diese Informationen nicht speichert. Zweitens muss der Provider dem Consumer, bzw. der App vertrauen, dass der Zugriff auf diese Daten nicht missbraucht wird. Sobald der Provider die Daten herausgibt, hat er keine Möglichkeit mehr die sensiblen Daten zu kontrollieren, was evtl. auch rechtlich ein Problem darstellen kann.

    Eine unseriöse App könnte also die gesammelten Adressen verkaufen, Kontonummern weitergeben und Transaktionen auswerten, auch wenn die Login-Daten nicht bekannt sind. Es ist aus Provider-Sicht somit nicht sonderlich sinnvoll, Consumern dynamisch bzw. automatisch den Zugriff auf die API zu erlauben. Consumer müssen sich vor den ersten API Anfragen händisch am Provider registrieren und spezifische Callback URI’s vergeben. Nach Prüfung erhält der Consumer dann die Consumer-Credentials vom Provider und kann Anfragen an die API stellen.

    Besonders weil OAuth sich nur um die Autorisierung kümmert, jedoch auch mit der Authentifizierung in Berührung kommt kann es zu Attacken auf die Nutzerdaten kommen. Ein unseriöser Consumer kann mittels Phishing versuchen an die Provider-Zugangsdaten der Nutzer zu kommen. Der Provider kann hier ganz einfach eine Zwei-Faktor Authentifizierung einführen um passwortbasierte Zugangsdaten zu unterbinden (siehe 4). Das Fehlen eines optionalen Parameters (’state‘ mit Random-Hash) kann dazu führen, dass mittels CSRF (Cross-Site-Request-Forgery) Benutzerkontos des Providers übernommen werden können. Da der Parameter optional ist, wird er oft nicht mit berücksichtigt. Um „Covert Redirects“ oder offene Redirects zu verhindern, muss der Provider die Callback-URL prüfen, ob diese zuvor vom Consumer registriert wurde.

    Bei der Entwicklung eines OAuth Providers ist es daher wichtig mögliche Exploits zu verhindern um die Ressourcen und Nutzerkonten vor Missbrauch zu schützen.

    3. OAuth in Kombination mit 2FA

    Um mögliche Phishing Attacken zu verhindern setzen wir zur Authentifizierung am Provider die SecSign ID Zwei-Faktor Authentifizierung ein

    OAuth ist ein guter Standart um Drittanbietern Zugriff auf Ressourcen zu gewähren. OAuth regelt dabei aber nur die Autorisierung, nicht die Authentifizierung.

    Für den Provider mit einer passwortbasierten Authentifizierung kann dies gefährlich werden, wenn ein unseriöser Consumer versucht, unvorsichtigen Nutzern die Zugangsdaten für den Provider zu stehlen. Dazu muss der Consumer nur den OAuth Vorgang vortäuschen und ein Popup-Fenster verwenden das zwar genau wie der Provider (zum Beispiel Facebook) aussieht, aber eigentlich eine Phishing-Seite ist. Passt der Nutzer nicht auf, gibt er seine Facebook Zugangsdaten ein und sendet diese direkt an den Consumer. Der Nutzer muss also stets sicherstellen, dass es sich bei der URL an die er weitergeleitet wird, wirklich um den Provider handelt (in diesem Fall Facebook).

    Das Problem kann umgangen werden, indem der Provider eine echte Zwei-Faktor Authentifizierung (z.B. SecSign ID) anbietet. Die passwortlose Anmeldung schützt die Nutzer vor dem möglichen Diebstahl der Zugangsdaten. SecSign löst die Passwortprobleme unter Zuhilfenahme einer Challenge-Response- Authentifizierung mit 2048-Bit RSA-Schlüsselpaaren. Passwörter werden somit überflüssig und sensible Benutzerdaten werden weder übertragen noch gespeichert. Das bedeutet, dass Hacker keine Gefahr mehr für Benutzerkonten darstellen, da schlicht und ergreifend keine Passwörter gestohlen werden können.

    Die Zwei-Faktor-Authentifizierungsmethode arbeitet dabei mit dem mobilen Gerät des Nutzers (also etwas, das sich in seinem Besitz befindet) und dem Wissen des Nutzers (der PIN zur Identitätsüberprüfung). Der Nutzer gibt für die Anmeldung am Provider lediglich seinen in der SecSign App selbstgewählten Benutzernamen an und bekommt ein Symbol angezeigt. Der Nutzer wählt dann seine SecSign ID in der App aus und gibt eine PIN ein. Durch die Auswahl des richtigen Symbols in der App wird der User bei dem gewünschten Provider angemeldet.

    4. Beispiel für die Implementierung mit PHP

    Im folgenden werden wir ein Beispiel implementieren welches folgendes Szenario darstellt:

    • Website A / OAuth Provider: die Website, auf die der Zugriff erlaubt werden soll. Jeder User hat ein persönliches Profil und kann eine Notiz speichern.
    • Website B / OAuth Consumer: die Anwendung ermöglicht es Notizen zu veröffentlichen. Der Consumer bietet dafür die Möglichkeit die Notiz von Website A abzufragen und zu veröffentlichen.

    Wie kommt Website B nun an die Daten des Nutzers von Website A, ohne Nutzernamen und Passwort zu verlangen? Hier kommt OAuth ins Spiel. OAuth macht es möglich, dass Website B auf die (per API zur Verfügung gestellten) Daten von Website A zugreifen kann ohne das der Benutzer jemals seine Login-Credentials für A an B geben muss.

    4.1 Vorbereitung

    Die folgenden Hinweise geben einen Anhaltspunkt, wie Sie einen OAuth2 Server bzw. OAuth Provider realisieren.

    Um Phishing Attacken zu verhindern setzen wir zur Authentifizierung am Provider die SecSign ID Zwei-Faktor Authentifizierung ein. Des weiteren wird die Session am Consumer gehasht und als state Variable an den Provider gegeben um CSRF Attacken zu unterbinden.

    Unser Beispiel bezieht sich auf eine lokale Testumgebung für den Provider und Consumer. Da die integrierten PHP Server Single Threaded sind, müssen 2 Instanzen erzeugt werden damit Provider und Consumer gleichzeitig kommunizieren können.

    Bitte beachten Sie, dass wir in diesem Beispiel Bearer-Token verwenden, welche mittels SSL/TLS abgesichert sein müssen. Bei einem lokalen Test können wir dies vernachlässigen, eine Produktiv-Umgebung dagegen muss entsprechende Sicherheitsmaßnahmen treffen und die, unter Anderem, Kommunikation per SSL/TLS oder MAC-Token absichern.

    Der Artikel erklärt die notwendigen Schritte und Dateien, um einen OAuth Provider mit 2FA und einen OAuth Consumer zu entwickeln und zu testen.

    Quellentext herunterladen

    Erstellen Sie einen neuen Ordner für den Provider und starten Sie den Webserver:

    Öffnen sie eine neue Konsole / Terminal und erzeugen sie eine neue Webserver Instanz für den Consumer:

    Für die weiteren Schritte wird Composer vorausgesetzt. Composer ist ein Paketmanager für PHP und installiert Abhängigkeiten (zum Beispiel: Bibliotheken) eines PHP-Programmes.

    4.2 OAuth Provider (Server)

    Die folgenden Hinweise geben einen Anhaltspunkt, wie Sie einen OAuth2 Server bzw. OAuth Provider realisieren. Wir nutzen die OAuth2-server-php PHP library , welche uns alle Funktionen etwas bequemer zur Verfügung stellt. Falls sie lieber eine andere Bibliothek oder andere Serversprache nutzen möchten, gibt es hier eine Übersicht.

    1. Abhängigkeiten installieren und Datenbank vorbereiten

    Mittels composer install werden alle Abhängigkeiten installiert. Dies sind OAuth2-server-php sowie secsignphphelper, welcher ohne großen Aufwand eine Zwei Faktor Authentifizierung erlaubt.

    Wechseln sie in das Verzeichnis secsign-provider und erstellen sie composer.json:

    Nutzen Sie das folgende Schema um die Standarddatenbank (MySQL, SQLite, PostgreSQL oder MS SQL Server) zu erstellen :

    2. OAuth2 Server

    Nun müssen wir unser OAuth2 Server-Objekt erstellen und konfigurieren. Das Server-Objekt wird von allen Endpunkten in unserer Anwendung verwendet.

    server.php :

    3. Token Controller

    Als nächstes erstellen wir den Token Controller. Diese URI gibt einen Token an den Consumer zurück.

    token.php:

    Beim Erstellen der Datenbank wurde bereits ein neuer OAuth Consumer bzw. OAuth Client (consumer1) beim Provider registriert.

    Ein Access-Token sollte erhalten werden:

    4. Resource Controller

    resource.php:

    Jetzt wo wir Tokens erstellen können, wollen wir sie auch validieren

    Der Resource Controller ist für die Ausgabe der Notizen zuständig. Im nächsten Schritt erstellen wir den Controller für die Autorisierung, welcher bei einer erfolgreichen Anmeldung dem Consumer einen dem Nutzer eindeutigen Code zurück gibt. Der Consumer kann nun mit seinen Credentials und dem Code des Nutzers einen Token anfordern. Geht alles gut, erhält der Consumer vom Token Controller einen Access Token. Dieser Access Token wird an den Resource Controller gesendet um die Notiz abzurufen. Der Resource Controller validiert den Token und sieht nach, ob ein Benutzer mit dem Token verknüpft ist. Wenn alles stimmt, wird die Notiz zum Consumer gesendet.

    5. Controller für die Authorisierung

    Der Controller zur Autorisierung ermöglicht den Benutzern, Anwendungen von Drittanbietern zu genehmigen. Statt den Access Token direkt zu vergeben (wie im ersten Token-Controller Beispiel) wird hier der Authorize-Controller verwendet, um nur dann ein Token ausgeben, wenn der Benutzer die Anforderung genehmigt hat.

    authorize.php:

    Mit folgender URL wird das Formular zur Autorisierung angezeigt. Wenn sich ein Nutzer nun mit der SecSign ID Zwei-Faktor Authentifizierung anmeldet, bestätigt er (in diesem Beispiel automatisch), dass er seine Notiz für „consumer1“ freigeben möchte:

    Der Authorisierungs-Code kann nun dafür genutzt werden, um den Access-Token anzufragen:

    Wenn alles klappt, erhalten sie den Access-Token, welcher dazu genutzt werden kann die eigentliche Resource (die Notiz) des Nutzers anzufragen:

    4.3 Oauth Consumer (Client)

    Die folgenden Hinweise geben einen Anhaltspunkt, wie Sie einen OAuth2 Client bzw. OAuth Consumer realisieren. Bisher haben wir den Provider manuell bedient, den gleichen Ablauf werden wir nun in einem simplen Beispiel-Consumer umsetzen. Um nur einen kurzen Überblick über die Funktionsweise des Consumers zu geben wurden Fehlerausgaben etc. weggelassen.

    Der Consumer besteht besteht nur aus der index.php:

    Wenn Sie nun im Browser http://localhost:8089 aufrufen erhalten Sie die Startseite des Consumers. Klicken Sie auf den Link, dass Sie eine Notiz übertragen möchten, werden Sie zum Provider weitergeleitet. Dort authentifizieren Sie sich mit Hilfe Ihrer SecSign ID und nehmen gleichzeitig die OAuth Autorisierung vor. War dies erfolgreich werden Sie zurück zum Consumer geleitet, welcher dann den Access Token anfragt. Wenn der Access Token vorliegt, kann die Notiz angefragt werden. Die Notiz kann dann weiter verarbeitet und gespeichert werden. Hier gibt der Consumer die Notiz einfach aus.
    Keywords: 2 factor authentication OAuth, Two-factor authentication OAuth, 2fa OAuth, How to use OAuth, How to integrate OAuth, OAuth php

    5. Unsere APIS

    Wir haben eine stetig wachsende Liste an APIs und Plugins um die SecSign ID Zwei-Faktor Authentifizierung einfach und schnell in jedes Projekt zu integrieren.
    Wir bieten nicht nur APIs in zahlreichen Programmiersprachen, sondern auch Plugins für CMS, Server und VPN Umgebungen, oAuth2 und zahlreiche mehr. Die Plugins nutzen unsere APIs und bieten zusätzliche Funktionen, zum Beispiel Nutzer Management, einfache und native Installation, Logging oder die Integration in Firewalls oder Active Directories.

    Das JIRA Plugin beispielsweise nutzt die JAVA-API. Die PHP-API und JS-API wird von WordPress, Joomla, Drupal, Typo3 und vielen anderen genutzt. Die ASP.net/C#-API wird für die Windows und Cisco VPN genutzt und die C-API findet Verwendung um Unix SSH Services zu schützen. Die Objective-C API wird für unsere AppleTV und iPhone und iPad Apps genutzt.

    available_apis

    6. Erfahren Sie mehr

    Sie können die SecSign ID Zwei-Faktor Authentifizierung und den Zwei-Faktor Login durch eine einfach Integration des Plugins in Ihre Website oder Ihre Testumgebung kennenlernen. Oder testen Sie den Login auf unserer Website, ohne sich vorher zu registrieren. Sie haben bereits eine SecSign ID oder hätten gerne eine? Loggen Sie sich jetzt ein und nutzen Sie das Portal oder registrieren Sie sich ganz unkompliziert.

    Erfahren Sie selbst, wie schnell und unkompliziert der Login Prozess mit der Challenge-Response Authentifizierung mit 2048-bit Schlüsselpaaren ist. Sie brauchen keine Passwörter, und es werden keine vertraulichen Logindaten übertragen. Einfache Integration und unkomplizierte Nutzung.

    Für mehr Informationen zum patentierten SafeKey Verfahren finden Sie hier.

    Falls Sie eine API für eine Programmiersprache vermissen kontaktieren Sie uns unverbindlich. Falls Sie Hilfe mit der Integration in ein existierendes System brauchen oder kein passendes Plugin für Ihr Content Management System finden, kontaktieren Sie unser Support Team und wir helfen Ihnen gerne weiter.

    Ihr eigener ID-Server

    Die Inhouse Installation der SecSign ID bietet Ihnen die Flexibilität, sich mit Ihren bevorzugten Server, Services und Geräten zu verbinden. Passen Sie die SecSign ID Ihrer Unternehmensmarke an!

    your_own_id

    Warum sollte ich SecSign nutzen?

    Inhouse oder Cloud Lösungen

    Unsere Lösungen lassen sich leicht anpassen: Wählen Sie zwischen der durch uns betriebenen SecSign Cloud oder betreiben Sie selber den SecSign Authentifizierungsserver Inhouse oder in einem Rechenzentrum Ihrer Wahl. Mehr zum Inhouse Zwei-Faktor Authentifizierungsserver

    Einfache Anpassung an Ihre Bedürfnisse

    Wir passen die App an ihre Unternehmens Look-and-Feel an. Zwei-Faktor Authentifizierung angepasst an Ihre Bedürfnisse, für Ihre Kunden.

    Anwendungsfertiges SDK

    Integrieren Sie die SecSign Zwei-Faktor Authentifizierung in existierende Apps mit unserem SDK. Es könnte nicht einfacher gehen.

    Unkompliziertes Nutzer-Management

    Nutzen sie den Zwei-Faktor Authentifizierungsserver zum Schutz Ihres Active Directory/LDAP. Ihr individuelles Identity and Access Management System, beispielsweise mit verpflichtenden Updates und zahlreichen Sicherheitseinstellungen.

    Schützen Sie ALLE Logins

    Integration in sämtliche Login-Umgebungen: Web, Local, VPN, Remote Desktop, Mobile Logins und viele mehr.

    Plugins für alle Anwendungsgebiete

    Komplexe Integrationen gehören der Vergangenheit an: SecSign bietet Ihnen Plugins für nahezu alle Umgebungen.

    Letzte Blog Einträge, Neuigkeiten & Funktionen

    Crowd SSO

    21.09.2017

    Read More
    Do NOT follow this link or you will be banned from the site!