In the previous posts we discussed that OAuth testing depends on the nature of the token. The token is granted to a client for access to a user's resources. Therefore, OAuth APIs are largely qualified by user first and then client. So APIs are resource qualified in the form '/v1/users/me/clients/clientId'. The reverse order of '/v1/clients' is generally not needed to be maintained because the clients don't have any access unless a user authorizes a resource.
That said, it is important to consider admin access such as one that can reach across users. Is it necessary to have admin access ? or should users manage their own client authorizations ? This is the topic we will briefly consider.
Resources that are not user-specific are generally less demanding on security as opposed to resources that are user owned. For example, the reward cards and balances on them that a user has is considered confidential and so no other user should have access to the same. However, what if there is governance required such as when the law enforcement agencies want to know how may coffee drinks you need to have before you get your free one ? Or even more pertinent where was your last purchase store in case you died ? Governance has a notorious connotation to big brother snooping but in our technical discussion here we refrain from such discussion and consider the case where it is important for another user or system to know information of other users. This could be as benign as friends sharing card information to see which card needs to be used first for the free drink. In OAuth spec, there is no limitation against admin access or access to other users information. In OAuth there is no mention for grouping users or clients. In OAuth there is no mention for API aliasing or shortening or parameter abbreviation for ease of use by one or more users especially from handheld devices. This is left to individual vendors to determine.
In the case where vendors choose to have cross user access or admin client access, the nature of the token granted is relevant. This could be scoped to include certain information such as last store while excluding certain information as credit cards or social security number. Basically, the protocol does not and should not prevent granularity of access and accessors be it the client or the user.
This definitely calls for OAuth tests so that security, functionality and performance are not affected. The RFC discusses several security implications from the user and client point of view however testing may need to be customized to the implementation. The implementation can be as simple as requiring all authorizations owned and delegated to the end user.
That said, it is important to consider admin access such as one that can reach across users. Is it necessary to have admin access ? or should users manage their own client authorizations ? This is the topic we will briefly consider.
Resources that are not user-specific are generally less demanding on security as opposed to resources that are user owned. For example, the reward cards and balances on them that a user has is considered confidential and so no other user should have access to the same. However, what if there is governance required such as when the law enforcement agencies want to know how may coffee drinks you need to have before you get your free one ? Or even more pertinent where was your last purchase store in case you died ? Governance has a notorious connotation to big brother snooping but in our technical discussion here we refrain from such discussion and consider the case where it is important for another user or system to know information of other users. This could be as benign as friends sharing card information to see which card needs to be used first for the free drink. In OAuth spec, there is no limitation against admin access or access to other users information. In OAuth there is no mention for grouping users or clients. In OAuth there is no mention for API aliasing or shortening or parameter abbreviation for ease of use by one or more users especially from handheld devices. This is left to individual vendors to determine.
In the case where vendors choose to have cross user access or admin client access, the nature of the token granted is relevant. This could be scoped to include certain information such as last store while excluding certain information as credit cards or social security number. Basically, the protocol does not and should not prevent granularity of access and accessors be it the client or the user.
This definitely calls for OAuth tests so that security, functionality and performance are not affected. The RFC discusses several security implications from the user and client point of view however testing may need to be customized to the implementation. The implementation can be as simple as requiring all authorizations owned and delegated to the end user.
No comments:
Post a Comment