OAuth 2 LogoSo, jetzt muss ich mich auch mal zu der OAuth Geschichte äußern! Wer nicht weiß warauf ich anspiele, der sollte sich zuerst mal Eran Hammers Blogpost durchlesen: OAuth 2.0 and the Road to Hell.

Auf alle Kritikpunkte von Eran Hammer möchte ich gar nicht eingehen… Ich kann seine Kritik durchaus verstehen und teile sie auch weitestgehend. Auch ich bin generell der Freund von schlanken Spezifikationen und hasse Standards die versuchen alles abzudecken und jedes Format zu unterstützen.

Abgesehen von den ganzen Sicherheitsaspekten und dem Fokus auf “Enterprise”-Anwendungen welche Eran Hammer in seinem Artikel erwähnt, hat mich die Fehlende Interoperability von OAuth 2 zuerst am Meisten genervt:

OAuth 2.0 provides a rich authorization framework with well-defined security properties. However, as a rich and highly extensible framework with many optional components, on its own, this specification is likely to produce a wide range of non-interoperable implementations.

Mein erster Gedanke: Na toll! Man macht sich hier Gedanken über dezentrale Netzwerke, für die man einfache und simple Spezifikationen braucht und Familie OAuth released ein “Framework”…

Aber eigentlich ist ja gerade das auch eine riesen Chance für das Web! Während OpenID Connect bestimmt, dass jeder Provider die komplette Spezifikation implementieren muss:

The OpenID Connect Basic Client profile only documents Clients using the Code Flow. OpenID Providers MUST support both flows. OpenID Providers should consult the OpenID Connect Standard 1.0 Specification.

bleibt es jedem frei gestellt welchen Teil von OAuth 2 er umsetzt… Also warten wir doch einfach ab, bis das “Framework” fertig ist, suchen uns die für das Web eleganteste Variante raus, dokumentieren sie schön und fertig ist “OAuth 2 – The Web Edition“.

…nicht perfekt, aber es könnte auch schlimmer sein!

openid-complex

Hat der erste Entwurf von OpenID Connect noch auf eine (übersichtliche) Seite gepasst, braucht der Draft der OpenID Foundation schon 7 unterschiedliche Spezifikationen.

Wieso müssen “Standard”-Organisationen wie das W3C (z.B. RDFa) oder der OpenID Foundation denn alles so unnötig kompliziert machen? Immerhin schafft es ja sogar Facebook seinen Authentifizierungsprozess auf einer Seite zu erklären. …und noch besser! Er lässt in drei Sätzen zusammenfassen:

  1. Hol dir über folgende URL einen Access-Token:
    https://www.facebook.com/dialog/oauth?
    client_id=YOUR_APP_ID&redirect_uri=YOUR_URL
  2. Häng ihn an folgende URL, auf den du den User weiterleitest:
    https://www.facebook.com/dialog/oauth?
    client_id=YOUR_APP_ID&redirect_uri=YOUR_URL&
    scope=email,read_stream
  3. Fertsch!

…dazu kommen eine weitere Discovery-Variante die Webfinger, host-meta, XRD, XRDS oder YADIS komplett ignoriert und eine Identity-API die SREG oder AX noch nicht einmal ähnelt!

Mike Jones, einer der Hauptentwickler der Spezifikation, schreibt zwar:

The design philosophy behind OpenID Connect is “make simple things simple and make complex things possible”.

Das ist aber nur die halbe Wahrheit. Webseitenbetreiber, die zukünftig einen OpenID Connect Login anbieten wollen, haben es in der Tat etwas einfacher, da sie sich auf die “Minimalanforderungen” konzentrieren können. Seiten die einen OpenID Connect Provider stellen wollen haben aber folgendes Problem:

Authorization Requests can follow one of two paths; the Implicit Flow or the Authorization Code Flow. [...]
The OpenID Connect Basic Client profile only documents Clients using the Implicit Flow. OpenID Providers MUST support both flows. [...]

Damit begeht die OpenID Foundation wieder den gleichen Fehler wie bei OpenID 2.0. Am Schluss gibt es so viele unterschiedliche und halbfertige Implemenrierungen, dass man wieder auf SaaS-Dienste wie Janrain oder Gigaya zurückgreifen muss. Wozu braucht es dann noch einen “Standard”?

Warum denn immer 1000 Alternativen anbieten? Bei Facebook klappts ja auch ohne…

BrowserID

Ich schreibe gerade einen Artikel für das t3n Magazin über aktuelle Sign-In-Mechanismen und hab mir in dem Zuge BrowserID mal etwas genauer angeschaut. Ich bin wirklich extrem überrascht mit wie wenig Arbeit es sich in z.B. WordPress einbauen lässt.

BrowserID besteht eigentlich nur aus einem JS-File,ein paar Zeilen JS-Code:

<script src="https://browserid.org/include.js" type="text/javascript"></script>
<script type="text/javascript">
navigator.id.get(function(assertion) {
    if (assertion) {
        // This code will be invoked once the user has successfully
        // selected an email address they control to sign in with.
    } else {
        // something went wrong!  the user isn't logged in.
    }
});
</script>

und dem anschließenden Verifizieren der assertion:

$ curl -d "assertion=&audience=https://mysite.com" "https://browserid.org/verify"
{
    "status": "okay",
    "email": "lloyd@example.com",
    "audience": "https://mysite.com",
    "expires": 1308859352261,
    "issuer": "browserid.org"
}

Den ausführlichen Ablauf der Authentifizierung findet ihr auf Github.

Um BrowserID in WordPress zu integrieren lädt man also zuerst den JS-Code in den Login Header:

// add the BrowserID javascript-code to the header
add_action('login_head', 'bi_add_js_header');
function bi_add_js_header() {
  echo '<script src="https://browserid.org/include.js" type="text/javascript"></script>';
  echo '<script type="text/javascript">'."\n";
  echo 'function browser_id_login() {
    navigator.id.get(function(assertion) {
      if (assertion) {
        window.location="' . get_site_url(null, '/') .'?browser_id_assertion=" + assertion;
      } else {
        // do nothing!
      }
    })
  };'."\n";
  echo '</script>';
}

und platziert den BrowserID-Button auf der Login-Seite:

// add the login button
add_action('login_form', 'bi_add_button');
function bi_add_button() {
  echo '<p><a href="#" onclick="return browser_id_login();"><img src="https://browserid.org/i/sign_in_blue.png" style="border: 0;" /></a></p>';
}

Nach dem klick auf den Button öffnet sich das Autorisierungs-Fenster von BrowserID und nach dem erfolgreichen Sign-In wird die gerade implementierte Methode navigator.id.get(function(assertion) {} aufgerufen.

BrowserID login window

Im nächsten Schritt muß man die erhaltene assertion über BrowserID.org verifizieren. Da ich den notwendigen POST nicht über JavaScript absetzen will, leite ich einfach auf eine Seite weiter und übergebe die erhaltene assertion als GET-Paramater.

if (assertion) {
  window.location="' . get_site_url(null, '/') .'?browser_id_assertion=" + assertion;
}

Jetzt kann der POST bequem über WordPress abgesetzt werden.

// the verification code
add_action('parse_request', 'bi_verify_id');
function bi_verify_id() {
  global $wp_query, $wp, $user;

  if( array_key_exists('browser_id_assertion', $wp->query_vars) ) {
    // some settings for the post request
    $args = array(
      'method' => 'POST',
      'timeout' => 30,
      'redirection' => 0,
      'httpversion' => '1.0',
      'blocking' => true,
      'headers' => array(),
      'body' => array(
        'assertion' => $wp->query_vars['browser_id_assertion'], // the assertion number we get from the js
        'audience' => "http://".$_SERVER['HTTP_HOST'] // the server host
      ),
      'cookies' => array(),
      'sslverify' => 0
    );

    // check the response
    $response = wp_remote_post("https://browserid.org/verify", $args);

    if (!is_wp_error($response)) {
      $bi_response = json_decode($response['body'], true);

      // if everything is ok, check if there is a user with this email address
      if ($bi_response['status'] == 'okay') {
        $userdata = get_user_by('email', $bi_response['email']);
        if ($userdata) {
          $user = new WP_User($userdata->ID);
          wp_set_current_user($userdata->ID, $userdata->user_login);
          wp_set_auth_cookie($userdata->ID, $rememberme);
          do_action('wp_login', $userdata->user_login);

          wp_redirect(home_url());
          exit;
        } else {
          // show error when there is no matching user
          echo "no user with email address '" . $bi_response['email'] . "'"; 
          exit;
        }
      }
    }
    
    // show error if something didn't work well
    echo "error logging in"; 
    exit;
  }
}

Gibt es einen User mit der entsprechenden E-Mail – Adresse wird er eingeloggt, falls nicht, wird ein Fehler ausgegeben.

Bei der Demo hab ich mir aus Zeitgründen ein wenig Code bei Marcel Bokhorst geliehen, dessen BrowserID-Plugin wesentlich ausgereifter und vollständiger ist als der kleine Demo-Code den ich hier zusammengestückelt habe.

Wenn euch das zu schnell ging und ich auf einige Details nicht genügend eingegangen bin, könnt ihr gerne fragen :)

Ich habe den kompletten Code übrigens auch auf Github hochgeladen… das ist einfacher als sich alles zusammen zu kopieren.

Was das OpenWeb so kompliziert macht ist das Wörtchen “alternativ“!

  • OpenID Discovery basiert auf Meta-Tags, alternativ funktioniert aber auch XRDS(-Simple)/Yadis oder Webfinger.
  • OpenID stellt über SREG Profilinformationen bereit, alternativ aber auch über Attribute Exchange.
  • RDFa 1.1 ist folgendermaßen aufgebaut:
    <html
      prefix="foaf: http://xmlns.com/foaf/0.1/"
      >
      ...
      <span property="foaf:name">John Doe</span>
      ...
    </html>

    alternativ aber auch:

    <div vocab="http://xmlns.com/foaf/0.1/" about="#me">
      <span property="name">John Doe</span>
    </div>

    …oder:

    <div profile="http://xmlns.com/foaf/0.1/" about="#me">
      <span property="foaf:name">John Doe</span>
    </div>
  • OpenSocial, oEmbed, ActivityStrea.ms und host-meta benutzen JSON, alternativ aber auch XML
  • OAuth verschlüsselt mit HMAC-SHA1, alternativ aber auch mit RSA-SHA1 oder PLAINTEXT

To be continued…

Wie viel Komplexität man sich sparen könnte wenn man sich auf eine Variante beschränken würde.

…und das Open Web kennt mindestens genau so viele Wörter für “Name”!

Ich hab mir letzte Woche mal den aktuellen Draft von OpenID Connect angeschaut und mich riesig gefreut, dass die OpenID-Community ihrer Linie treu bleibt und dem User-Schema wieder komplett neue Bezeichnungen gibt. Aber das scheint ein genereller Spaß in OpenWeb-Kreisen zu sein. Ich hab mir mal einen Spaß d’raus gemacht einzelne Bezeichnungen verschiedener “Standards” die mit Profil/User-Infos zu tun haben, zu vergleichen.

Claims für den kompletten “Namen” eines Users:

  • fn (vCard, hCard)
  • name (foaf, OpenID Connect, Facebook Connect, schema.org)
  • fullname (OpenID SREG)
  • namePerson (OpenID AX)
  • displayName (Portable Contacts, Open Social, Activity Streams)

Claims für den “Nachnamen” eines Users:

  • given name (vCard)
  • given-name (hCard)
  • lastName (foaf)
  • family_name (OpenID Connect, Facebook Connect)
  • namePerson/last (OpenID AX)
  • givenName (Portable Contact, Open Social)

Gut dass wir das W3C, die WHATWG, die IETF und diverse ander Standard-Organisationen haben die in jahrelanger Arbeit Standards wie RDF, XML, JSON, RDFa und Microdata spezifizieren und dann jeder, wie er gerade bock hat, ein Schema dafür baut :D

Schema.org und das Open Graph Protocol sind perfekte Beispiele dafür, wie man gekonnt bestehene Schemas ignoriert und einfach macht, wie man denkt!

P.S. Ich weiß dass man die Bezeichnung “Eskimo” eigentlich nicht mehr benutzt und wehe mir nimmt jemand den Mythos mit den 90 Wörtern für Schnee ;)