Pega web embed and use of third party cookies
I am searching for documentation around pega web embed and use of cookies but not able to find any concrete answers to this. the question i have is will pega web embed set a third party cookie or not ?
as we all know third party cookies are going away, and if pega web embed is using cookies it will be a problem when third party cookies are no longer supported by browsers.
reviewed few articles but can not find concrete answer.
https://support.pega.com/question/web-embed-tags-third-party-cookie-issue-pega-mashup
https://developer.chrome.com/en/docs/privacy-sandbox/third-party-cookie-phase-out/
any insight into this will be a great help, Thanks in advance
Accepted Solution
Updated: 15 Sep 2023 15:40 EDT
Pegasystems Inc.
US
Web-Embed still requires the use of cookie for the authorization code redirect implementation because the Pega Infinity Authorize Grant flow is reliant on the Pega-RULES cookie. Similarly to Pega Web Mashup, if your web-embed is on a different domain than your main document site, you will need to use a proxy server to proxy these transactions to the Infinity server in case the browser is blocking 3rd party cookies.
To avoid the Pega-RULES cookies, you can use the authHeader attribute and always pass in the credentials (with grantType='none'). There is also a grantType='customBearer' configuration with Infinity '23 which leaves authentication fully up to the implementor using Pega custom authentication techniques.
https://docs.pega.com/bundle/platform/page/platform/user-experience/web-embedding-constellation.html
New Pega Infinity '23 capability:
- New attributes: assignmentHeader, grantType, autoReauth
- New methods: login, setCustomTokenCB
- Existing casePage attribute extended to pass thru additional values as a view name to use for desired casePage view
- authHeader setting (for grantType 'none'; and updateTokens method when using OAuth) also now automatically retry any recently failed 401 transactions (very smooth user experience when a full re-auth is required)
Updated: 19 Sep 2023 8:54 EDT
Pegasystems Inc.
US
Also, with Web Embed the authorize transaction being negatively impacted due to cookie blocks will be of concern when the default "authCode" grantType is utilized and also only during the "silent authentication" phase of authentication.
"silent authentication" phase comes into play when either the userIdentifier and password attributes are specified (with authService set to 'pega') or when the authService is set to some other value (using an external identity provider [also note that with external identity providers the userIdentifier and password attributes are never heeded]). "silent authentication" can also be disabled by explicitly setting "silentTimeout" attribute to "0".
Also, with Web Embed the authorize transaction being negatively impacted due to cookie blocks will be of concern when the default "authCode" grantType is utilized and also only during the "silent authentication" phase of authentication.
"silent authentication" phase comes into play when either the userIdentifier and password attributes are specified (with authService set to 'pega') or when the authService is set to some other value (using an external identity provider [also note that with external identity providers the userIdentifier and password attributes are never heeded]). "silent authentication" can also be disabled by explicitly setting "silentTimeout" attribute to "0".
In this scenario where "silent authentication" fails (or is disabled), Web Embed would then revert to use "popup authentication" which would then attempt to open a window explicitly to the Pega server url...so the authorize would then succeed as Pega-RULES would not be a 3rd party cookie in that scenario. Also, if configured to an external identity provider, the window would also redirect to the external identity provider, and any IDP cookies also would not be considered 3rd party cookies in that scenario and so would not be blocked. This may result in a window opening and then closing (going away) rapidly as the SSO succeeded without needing to display any login challenge user experience. (Note: the "popup authentication" phase would be disabled by specifying "iframeLoginUI" attribute with a value of 'true' or by specifying a 'noPopups' attribute with a value of 'true')
Vinod Seraphin | Web Embed Development