...
OAuth 2.0 Service Provider for Apache Shindig
Eric Woods and Matthew Marum are implementing support for an OAuth 2.0 Service Provider in Apache Shindig. This article provides an overview of the implementation including high level design, supported flows, common How-Tos, and future considerations.
The OAuth 2.0 specification is here: http://tools.ietf.org/html/draft-ietf-oauth-v2-20
Note that the implementation is still evolving, so consider this design document to be a draftOAuth 2.0 support is ENABLED by default. However, clients can still anonymously access the Social APIs using the default AuthenticationHandlerProvider. To prevent anonymous access to Shindig's Social APIs, modify the existing one or create your own AuthenticationHandlerProvider. See the How-Tos section below for details.
High Level Design
All OAuth 2.0 requests are received by the OAuth2Servlet. Per the spec, there are two OAuth 2.0 related endpoints: /oauth/authorize and /oauth/token. The request is quickly delegated to either the OAuth2AuthorizationHandler or the OAuth2TokenHandler accordingly.
...
We provide "poor-man" implementations of the two service interfaces; the OAuth2ServiceImpl uses in-memory data structures, and the OAuth2DataServiceImpl uses canonical.json.
OAuth 2.0 Flow Support
- Authorization Code Flow (done)
- Implicit Grant Flow (done)
- Client Credential Flow (done)
User Authentication
User authentication for this OAuth 2.0 service provider is handled through the sample ShiroFilter that Shindig also used for the OAuth 1.0a implementation. This means our service provider makes assumptions that requests to our authorization endpoint have been user authenticated by the time they are received.
How-Tos
How to Enable/Disable OAuth 2.0 Security
OAuth 2.0 support is enabled in Shindig's default AuthenticationHandlerProvider.
OAuth 2.0 support can be added to your existing AuthenticationHandlerProvider by adding the OAuth2AuthenticationHandler to the chain. The OAuth2AuthenticationHandler ensures that requests for protected resources (the Social REST APIs) include valid access tokens in the form of Bearer tokens as defined in the OAuth 2.0 specs.
If your AuthenticationHandlerProvider doesn't return the OAuth2AuthenticationHandler, access tokens will not be checked when clients access protected resources (the Social REST APIs).
If necessary, you can disable the OAuth2 access token and authorization endpoints by removing mappings for the OAuth2Servlet in the Shindig web.xml.
How to Register a Client
Clients are pre-registered in canonicaldb.json. Client registration, authorization codes, access tokens, and refresh tokens are keyed by client. Here's the current structure (subject to change):
...
TODO: where and how are grant handlers registered?
How to Enable/Disable OAuth 2.0 Security
You can add OAuth2 support to protect your Social APIs by using an AuthenticationHandlerProvider that provides the OAuth2AuthenticationHandler. The OAuth2AuthenticationHandler ensures that requests for protected resources (the Social REST APIs) include valid access tokens.
You can disable the OAuth2 access token and authorization endpoints by removing mappings for the OAuth2Servlet in the Shindig web.xml
If your AuthenticationHandlerProvider doesn't return the OAuth2AuthenticationHandler, access tokens will not be checked when clients access protected resources (the Social REST APIs).
Future Considerations
Currently, the entire OAuth 2.0 implementation is located in a single package within Shindig's social-api module. We need to determine the most appropriate way to integrate this package into shindig. We could integrate this package into social-api following the existing patterns, or it may even be broken out as an entirely new module within Shindig. To be determined...
...