OAuth 2.0 Flow Support

The OAuth 2.0 Specification describes four methods (flows) for obtaining access tokens

1. Authorization Code (3-party) http://tools.ietf.org/html/draft-ietf-oauth-v2-21#section-4.2
2. Implicit Grant  http://tools.ietf.org/html/draft-ietf-oauth-v2-21#section-4.1
3. Resource Owner Password Credentials  http://tools.ietf.org/html/draft-ietf-oauth-v2-21#section-4.3
4. Client Credentials (2-party)  http://tools.ietf.org/html/draft-ietf-oauth-v2-21#section-4.4

Authorizatoin Code is the flow that makes the most sense for a web application, like the shindig WAR, and was the primary focus of the implementation.

Implicit Grant was intended for user agents (e.g. Javascript in a browser) and depends on redirects to URIs with token data embedded in the fragment.  We can't help out much here, but don't do anything to preclude gadgets from handling implicit grant flows on their own.

Resource Owner Password Credentials (ROPC.)  Writing credential vault code to safely enter/store/manage user credentials for external servers is beyond the scope of the OAuth 2.0 client.  HOWEVER, if there was a credential vault in shindig a ROPC flow handler could be injected into the system.

Client Credentials could be handled rather simply and was implemented and tested in this reference implementation.