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? > > 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
