In this post, we will describe the implementation in a bit more detail.
First we will describe the database schema for the OAuth.
Then we will describe the logic in the controllers that will validate and filter out the bad requests and those explicitly prohibited.
Then we will describe the tests for the webUI Integration. All along the  implementation we will use the features available from the existing proxy and stage the changes needed to remove the proxy.
First among these is the schema for the token table. This table requires a mapping for the userId and the clientId together with the issued token. This table is entirely for our compliance with OAuth security caveats and hence user, clients and proxy are unaware of this table and will not need to make any changes on their side due to any business rules associated in this table as long as they are OAuth compliant. Since the token is issued by the proxy, we will need to keep token request and response information in this table. In addition, we will record the apiKey and clientId from the client along with the token even though the proxy may be enforcing this already. (Note clientId is internal and apiKey is public and they are different.) This as described in the previous post helps us know who the token was originally intended for and whether, if any, misuse occurs by a third client. And we will keep the user mapping as optional or require a dummy user since some clients may request credentials only to access non-privileged resources. It could be interesting to note that the userId is entirely owned by our API and retail company but the check for an access token issued on behalf of one user to be used with only that user's resources is currently enforced by the proxy.  That means the proxy is keeping track of the issued token's with the user context or is passing the user context back to the API with each incoming token.
But we have raised two questions already. First - Should we treat user context as nullable or should we default to a dummy user. Second - Does the proxy pass back the user context in all cases or should the API implement another way to lookup user given a token for non-proxy callers ?
Let us consider the first. The requirement to have a non-nullable field and have a default value for client credential only calls, is certainly improving validation and governance. Moreover, we can then have a foreign key established with the user table so that we can lookup user profile information directly off the token after token validation. This leads the way to removing the ugly "/user/me" resource qualifier from all the apis that access user privileged resources. The userId is anyways internal usage only so the APIs look cleaner and we can internally catalog and map the APIs to the type of access they require. This means having another table with all the API routes listed and having classified access such as user privileged or general public.  This table is not just an API-Security table but also provides a convenient placeholder for generating documentation and checking correctness of listings elsewhere. Such additional dedicated resources for security could be considered an overhead but we will try to keep it minimal here. Without this table we will assume that each API internally applies the UserId retriever ActionFilterAttribute to those that require to access privileged resources and the retriever will apply and enforce the necessary security.
We will also answer the second question this way. The proxy provides user information via "X-Mashery-Oauth-User-Context" in the request header. This lets us know that the token has been translated to a user context and the proxy has looked it up in a token database.  This token database does not serve our API Security otherwise we would not be discussing our schema in the first place. So lets first implement the schema and then we will discuss steps 2 and 3.

Improvements to OAuth 2.0 if I could venture to guess:
1) Tokens are not hashes but an encyrption provided in request and response body. Token is an end result representing an agreement between user, client, and one or more parties. A given token could be like a title on an asset immediately indicating the interests vested in the asset - be it the bank, an individual or third party.  However the token must be interpretable to the authorization server alone and nobody else. It should be opaque to both the user and the client and understood only by the issuer to repudiate the caller and the approver. The client and the user can use their state and session properties respectively to repudiate the server. In both cases, this has nothing to do with the token.  Such a token processing obviates the persistence of tokens in a store for lookup by each API call. This moves the performance overhead from storage and cpu to mostly cpu based which should be welcome on server machines. That said, almost every api makes a call to a data provider or database and yet another call to associate a hash with a user and a client is not only simpler but archivable and available for audit later. Test will find this option easy, more maintainable and common for both dev and test. This option also scales up and out just like any other api call and since its a forward only rolling population, there is possibility to keep the size finite and even recycle the tokens. The internal representation of user and client has nothing to do with the information exchanged in the querystring so the mapping is almost guaranteed to be safe and secure. This approach also has conventional merits of good bookkeeping with the database technologies such as the ability to do change data capture, archivals, prepared plan executions etc. In the encryption based token scenario, the entire request and response capture may need to be taken for audit and then parsed to isolate the tokens and discover their associations. Each discovery may need to be repeated over and over again in different workflows. Besides an encrypted string is not easy to cut and paste as is the simplicity of a hash and the cleartext on the http. That said, encryption of request parameters or for API call signatures are anyways used in practice so the adoption of an encryption based token should not have a high barrier to adoption. Besides, the tokens are cheap to issue and revoke.
2) Better consolidation of the grant methods offered. This has been somewhat alluded to in my previous post and it will simplify the endpoints and the mechanisms to what is easy to propagate. For example, the authentication code grants and the implicit code grants need not be from an endpoint different from the token granting endpoints since they are semantically the same. Code to token and refresh could be considered different but at the end internal and external identifiers will anyways be maintained be it for user, client or token. Hence, the ability to treat all clients as one and access tokens with or without user privileges and all requests and response as pipelined activities will make this more streamlined. Finally, an OAuth provider does not need to be distributed between the proxy and the retailer. In some sense, these can all be consolidated in the same stack.

The TFS Query object is used to run queries stored on the TFS Server. When this class is instantitated, the constructor requires two or more parameters named WorkItemStore and WIQL text. The WIQL text can be navigated to using the QueryFolder and QueryDefinition for 'Shared queries' folder and the name of the query respectively and using the QueryText property on the QueryDefinition. However if the WIQL text has a reference to variables such as '@Project' it throws the TFS Error. Ok. That had to do with wrapping constants in quotes and TFS permissions and this is now automated.

Assuming that security provided by an OAuth implementation for REST APIs is a layer above the actual APIs for various services, there should be no logic within the API implementation that

checks the user or client or their mapping to a token. That should be taken care of such that all API implementations except for the OAuth ones will work for all callers. In such a case,

the APIs should uniformly be governed by this security declaration. One way to implement that would be to declare an ActionFilterAttribute such that all APIs can be decorated with it. This

provides a uniform security declaration.
The Implementation for this ActionFilterAttribute can for example check the following:
1) validate the api key that it belongs to a known set of registered clients
2) validate the access token by pulling up the corresponding userId, clientId and mapping
These implementations are at the controller level but can be expanded to private methods and extensions
The attribute itself may be packaged in a separate assembly say the OAuth2.Provider.web.dll and made available via Nuget.
The checks for UserID may already be available via API implementations that rely on aliases for userID.
The checks for ClientID and Token mapping require talking to OAuthProviders either local or remote and hence they need additional configuration sections to retrieve these values from.
The last check can be applicable across all APIs since the apiKey and accessTokens are available to each.
The mapping for the tokens could be stored centrally in the same database as the user profiles from where userId is validated.

This post continues from the previous post in that we discuss the validations for client and the client authorizations. Specifically, we did not mention the state parameter and its use to thwart cross site forgery attacks. such attack is mounted when a victim user agent is made to follow a malicious URI to a trusting server. An attacker usually injects its own access token to make the victim client post sensitive user information to the attacker's protected resources instead of the user's resources. The, OAuth server associates an access token to a user. Given an access token, it will correctly resolve the user associated with the token but it may not detect that an access token has been replaced because the same client could have been authorized by more than one user. With this injected token,  the attacker is able to hijack the session and gain access to sensitive information.
CSRF protection becomes necessary. The redirection URI is typically protected by requiring any request to include  a value that binds the request to the user agents authenticated state such as a hash of the session identifier in the state parameter.
This additional information enables a client to verify the validity of the redirects. This is simple for the clients to enforce and hard for the attacker to circumvent.
The authorization server must also enforce such CSRF protection for its authorization endpoint and enforce that a malicious client cannot gain an access token without user intervention.

In OAuth implementation, There are four kinds of TokenProviders. These are ResourceOwnerTokenProvider, ClientCredentialTokenProvider, AuthorizationCodeTokenProvider and RefreshTokenProvider. It's the TokenProvider that implements the checks for valid user Id and valid client Id. Therefore, the TokenProvider should also implement the check to see that the token is mapped to the same user Id and ClientId as expected. The access    token need not be stripped by the proxy. If the proxy strips the access token and forwards it on to the API implementation, then it should implement the check to see that the token maps to the user and the client correctly. Unless the access token is received by the API implementation, it is hard for the API to validate the same. The only mitigation in such a case is to keep a registry of all TokenProvider calls such that the incoming clientIds are recorded and queried against the proxy. If a client registry fails the proxy lookup, then it should be denied any tokens. For clients that are registered but not user authorized, we look it up with another call to the proxy asking for the applications allowed by the client. If two clients are registered and authorized by the same user, the registry for clientId and accessToken maintained by the API will mitigate the hijacking of token between these two clients. This step by step check is only necessary when we are relying on a proxy that doesn't automatically validate the clients before issuing the tokens to them. These steps rely on the assumption that the proxy provides methods for lookup a client information based on the client Id and to list all the clients authorized by a given user.

When the API has its own implementation of an OAuthProvider, instead of relying on the proxy, then the token database maintained by the API will have an association between the token, the user and the client. That enables a single central checkto validate a given access token instead of authenticating a client.
OAuth RFC mentions there are more than one way to authenticate a client and the common practice being the use of a client credential such as a client id and a client secret. The other kinds of client authentication can be password or public/private 

key pair. The only thing the RFC mentions as a must is that the clients should not be authenticated by their apikey or clientid alone since it is public and can be switched. Therefore a lookup of the client secret against a client registry is required. This client secret is sent to the authorization server in the request body as opposed to the apikey that's passed as 

query string. Further, the RFC distinguishes the clients as confidential clients and public clients saying the confidential clients should have a client authentication method.

In OAuth, There are four kinds of TokenProviders. These are ResourceOwnerTokenProvider, ClientCredentialTokenProvider, AuthorizationCodeTokenProvider and RefreshTokenProvider. It's the TokenProvider that implements the checks for valid user Id and valid client Id. Therefore, the TokenProvider should also implement the check to see that the token is mapped to the same user Id and ClientId as expected. The access token need not be stripped by the proxy. If the proxy strips the access token and forwards it on to the API implementation, then it should implement the check to see that the token maps to the user and the client correctly. Unless the access token is received by the API implementation, it is hard for the API to validate the same. The only mitigation in such a case is to keep a registry of all TokenProvider calls such that the incoming clientIds are recorded and queried against the proxy. If a client registry fails the proxy lookup, then it should be denied any tokens. For clients that are registered but not user authorized, we look it up with another call to the proxy asking for the applications allowed by the client. If two clients are registered and authorized by the same user, the registry for clientId and accessToken maintained by the API will mitigate the hijacking of token between these two clients. This step by step check is only necessary when we are relying on a proxy that doesn't automatically validate the clients before issuing the tokens to them. These steps rely on the assumption that the proxy provides methods for lookup a client information based on the client Id and to list all the clients authorized by a given user.