Thanks for posting this! Great overview of potential implementation flaws. From the article: In some RPs, access tokens are appended as query parameter

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 http://tools.ietf.org/html/rfc6750#section-2 [1]: http://tools.ietf.org/html/rfc6750#section-5.3 http://tools.ietf.org/html/rfc6750#section-5.3