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.
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.
No comments:
Post a Comment