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
b :  bit.ly/sumedha
_______________________________________________
Architecture mailing list
[email protected]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Reply via email to