Hi Prasanna, On 23 March 2017 at 08:53, Prasanna Dangalla <[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. 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. 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? >> > > Hi Lakmali, > > In this approach how are we going to restrict the users using this testing > access token in API console and in real use cases. Let say a user is logged > in and using this access token. At that time, would they be able to use it > from API console? > Actually we don't have any explicit restriction. Only thing is this token will have a limited quota. Thanks, Lakmali > > >> Thanks, >> Lakmali >> >> >> -- >> Lakmali Baminiwatta >> Associate Technical Lead >> WSO2, Inc.: http://wso2.com >> lean.enterprise.middleware >> mobile: +94 71 2335936 >> blog : lakmali.com >> >> > -- 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
