The OAuth implementations need not provide both password and implicit grant methods on the same endpoint. Hence there can be more than one endpoints available to the user agent. In this discussion we will use the following definitions:
User : this is the resource owner. She should have access to her profile via the APIs
User Agent : this is the browser. The mobile phone or an iPhone App can be a user agent as well.
Client : this is the application registered with Mashery. It can make service requests on behalf of the user.
Service: A service is the resource provider and holds all data.
Authorization server: this issues tokens
Note authentication and authorization are two separate parts of the login process. Authentication is assumed to be taken care of by web site using username and password such as in the case of starbucks.com with starbucks.com username and password. If the Starbucks application is official and branded, it has no problems taking the username and password from the user and together with its client id, retrieving a token from the authorization endpoint.
However implicit is required for unofficial developer applications because a user may not be comfortable providing his/her username or password to third party iPhone applications. Here the client inside the user agent will need to redirect the user to the login website along with the client id. The authentication website will redirect back to the user agent with the token so the user agent is only aware of the token and can make use of this token to make subsequent API calls.
We need this website that can accept requests from different clients and enables the user to grant access to these clients. Note that the website needs to be hosted by Starbucks.User Id may not be retrieved and certainly not passed to the client or user agent. The tokens last for 3600 seconds so they can be used across calls. However the token needs to be retrieved with the user context and the client context by the web site.
UserId translation is not required anywhere unless the implicit needs to be supported. In which case, they could be available off the request header. Note that Implicit is not a token provider because it would require userId or the alias me which is not supported by authorization endpoints because there is no way to tie the userId to the sender sending the userId even if the senders are all authenticated. This is the hurdle that needs to be overcome for implicit to work per the specification. The specification does not bar userId based token retrieval however implementations have to secure a lot more in order to fully implement implicit. This doesn't mean it cannot be done, just that there is a lot of difference between a password and a user Id. Besides a userId can be treated as internal to the system. In such cases implicit is never available to a mobile application. A mobile application has a well known route to send its client id over to the authentication website and expect a token back to facilitate further calls on behalf of the user.
User : this is the resource owner. She should have access to her profile via the APIs
User Agent : this is the browser. The mobile phone or an iPhone App can be a user agent as well.
Client : this is the application registered with Mashery. It can make service requests on behalf of the user.
Service: A service is the resource provider and holds all data.
Authorization server: this issues tokens
Note authentication and authorization are two separate parts of the login process. Authentication is assumed to be taken care of by web site using username and password such as in the case of starbucks.com with starbucks.com username and password. If the Starbucks application is official and branded, it has no problems taking the username and password from the user and together with its client id, retrieving a token from the authorization endpoint.
However implicit is required for unofficial developer applications because a user may not be comfortable providing his/her username or password to third party iPhone applications. Here the client inside the user agent will need to redirect the user to the login website along with the client id. The authentication website will redirect back to the user agent with the token so the user agent is only aware of the token and can make use of this token to make subsequent API calls.
We need this website that can accept requests from different clients and enables the user to grant access to these clients. Note that the website needs to be hosted by Starbucks.User Id may not be retrieved and certainly not passed to the client or user agent. The tokens last for 3600 seconds so they can be used across calls. However the token needs to be retrieved with the user context and the client context by the web site.
UserId translation is not required anywhere unless the implicit needs to be supported. In which case, they could be available off the request header. Note that Implicit is not a token provider because it would require userId or the alias me which is not supported by authorization endpoints because there is no way to tie the userId to the sender sending the userId even if the senders are all authenticated. This is the hurdle that needs to be overcome for implicit to work per the specification. The specification does not bar userId based token retrieval however implementations have to secure a lot more in order to fully implement implicit. This doesn't mean it cannot be done, just that there is a lot of difference between a password and a user Id. Besides a userId can be treated as internal to the system. In such cases implicit is never available to a mobile application. A mobile application has a well known route to send its client id over to the authentication website and expect a token back to facilitate further calls on behalf of the user.
No comments:
Post a Comment