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.

URL shortening for REST API

REST APIs are easy to document. And their use often involves small variations in the URI. Therefore , URI shortening and parameter abbreviation helps particularly on mobile devices.  The difference between a regular URL shortening and this kind of smaller URI's is that these will not necessarily be a hash. The URI's can have meaningful abbreviations given that we could  control which API's they map to  and because the APIs are limited. The shortened URI' s could  be stored in a database and the URI's they map to could  still be available independently. This means that we can develop the MVC route based API's as usual and have this service as an add on. The service merely redirects to the actual API"s as HTTP 302 and not require any static or dynamic pages assigned to the short URIs. This service could even live in the http proxy, if the API uses one. The proxy can be transparent on this redirection.
API documentation has to be kept in sync with this short URI mapping. Documentation can be generated from the config routes in which case the short APIs may need their own listing and correspond API documentation redirects. if the framework were to allow such short URI services, then thereis no need for an external service or database and short URi's  could be provisioned in the config files itself. This will also help keep the documentation together.
Query string or Request body parameter abbreviation requires changes on the API implementation. Parameters need not be specified with their full names but by their first initial or some shortener convention.  Only the parameter lookup changes so they can be kept in sync with their corresponding actual parameters. Together with abbreviations, short URI and documentation provide compelling convenience. Statistics could be gathered for both short and regular URI's to warrant continued usage.

This is  a quick overview of the OAuth RFC 6749 and will cover some salient features mentioned there.
Implicit workflow is described as follows:
The client is issued an access token directly instead of the authorization code. This is done on the basis of resource owner authorization The client is issued an access token. Client is not verified.  The access token is sent back in the uri fragment. Unauthorized parties could gain access to it. In some cases client can be verified with the redirect uri. Access tokens are issued with the minimal scope.  Phishing attacks are possible where the access token can be switched with the another token previously issued to the attacker. Due to such security considerations, when authorization code grant is available, implicit might not be provisioned.
Other security scenarios include the following:
1) A malicious client can impersonate another client and obtain access to protected resources. This can be avoided with the registration of redirect uri and receiving authorization responses. The authentication server must authenticate the client whenever possible.
2) Access tokens must be kept confidential in transit and storage. TLS can be used for transit and database could be encrypted.
3) Authorization servers may issue refresh tokens to both web application and native application clients. Refresh tokens must be issued only to the client who was previously issued the token. The authorization server could also use refresh token rotation where the clients who used the previous token can be identifed.
4) Authorization codes must be short lived since it is used for the exchange of a token.
5) The redirect_uri parameter can be manipulated.

In the previous post, there was a mention for cross user access or admin access, however in this post we talk about infrastructure support for mobile devices. One of the things we discussed was expiration of access. With mobile devices and other applications, there can be convenience provided to the user such that her login efforts are minimized. For example the authorization website where the user login to grant access to a client, may choose to remain signed in for the duration of a session that is longer the token expiry time.  Clients in expiry of their tokens need not request the user to login again. That can be maintained by the site. Further the user may grant indefinite time access or until explicit revoke at the website such that the client could continue to have the web site send redirects. Strictly speaking this is not OAuth. It's just a convenience provisioned outside the OAuth.