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.

OAuth testing discussion continued
we had discussed a few test cases with OAuth earlier. The server has to validate a response.