Prestashop is an online store building system that allows users to build their own eCommerce platforms for creating and selling their own products. It comes built-in with several features called modules which include easy checkout and payment system integrated with PayPalTM, Facebook, and social network integrations for building your community around your store, and administration for simplifying the daily management of your store.

PingIdentity is a global identity and access management provider which enables various software to handle and manage user authentication & user authorization. It leverages the usage of popular authentication & authorization protocols like SAML 2.0 and OAuth 2.0 which securely facilitates single sign-on (SSO) between two compliant entities. PingIdentity can also be used to build several other identity platforms for various enterprise groups such as employee management, health management for employees, etc. By facilitating SSO using one of its SSO protocols, it enables cross access between itself and applications built on it with other third-party applications/websites.

Scenario

You have an employee portal that is built on PingIdentity and a Prestashop store which the employees can access after successful authorization from the employee management portal. To facilitate this authorization process, you want the employees to SSO into Prestashop using the OAuth protocol. However, by default, the authorization code grant flow allows the users client secret to be visibly sent in the request URL. So to incorporate a more secure way of doing this, you want the SSO to work using the authorization code grant PKCE (Proof Key for Code Exchange) flow instead, which prevents the client secret from being sent in the request URL.

Requirements

PingIdentity is used to build the employee portal where all the employee credentials and details exist, this is where all the users will be granted authorization access.

Prestashop is set up and configured as a service provider wherein only authorized users will be able to access the store.

Components Involved

• OAuth Client: PingIdentity on which all the employee portal is built all the user identities come from here.
• OAuth Server: Prestashop where the service will be accessed by the authorized users the Prestashop as OAuth Client plugin will be installed here.

To get the plugin you contact us HERE

Flow Diagram

Solution

1. PKCE grant flow

• PKCE stands for Proof Key for Code Exchange. It is a grant flow built on the authorization code grant, which is best used to enable OAuth SSO in public clients.
• PKCE works by having the client/app generate a random value at the beginning of the flow called a Code Verifier, and hashing it later, to create what is called the Code Challenge.
• This Code Challenge, which is used instead of a fixed client secret in a traditional OAuth flow, is then included in the query string for the request to the Authorization Server where the hashed value is stored for later verification and, after the user authenticates, redirects back to the app with an authorization code.
• The app makes the request to exchange the code for tokens, only it sends the Code Verifier instead of a fixed secret. Now the Authorization Server can hash the Code Verifier and compare it to the hashed value it stored earlier.
• Assuming the hashed value matches, the Authorization Server will return the tokens.

2. Using PKCE for the SSO

• Taking reference of the PKCE flow described above, when an employee tries to access the Prestashop store, the user will be redirected to the Prestashop as OAuth Client which will generate a code challenge using a cryptographically generated random code verifier.
• The plugin will then redirect the user via the authorization code request to the employee portal along with the code challenge prompting the user to login here. The employee portal will store the code challenge here for later verification.
• In the traditional OAuth authorization code grant flow, the authorization code request (or the request URL) will contain the client secret, but with the PKCE flow, this client secret will be replaced with the code challenge thus making the transaction much more secure.
• Once the user is successfully authenticated here, the employee portal redirects the user back to the plugin along with the Authorization Code. This authorization code will be valid for use for only one transaction.
• The plugin will then send over the previously generated code verifier and the authorization code to the employee portal where the previously stored code challenge and the code verifier will be validated.
• After validation, if the values of the code verifier and the code challenge match, the employee portal will send over the ID token and the necessary access token back to the plugin which can request for the user’s access data.
• The plugin then responds with the requested data, and the user can access the Prestashop store.

Additional Resources

• Login into Prestashop
• Prestashop OAuth SSO login
• Prestashop SAML SSO login
• Frequently Asked Questions (FAQs)