Thanks for posting this! Great overview of potential implementation flaws. From the article:

    In some RPs, access
    tokens are appended as query parameters to the RP's sign-in
    endpoint (i.e., the URI that issues the authenticated session
    cookie), which reveals the tokens in the browser's history
    and server logs.

The official spec only supports including the access token in a URL-encoded body of a POST request, or as part of an Authorization header [0]. This is one of the biggest differences between the official spec and most current (not up to spec) implementations.

Also disappointing^H^H^H^H^H^H^H^H^H^H^H^H^H interesting:

    Surprisingly, our evaluation shows that only 21% of RPs em-
    ploy SSL to protect SSO sessions, even though about half of
    tested RPs have protected their traditional login forms with
    SSL.

The relevant part of the specifcation [1]:

     Always use TLS (https):  Clients MUST always use TLS [RFC5246]
     (https) or equivalent transport security when making requests with
     bearer tokens.  Failing to do so exposes the token to numerous
     attacks that could give attackers unintended access.

[0]: http://tools.ietf.org/html/rfc6750#section-2 [1]: http://tools.ietf.org/html/rfc6750#section-5.3