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
