Requests for comment/Service-oriented architecture authentication

Problem statement
With many more entry points and the need for inter-service authentication, a service-oriented architecture requires a stronger authentication system.

Goals

 * Single sign-on support
 * Support a relatively timely revocation of rights (minutes)
 * Minimize the risk & impact of exploits:
 * Principle of least privilege: for example, most services should not have direct access to sensitive user information (password hashes etc)
 * Minimize the risk of confused deputy attacks and attack surface by primarily trusting unforgeable user capabilities rather than services, and always checking capabilities at the lowest possible layer (example: storage service)
 * Be efficient for high request volumes (APIs)
 * No synchronous checking with other services required for common requests (reads in particular)
 * Small token size to minimize network overhead in particular for non-SPDY clients
 * Follow best security practices, use established standards & existing implementations
 * Support derivative and asynchronous requests like link updates
 * But don't allow them directly

OpenID connect / OAuth2 + Bearer tokens

 * All authenticated traffic uses TLS
 * Authentication service is only service that has access to sensitive user information
 * Client authentication
 * Normal browser auth / our domains: Bearer token is set in HTTP-only cookie (instead of session id)
 * Cross-domain: Client follows the normal OpenID connect token request flow with auth service
 * retrieves time-limited signed Bearer token
 * token encodes common access rights like 'read article' (in signed JWT)
 * Client sends token with each request (SPDY can make sure it only goes over the wire once)
 * Most backend services have no special rights; they merely forward the user-provided token to other services
 * Checking happens at the lowest possible layer to avoid multiple entry point issues. Example: storage service
 * Common requests like read only require a signature and timestamp check
 * Less common requests require calls back into auth service to establish rights
 * CSRF tokens for state-changing operations provided and verified by the auth service on behalf of backends (storage service for example)
 * performance not as critical as those operations are rare compared to reads
 * Authenticate derivative requests when enqueuing them, based on per-queue ACLs. Once authenticated & enqueued, an additional signed assertion added by the queue removes the auth timeout, so that jobs will be able to complete in the background. Ideally such jobs are idempotent and depend on a primary authenticated request having gone through. This would make them relatively harmless & avoid the need for additional protection against making those requests directly beyond not exposing them publicly.

OpenID connect is used by: PayPal, Microsoft, Salesforce, Google, Deutsche Telekom, mobile carriers (GSMA) etc

Status quo
The MediaWiki PHP codebase performs all authentication and authorization checks internally.

It provides:
 * Account creation and autocreation
 * Authentication (password, or plugin based)
 * Authorization / session management
 * Sets up the appropriate User object (e.g., $wgUser) for each request, before MediaWiki processes the request
 * MediaWiki uses the User object for most code that determine authorization
 * The User object tracks if the user has been blocked, and can validate anti-CSRF tokens for the user's session
 * Logout (destroy the session)

This RFC is about handling these tasks in a service with a well-defined interface.