Discussion continued

In the previous post we discussed interactions for OAuth. In this post we focus on the provider side interactions. The proxy and the API both participate in token and code grant. The proxy maintains the token database and the API maintains the user database. When the client calls in without a user context, the grants have lesser privileges. When the client calls in with a user context, the grants have more privileges. The API implements the OAuth endpoints that the webUI calls or clients call and internally there are handshakes between the proxy and the API before a grant is issued. As you can see there's several interactions between the proxy, the client, the user and the API including cross communication. First, the client talks to the token endpoint, then the API talks to the token provider, then the API returns the token as in the case of client credentials. If the user is involved, the user first talks to the WebUI, then the WebUI talks to the API which then talks to the token provider and then the token is passed to the client.
When the user signs on at the webUI through any client, then the API gets a call to an internal or external endpoint for OAuth. At that point, it is a mere convenience for the API to rely on external  token provider to return a token. It is better for the API to own the mapping between userId and client Id since such provisioning is easy and brings in the control over what clients can selectively be treated differential-ly. For example, the company's mobile application might be a client that should have high availability over other clients. Also the company's mobile application could have access to internal endpoints. Internal endpoints are different from external in many ways but I would like to draw attention to one call out item. External endpoints could be hosted by any proxy or in a third party cloud hosted by yet another network. There could be significant delays in the responsiveness of the APIs. This is not just a maintenance issue, its actually a significant usability issue. User attention span can be assumed to span a handful of seconds and even on mobile devices, frequent round trips may need to be avoided.
Network delays, heterogeneous networks and cloud services provide a significant challenge to the responsiveness of the APIs to various clients.
When we talk about the company's mobile application, we could consider diverting the traffic to networks within direct control of the company or a direct lease with a cloud provider.
This argument is made in the favor of differentiating clients but in general the point here is that network responsiveness the APIs may be even more important than the resource management such as CPU or memory for the API providers. CDNs could also help but they are very different from what APIs are used for.
Moreover statistics and call history of APIs are better grouped with clients rather than users.

membership providers

membership providers have their own validation routines. For example, MembershipProvider.ValidateUser checks if the user specified is valid. The membership provider changes in OAuth and hence corresponding validations  should occur by the OAuth provider or in this case, the website. In OAuth, the sessions are maintained by the other website that requests OAuth. This causes the user to reauthenticate after a specified time. For the most part refresh tokens are sufficient to keep accessing protected resources.
UserId lookup is associated with the WebUI login process. All callers to APIs could require the alias of "me" for the user Id. This way they don't need to know the user Id. However internally for APIs that are secured through OAuth, the access token is associated with a user and client. The OAuth provider should be able to find out what the userId is based on the token and grant access to protected resources or flag the token as inappropriate token.
So let's consider the access between each quadrant of players:

Client                    |    User (Vivian)
(Ravi.com)
----------------------------------------------
Provider(Proxy)     |    API (Retail.com)


I made the User directly access the API through the retail company's primary website or over the company's mobile application. Users are able to access their resources.
All calls crossing the dotted line must be with registration so that implementation knows who the caller is. The bottom parts constitute the implementation components and are things we will assume we can control and is therefore private in nature. The User and the client can be considered to be public and can be considered public. The public region is largely where security attacks originate from. This is typically launched by a malevolent user or a client. The interaction between a user and a client is one of authorization Without both of them, there is no access for the client to the protected resources in the API. For the non protected resources, the client has to get tokens from the OAuth provider. In this case the client has to register with the OAuth Provider. The retailer has no knowledge of who the client is and does not need to keep track of the client. This can be strict. Virtually all calls to the API are for some user or a guest and the API need not even bother about the clients. If the strictness were to be enforced, the retailer is looking for some kind of userId from the proxy for all client calls. Therefore if the proxy is not presenting a token that maps to a UserId, there is no access to protected resources through the proxy.
Notice that Retail.com could become a client by itself. This is a scenario we can talk about in the improvements. This does not change the fact that the APIs is the true representation of the Retail company.
When all websites including the retailer's access data through the API as a registered client, the API implementation is guaranteed that all accesses are unified in a way such that they are accessed with a token that represents both the client and the user. The retailer's website does not have to be a special client. It just needs to keep its client I'd and secret confidential just like any other web server. In practice, a .com website for a retailer presents a considerable legacy that adds no customer win for registering itself as a client and moreover poses risks during the change which the business may not allow. Furthermore, the .com website and the API provide mechanisms to compare the data between the two.



We will also talk about proxy and/or API sharing user and client mapping.
Finally, I want to list what I see as candidate improvements I can consider for OAuth
1) Token and management endpoints to be redesigned such that one provides token or code by all grant methods and another provides management functionalities
2) the management portion could be exclusively for the WebUI presented to the user for management of the client registrations. Grants and revokes of clients or new user registrations and redirects are what the WebUI provides
3) API implementation should not rely on OAuth to treat it merely as a user based access that could have otherwise been established with a single sign on web server. It was to enable richer experiences customized for different users and clients. OAuth was also not merely about using tokens and codes in place of passwords and sessions but for different clients to provide seamless sessions.
4) when the clients are fully supported  andand are treated the same as users, then we could even do away without the notion of users in the implementation.
5) resource management becomes easier with client only management and representing users as groups.

We can the think of a stack such as the following :
User
Client
Proxy
API
and eliminate the proxy with better functionalities within the API

OAuth testing discussion continued

In this post we look at performance considerations to OAuth testing. Much of this testing is targeting the OAuth provider. The authorization end points both token and management rely on the token database maintained by the OAuth provider. 

OAuth testing continued

9) landing page for user authorization
a) users must be able to see client description
b) user acceptance must result in return url with token/code
c) user denial must result in return url with error parameters in query string
d) response type, user_id, client_id, redirect_uri, scope and state parameters should be validated.
e) tokens retrieved should exist in the provider database.
10) user and client mapping
a) client access provisioned on a user by user basis, otherwise only client credential provisioning possible
b) check against cross user profile access via common clients
c) check against admin access clients
d) check correctness of user list maintained by client
e) check correctness of clients authorized by user
11) resource management policies enforcement
a) provision minimal scope authorization and check for external access
b) check against all scope parameters or access range.
c) specify full access range and bearer token to see if different if card balances can be read.
d) set the state and callbacks to see if scope changes
e) check which apis or methods are to be protected with access tokens and if they are all enforced.
f) check mashery or OAuth providers api for token to user or client mapping
12) security validations
a) check for phishing attacks
b) check the http headers for leak of securables
c) check that TLS is required for all APIs
d) check that the server authentication by way of certficates is provisioned.
e) check that client ids and secrets are not leaked
f) check that cross site forgery attacks can be thwarted by callbacks and state.

oauth testing continued

Let's close on the OAuth test matrix here:

1) Implicit Grant

a. missing user id

b. missing client id

c. any user id but Valid client id 

d. Valid user id and client id

e. Valid user id but invalid client id

f. Error codes – 400, 403, 404, invalid_request, invalid_token and insufficient_scope

g. Use invalid uri to not get 302 (new)

h. Performance (new)

i. XML and JSON responses

2) Authorization Code Grant

a. Similar to Implicit grant but responseType=code so 1a to 1i will be repeated. (new)

b. Code will be translated to token.

c. Code expiry will not be tested but code revoke will be tested to validate token

3) Client credentials grant

a. Targets token endpoint to get token using client id, client secret, scope (new)

b. Checks for error message for  invalid grant (new)

4) Revoke access

a. Revoke token will be tested but not revoke client

b. Revoke an already revoked token

c. Revoke an already revoked client (new)

d. Revoke all tokens for a client ( Get all tokens and validate each) (new)
5) Claim information
a) Get claims based on default scope (null)
b) Get claims based on specific scope (not null)
6) Client Information
a) Get name of client application and check access tokens
b) Get client without name, description or image to see the default rendered to the user
c) Get all access tokens and add or remove tokens to see if the client information is updated
d) Check if revoke all removes all access tokens.
7) Get allowed clients for a user
a) Check if all the clients are listed for the user.
b) Add or remove a client to see the corresponding update to the list
c) Authorize a client for the user but delete the client to check for orphaned entries
8) Check response types
a) check the code
b) check the token

In the previous post we looked at some OAuth security considerations. In this post we review the IANA considerations from RFC.
First, the token types have to be registered with the OAuth external review mailing list.
Examples could be included with the registration request. Registry updates must only be done by designated experts.
Registration templates include type name, authentication scheme, change controller and specification document.
Initial registry contents include

• client_id, 
• client_secret, 
• response_type, 
• redirect_uri, 
• scope, 
• state,
• code,
• error_description,
• error_uri,
• grant_type,
• access_token,
• token_type,
• expires_in,
• username,
• password
• refresh_token

Response types are also registered. Again these include response type name, change controller and specification document

OAuth testing should cover these registrations. For example, tests should cover the different response types and token types.

OAuth testing requires clients and users mapping to be tested. In addition, resource management policies should be tested. For example, resource management testing should include test that the public clients should don't have access to the user profiles. Similarly user profiles based access should have access to the non-user-profile specific information.

A specially designated admin client is useful for offloading the troubleshooting to non-development. teams. however, that may be for internal use and should ideally be built without modifying the existing protocol implementation.

OAuth security considerations from RFC continued.
1) resource owner password credentials - this is probably the one that grants maximum access to the client. However client and authorization server should limit the scope. This method in general is different from the pattern that this RFC proposes and is used for backward compatibility. The vulnerability here is that the resource owner does not have control over how the credentials are used.
2) tokens, codes, passwords, and secrets should not be transmitted in the clear. Http headers, URI appear as clear text. State and scope could appear in the clear so they should not ave any sensitive  information.
3) ensure endpoint authenticity by requesting TLS with server authentication. TLS certificates must be validated
4) tokens, passwords etc should not be guessable. Their probability should be fewer than one in 2^128
5) due to the use of redirects there could be phishing attacks possible. Websites that ask for credentials should be authenticated.
6) Cross site request forgery should be prevented such as when  a  user-agent is made to follow a malicious URI to a trusting server.  In such security attacks, the attacker injects his own authorization code. CSRF protection is achieved by including a value in the URI that hints at the authenticated state.