Hi Lakmali,
Since we supposed to use password grant type for generating the tokens, why do we need to skip validation? Because it's an additional task to check whether the API invocation happens through API Store or in any other ways. Also, if we are using a special scope to the token for skipping subscription validation, won't the user identify this special scope and use it when they invoke the API with real scenarios? In my opinion, this an additional burden. On Thu, Mar 23, 2017 at 9:06 AM, Sumedha Rubasinghe <[email protected]> wrote: > > > On Thu, Mar 23, 2017 at 8:28 AM, Lakmali Baminiwatta <[email protected]> > wrote: > >> Hi all, >> >> Prior to C5, we were generating an access token per app created in the >> store using the client_credentials grant type and it was displayed to be >> used as the test tokens. The same was used in the API Console as well. Due >> to below reasons we are going to generate a token against the OAuth app >> registered for the UUF app and make it available as the test token. >> >> - Ideally the UI application (ex: store) is the real application >> which does the test API calls. >> - People get it confused with the application tokens we provide in >> the store and use those in the real use cases. >> - Make it possible to do a test API call without subscribing. >> - Provide Swagger API Console in Publisher as well. >> >> The proposed solution is to generate an access token with the UUF app's >> credentials + special scope. The subscription validation will be skipped >> for the tokens in this special scope. >> > > Why skip subscription check? If UI app's capabilities are properly mapped > to API resources with correct scopes, it's ok to treat this as a normal > application subscribing to bunch of product APIs. > > > > > >> For implementing the solution, we have to consider below points. >> >> >> - Grant Type - If the client_credentials grant type is used, all the >> concurrent users accessing the UI app will get the same token. >> >> > I think you should also get device id/brower id into this combination as > well. A given user can maintain multiple sessions from different > devices/browers concurrently. (eg: for statistics dashboards) > > > >> >> - In order to do any user level restrictions for this token in the >> gateway level, we have to use password grant type. One case is visibility >> restricted API invocations. Also I guess we shouldn't allow to invoke API >> resources protected with scopes if the logged in user is not allowed for >> that. >> >> >> - Scope white listing - This scope has to be white listed, since the >> API resource is not actually protected with it. >> >> >> - Throttling - Since there is no API subscription, special throttle >> limit has to be applied with some minimum quota. One option is to apply >> the >> unauthenticated tier limits which does a throttling based on the client >> IP. >> >> >> - Token validity and refresh token - If the client_credential grant >> type is used, we can't invalidate this test token when a user is logged >> out >> since other users might be using it already. Therefore IMO, we can use >> password grant type and use the similar token refreshing mechanism done >> for >> UUF app authentication. >> >> >> - Obtaining the access token - In order to get an access token, we >> need the consumer key and secret of the UUF app. Currently we do a UUF >> backend app call only when the user is authenticating or when refreshing >> the token. So here also, I think we can generate the test token when the >> user is authenticated(log in to the UUF app) and store it in the local >> storage. I believe its okay to display this access token for the user. >> >> Thoughts? >> >> Thanks, >> Lakmali >> >> >> -- >> Lakmali Baminiwatta >> Associate Technical Lead >> WSO2, Inc.: http://wso2.com >> lean.enterprise.middleware >> mobile: +94 71 2335936 >> blog : lakmali.com >> >> >> _______________________________________________ >> Architecture mailing list >> [email protected] >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >> >> > > > -- > /sumedha > m: +94 773017743 <+94%2077%20301%207743> > b : bit.ly/sumedha > > _______________________________________________ > Architecture mailing list > [email protected] > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- Thanks Abimaran Kugathasan Senior Software Engineer - API Technologies Email : [email protected] Mobile : +94 773922820 <http://stackoverflow.com/users/515034> <http://lk.linkedin.com/in/abimaran> <http://www.lkabimaran.blogspot.com/> <https://github.com/abimarank> <https://twitter.com/abimaran>
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
