On Wed, 21 Aug 2019 at 1:21 pm, Asela Pathberiya <[email protected]> wrote:
> > > On Tue, Aug 20, 2019 at 2:37 PM Nuwan Dias <[email protected]> wrote: > >> Hi, >> >> With the introduction of the Microgateway self-contained access tokens >> were supported in the API Manager since version 2.5. Self-contained access >> tokens however were only supported in the Microgateway so far. The regular >> gateway was unable to process and validate a self-contained access token. >> With API Manager 3.0 we are bringing this support to the regular gateway as >> well. With this we hope to make self-contained tokens the default token >> type of applications. Opaque tokens will still be supported as before. >> There are several benefits of using self-contained access tokens. These are, >> >> 1) The gateway no longer connects to the Key Manager when processing API >> requests. This makes the deployment simpler and reduces configuration >> points a bit. >> 2) We no longer have to scale the Key Manager when we need the Gateway to >> be scaled. This bring a significant reduction to the cost of using the >> product in larger deployments. >> 3) The gateway becomes regionally resilient. A token issued from one >> region can be validated by a gateway in another region even if the data is >> not synced. >> 4) Back-end JWTs will be included in as part of the access token itself >> (self-contained). This eliminates the need of creating back-end JWTs while >> the API request is being processed. Which in turn makes APIs calls much >> faster. >> >> One pending items that's left to handle is the revocation of >> self-contained access tokens. Since the gateway does not connect to the Key >> Manager for validating self-contained tokens, the gateway will not know >> when a particular token has been revoked. Using shorter expiry times for >> access token addresses this solution to a certain extent. We hope to >> implement the same solution we implemented for the Microgateway to address >> this. The Key Manager will be notifying the gateway cluster through a >> broker when a token has been revoked. And the gateway will no longer be >> treating the particular token as valid upon receiving the notification. >> >> Appreciate your thoughts and suggestions on this. >> > > So we are making it as default to increase the usage of it ? > Well, the objective is to make the gateway more independent, easily scalable and regionally resilient. > > Is this would be same for developer token in store (application tokens)? > Yes. What are the default user details which are adding to self-contains access > token ? > Same as the opaque token. Whoever authenticates to the system using the grant type. In case of the store developer token it will be the app owner. > > Thanks, > Asela. > > >> >> Thanks, >> NuwanD. >> -- >> *Nuwan Dias* | Director | WSO2 Inc. >> (m) +94 777 775 729 | (e) [email protected] >> [image: Signature.jpg] >> _______________________________________________ >> Architecture mailing list >> [email protected] >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > >> > > -- > Thanks & Regards, > Asela > > Mobile : +94 777 625 933 > > http://soasecurity.org/ > http://xacmlinfo.org/ > _______________________________________________ > Architecture mailing list > [email protected] > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > -- *Nuwan Dias* | Director | WSO2 Inc. (m) +94 777 775 729 | (e) [email protected] [image: Signature.jpg]
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
