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