Re: [Architecture] Making self-contained access tokens the default in APIM 3.0
Hi Sharma, You could now get the latest API Manager (v3.0.0) from here[1] which has this feature. [1] https://wso2.com/api-management/ Regards, Chamila. On Mon, Sep 23, 2019 at 2:28 PM Ashish Sharma wrote: > Hi Nuwan > > Could you please advise when is the first release (PROD ready) of the API > Manager with support for JWTs foreseen? > > Met vriendelijke groeten, > > Ashish Sharma > > > -- > *From:* Architecture on behalf of Nuwan > Dias > *Sent:* Tuesday, August 20, 2019 10:52 AM > *To:* architecture > *Subject:* [Architecture] Making self-contained access tokens the default > in APIM 3.0 > > 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. > > Thanks, > NuwanD. > -- > *Nuwan Dias* | Director | WSO2 Inc. > (m) +94 777 775 729 | (e) nuw...@wso2.com > [image: Signature.jpg] > ___ > Architecture mailing list > Architecture@wso2.org > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > -- Regards, Chamila Adhikarinayake Associate Technical Lead WSO2, Inc. Mobile - +94712346437 Email - chami...@wso2.com Blog - http://helpfromadhi.blogspot.com/ ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] Making self-contained access tokens the default in APIM 3.0
Hi Nuwan Could you please advise when is the first release (PROD ready) of the API Manager with support for JWTs foreseen? Met vriendelijke groeten, Ashish Sharma From: Architecture on behalf of Nuwan Dias Sent: Tuesday, August 20, 2019 10:52 AM To: architecture Subject: [Architecture] Making self-contained access tokens the default in APIM 3.0 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. Thanks, NuwanD. -- Nuwan Dias | Director | WSO2 Inc. (m) +94 777 775 729 | (e) nuw...@wso2.com<mailto:nuw...@wso2.com> [Signature.jpg] ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] Making self-contained access tokens the default in APIM 3.0
Can we expect APIM 3.0.0 milestone to be released with the token revocation feature? That's where some key business end-users relying on business functions when and if they decided to migrate. I know you have mentioned that Opaque tokens will still be supported as before, but I felt the user story through self-signed not yet 100% we can't find sustainable option so, IMHO ideally, 3.0.0 with the primary feature as Opaque but self-signed availability with optional WDYT? and once we finalize fully feature compatible self-signed token, we will switch to the default mode when that ready. On Sun, Aug 25, 2019 at 5:00 PM Ishara Cooray wrote: > Hi, > > 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. > > Only concern, this might lead the header to become very large. > In that case we will have to increase the header size. > Alternatively, HPACK[1] in http/2 (Header Compression for HTTP2) might be > useful. > > > [1] https://httpwg.org/specs/rfc7541.html > > Thanks & Regards, > Ishara Cooray > Associate Technical Lead > Mobile : +9477 262 9512 > WSO2, Inc. | http://wso2.com/ > Lean . Enterprise . Middleware > > > On Thu, Aug 22, 2019 at 11:04 AM Nuwan Dias wrote: > >> >> >> On Wed, 21 Aug 2019 at 10:57 pm, Manjula Rathnayake >> wrote: >> >>> Hi Nuwan, >>> >>> Can the same API gateway handle both self-contained and opaque tokens? >>> >> >> Yes it can. The gateway needs to be connected to the key manager if it is >> expected to validate opaque tokens. >> >>> >>> How does the API consumption work? Does the application need to invoke >>> both the KM and gateway endpoints to refresh/revoke and invoke the APIs? >>> >> >> If the gateway is connected to the key manager the app can use the /token >> and /revoke endpoints on the gateway itself. Otherwise the key manager >> needs to be expose them some other way for apps to use. >> >>> >>> Thank you. >>> >>> On Wed, Aug 21, 2019 at 1:21 PM Asela Pathberiya wrote: >>> On Tue, Aug 20, 2019 at 2:37 PM Nuwan Dias 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 ? Is this would be same for developer token in store (application tokens)? What are the default user details which are adding to self-contains access token ? Thanks, Asela. > > Thanks, > NuwanD. > -- > *Nuwan Dias* | Director | WSO2 Inc. > (m) +94 777 775 729 | (e) nuw...@wso2.com > [image: Signature.jpg] > ___ > Architecture mailing list >
Re: [Architecture] Making self-contained access tokens the default in APIM 3.0
Hi, 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. Only concern, this might lead the header to become very large. In that case we will have to increase the header size. Alternatively, HPACK[1] in http/2 (Header Compression for HTTP2) might be useful. [1] https://httpwg.org/specs/rfc7541.html Thanks & Regards, Ishara Cooray Associate Technical Lead Mobile : +9477 262 9512 WSO2, Inc. | http://wso2.com/ Lean . Enterprise . Middleware On Thu, Aug 22, 2019 at 11:04 AM Nuwan Dias wrote: > > > On Wed, 21 Aug 2019 at 10:57 pm, Manjula Rathnayake > wrote: > >> Hi Nuwan, >> >> Can the same API gateway handle both self-contained and opaque tokens? >> > > Yes it can. The gateway needs to be connected to the key manager if it is > expected to validate opaque tokens. > >> >> How does the API consumption work? Does the application need to invoke >> both the KM and gateway endpoints to refresh/revoke and invoke the APIs? >> > > If the gateway is connected to the key manager the app can use the /token > and /revoke endpoints on the gateway itself. Otherwise the key manager > needs to be expose them some other way for apps to use. > >> >> Thank you. >> >> On Wed, Aug 21, 2019 at 1:21 PM Asela Pathberiya wrote: >> >>> >>> >>> On Tue, Aug 20, 2019 at 2:37 PM Nuwan Dias 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 ? >>> >>> Is this would be same for developer token in store (application tokens)? >>> What are the default user details which are adding to self-contains >>> access token ? >>> >>> Thanks, >>> Asela. >>> >>> Thanks, NuwanD. -- *Nuwan Dias* | Director | WSO2 Inc. (m) +94 777 775 729 | (e) nuw...@wso2.com [image: Signature.jpg] ___ Architecture mailing list Architecture@wso2.org 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 >>> Architecture@wso2.org >>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>> >> >> >> -- >> *Manjula Rathnayaka* | Senior Technical Lead | WSO2 Inc. >> (m) +94 77 743 1987 | (w) +94 11 214 5345 | (e) manju...@wso2.com >> GET INTEGRATION AGILE >> Integration Agility for Digitally Driven Business >> ___ >> Architecture mailing list >> Architecture@wso2.org >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >> > -- > *Nuwan
Re: [Architecture] Making self-contained access tokens the default in APIM 3.0
On Wed, 21 Aug 2019 at 10:57 pm, Manjula Rathnayake wrote: > Hi Nuwan, > > Can the same API gateway handle both self-contained and opaque tokens? > Yes it can. The gateway needs to be connected to the key manager if it is expected to validate opaque tokens. > > How does the API consumption work? Does the application need to invoke > both the KM and gateway endpoints to refresh/revoke and invoke the APIs? > If the gateway is connected to the key manager the app can use the /token and /revoke endpoints on the gateway itself. Otherwise the key manager needs to be expose them some other way for apps to use. > > Thank you. > > On Wed, Aug 21, 2019 at 1:21 PM Asela Pathberiya wrote: > >> >> >> On Tue, Aug 20, 2019 at 2:37 PM Nuwan Dias 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 ? >> >> Is this would be same for developer token in store (application tokens)? >> What are the default user details which are adding to self-contains >> access token ? >> >> Thanks, >> Asela. >> >> >>> >>> Thanks, >>> NuwanD. >>> -- >>> *Nuwan Dias* | Director | WSO2 Inc. >>> (m) +94 777 775 729 | (e) nuw...@wso2.com >>> [image: Signature.jpg] >>> ___ >>> Architecture mailing list >>> Architecture@wso2.org >>> 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 >> Architecture@wso2.org >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >> > > > -- > *Manjula Rathnayaka* | Senior Technical Lead | WSO2 Inc. > (m) +94 77 743 1987 | (w) +94 11 214 5345 | (e) manju...@wso2.com > GET INTEGRATION AGILE > Integration Agility for Digitally Driven Business > ___ > Architecture mailing list > Architecture@wso2.org > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > -- *Nuwan Dias* | Director | WSO2 Inc. (m) +94 777 775 729 | (e) nuw...@wso2.com [image: Signature.jpg] ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] Making self-contained access tokens the default in APIM 3.0
On Wed, 21 Aug 2019 at 1:21 pm, Asela Pathberiya wrote: > > > On Tue, Aug 20, 2019 at 2:37 PM Nuwan Dias 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) nuw...@wso2.com >> [image: Signature.jpg] >> ___ >> Architecture mailing list >> Architecture@wso2.org >> 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 > Architecture@wso2.org > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > -- *Nuwan Dias* | Director | WSO2 Inc. (m) +94 777 775 729 | (e) nuw...@wso2.com [image: Signature.jpg] ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] Making self-contained access tokens the default in APIM 3.0
Hi Nuwan, Can the same API gateway handle both self-contained and opaque tokens? How does the API consumption work? Does the application need to invoke both the KM and gateway endpoints to refresh/revoke and invoke the APIs? Thank you. On Wed, Aug 21, 2019 at 1:21 PM Asela Pathberiya wrote: > > > On Tue, Aug 20, 2019 at 2:37 PM Nuwan Dias 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 ? > > Is this would be same for developer token in store (application tokens)? > What are the default user details which are adding to self-contains access > token ? > > Thanks, > Asela. > > >> >> Thanks, >> NuwanD. >> -- >> *Nuwan Dias* | Director | WSO2 Inc. >> (m) +94 777 775 729 | (e) nuw...@wso2.com >> [image: Signature.jpg] >> ___ >> Architecture mailing list >> Architecture@wso2.org >> 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 > Architecture@wso2.org > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > -- *Manjula Rathnayaka* | Senior Technical Lead | WSO2 Inc. (m) +94 77 743 1987 | (w) +94 11 214 5345 | (e) manju...@wso2.com GET INTEGRATION AGILE Integration Agility for Digitally Driven Business ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] Making self-contained access tokens the default in APIM 3.0
On Tue, Aug 20, 2019 at 2:37 PM Nuwan Dias 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 ? Is this would be same for developer token in store (application tokens)? What are the default user details which are adding to self-contains access token ? Thanks, Asela. > > Thanks, > NuwanD. > -- > *Nuwan Dias* | Director | WSO2 Inc. > (m) +94 777 775 729 | (e) nuw...@wso2.com > [image: Signature.jpg] > ___ > Architecture mailing list > Architecture@wso2.org > 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 Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
