The PGP SSO (Single Sign-On) GET method is deprecated and will stop working on July 1, 2021.
What PGP SSO is
The PGP SSO implementation is a custom proprietary implementation provided by GoodData (see GoodData PGP Single Sign-On). This implementation is based on the PGP keypair exchange. It allows your application to sign in an existing GoodData user. The authentication is done not by username and password but by generating a session-specific token using a pair of PGP keys.
Depending on your current situation and use case, the GoodData PGP SSO is sometimes easier to implement than SAML SSO.
Why we deprecated this feature
- HTTP GET requests should never be used when dealing with sensitive data (see HTTP Request Methods). Sensitive information within URLs may be logged in various locations, including the user's browser, the web server, and any forward or reverse proxy servers between the two endpoints (see CWE-598: Information Exposure Through Query Strings in GET Request). URLs may also be displayed on-screen, bookmarked or emailed around by users. They may be disclosed to third parties via the Referer header when any off-site links are followed. Placing session tokens into the URL increases the risk that they will be captured by an adversary (see CWE-200: Information Exposure). For more information, also see OWASP: Information exposure through query strings in URL.
- In HTTP, only POST should change the state (see Quick Checklist for Choosing HTTP GET or POST). Because we do not protect GET requests against CSRF attacks (see Cross-Site Request Forgery (CSRF)), this function is vulnerable and potentially abusable in some scenarios (for example, an attacker with leaked credentials or leaked sessionId (see the previous point in this section) could share a link to forcibly-navigate other users to access the apps/data amplifying the information leak impact.)
- Similarly to CSRF, with a valid token, a GET request can also be abused as an open redirect (see Unvalidated Redirects and Forwards Cheat Sheet). This is not dangerous by itself due to valid token limitation, but could be a part of a more complex attack.
Are you affected?
You are affected if you have the GoodData PGP SSO (see GoodData PGP Single Sign-On) implemented for authentication to the GoodData platform and use it by calling the API via the GET method.
Before July 1, 2021, make sure that you are using the POST method in your current PGP SSO login implementation. If you are using the GET method, switch to the POST method. See GoodData PGP Single Sign-On for additional information.
What will happen if you do not switch to the POST method
You will face the risk of losing access to the GoodData platform because it might be forged by attackers (see Why we deprecated this feature). Once the end-of-life date is reached, any implementation using the GET method will stop working.
If you have questions, contact GoodData Support.