OAuth 2.0 Client Integration Manager
The PTC Admin Center empowers customer administrators of PTC technologies to manage organizations of users, licenses, and additional configurations. The new Integrations feature enables these administrators to connect 3rd party applications with PTC products to enable authorization of data via the OAuth 2.0 protocol.
Role
Lead Designer, PTC Atlas Team
Key Collaborators
Product, Engineering, Design, Tech Writing
Project Timeframe
July 2023 - October 2023
Challenge
The PTC Windchill+ segment team, offering Product Lifecycle Management (PLM) software to customers, needed a way to connect Windchill data to their Enterprise Resource Planning (ERP) systems to better support critical downstream user workflows. Using the current applications within the PTC SaaS ecosystem, also called PTC Atlas, what new features would be necessary to bridge this gap for users?
Results
As a Windchill+ administrator, I need to connect one of my company's business systems to Windchill+ so that I can use Windchill+ data in downstream workflows that are critical to our business.
Windchill+ administrators can now leverage the PTC Admin Center to setup customer-led OAuth 2.0 integrations between Windchill and their 3rd party ERP systems.
New features include the ability to manage data authorization brokered by PTC OAuth 2.0 clients, using:
Secret key rotation
Callback URL Editing
OAuth client data field exposure and copying
These features manifest in the following two pages:
Integrations Overview Page - Final Design
Individual Overview Page - Final Design
Discovery & Definition
To better understand the problems faced by Windchill end users, I started off by conducting meetings with key stakeholders, namely PTC Atlas and Windchill product teams.
Ultimately, I identified two main user groups impacted by this project:
Windchill End Users
These are the process engineers, service technicians, quality assurance engineers, etc. that leverage the software to analyze and visualize product data. Many of these roles additionally utilize ERP software to help support automation and processes in finance, human resources, manufacturing, supply chain, services, procurement. These systems have the capability to pull in external data, like data stored within Windchill, and further dissect and visualize it.
Key Need: The ability to pull in Windchill data from their ERP systems.
Windchill Product Administrator
These are the system administrators, technical support engineers, organization administrators, etc. responsible for managing the softwares within their companies. Specifically, these users leverage the PTC Admin Center to manage any SaaS based PTC products owned by their companies, like Windchill.
Key Need: Connecting their company’s Windchill instance with third-party ERP systems.
To support these connections, the backend engineering team adopted the OAuth 2.0 authentication framework. After stakeholder interviews, I mapped user journeys, refining insights through follow-ups and annotations.
End User Scenario
End users would utilize 3rd party technologies like PowerBI to analyze manufacturing data from PTC products, like Windchill.
Organization Administrator Scenario
Organization administrators would use the PTC Admin Center in conjunction with the desired 3rd party ERP system to set up an integration. This part of my journey came with many questions, which I annotated and had to validate with stakeholders.
Research and Analysis
Before diving into preliminary designs, I researched the problem space.
Many companies already offer similar solutions for configuring OAuth 2.0 clients/apps. Some examples include OpenAI (ChatGPT), Google, Microsoft, etc. During this research, I compiled a Miro board with product examples, taking note of patterns and behaviors.
Products I researched had similar features:
Ability to dynamically create OAuth 2.0 clients
Secret key rotation
However, while conducting this research, I realized that I did not fully understand the OAuth 2.0 protocol and how it fit together with PTC's application ecosystem. To fill this gap in knowledge, I watched Youtube videos and read documentation on the topic, and continued talking with the product and engineering teams to piece together any unknowns.
Creating an OAuth 2.0 diagram further helped solidify my knowledge of the topic and shift my approach towards also designing with technical constraints in mind.
Wireframing & Iteration
With this knowledge of the product space building up, I began to wireframe potential solutions.
The wireframes started off trying to satisfy initial requirements, but throughout the process allowed the team to understand more about the actual technical pieces involved with setting up these integrations.
The original assumption was that the most important part of integrations was the Secret Key, and that this was the main connecting piece to a customer's 3rd party application. However, sharing rounds of iterations led us to understand that management of Client IDs actually serve as the links to client applications, which explains the shift in designs from a Secret key driven UI to a Client ID led UI.
Iteration 1
In this first iteration, I tried to satisfy the main requirements through a layout similar to the products I researched:
Secret key rotation
Ability to dynamically create OAuth 2.0 clients
Secret key rotation
Display help text and OAuth client info like Callback URLs
Iteration 2
This iteration is similar to the previous but builds on the idea of better organizing secret keys.
I tie secret keys to actions using a table with the ability to:
Generate new keys
Rotate key values
Delete keys
The static information on the page, like help text and Client ID strings, remains similar to the previous iteration's as well.
Iteration 3
In this iteration, the focus shifts from managing specific keys to centering the management around Auth0 applications. An Auth0 application can take various forms, such as a native mobile app, a single-page web app, or a traditional web application. In our case, it facilitates customers in establishing connections with their third-party applications.
Our engineering team has configured every organization with default access to four applications, each requiring the management of essential fields like:
Secret keys
Callback URLs
As this page serves as the "landing page" for all Auth0 applications within the organization, I utilized insights from previous iterations to build a dedicated "individual page" for each app, enhancing overall usability and efficiency.
Final Designs
After validating my wireframes with key stakeholders, I created high fidelity mockups.
Informed by wireframing and the realization that managing OAuth applications through secret keys aligns seamlessly with the technical structure of Auth0, the final designs materialized into two key pages:
the Integration Overview Page
the Individual Integration Page.
Integrations Overview
Navigation
A set number of integrations are provided for the Organization, based on customer requests. Each integration in the table provides navigation via its linked name and the Manage button to its individual configuration page.
Secret Key Rotation
Just like periodically changing passwords, regularly rotating the client secret that an app uses to authenticate is a security best practice. Whether a customer rotates it and updates their app with the new key based on security protocols or if they need to set up a brand new integration, this workflow allows for a one time visible key generation for all use cases.
Callback URL Editing
The callback URL typically specifies the URL of an app that is designated to receive an authorization code on behalf of the client app. In other words, the callback URL found within the 3rd party customer application must be entered into the Integrations page in order for PTC services to correctly redirect back to the client app after it requests data from PTC. This experience allows the Customer Administrator to update this field.
Final Takeaways
Reflecting on this project, there were several key learnings and future steps to come.
Learning #1 - Challenge Assumptions
The original assumption was that the most important part of integrations was the Secret Key, and that this was the main connecting piece to a customer's 3rd party application.
However, sharing rounds of iterations led us to understand that management of Client IDs actually serve as the links to client applications, which explains the shift in designs from a Secret key-driven UI to a Client ID-led UI.
Learning #2 - Collaboration
This project pushed me to navigate unexplored territories, specifically Auth0 and integrations, requiring close collaboration with developers and product managers.
Learning #3 - Trial and Error
Embracing a trial-and-error approach, we successfully integrated Auth0 into the user experience, revealing the intricate technical landscape. This hands-on experience highlighted the crucial link between design and development in overcoming complex challenges.
It not only solved immediate issues, but it also fostered a culture of continuous learning.
Overall Reflection
Looking towards the future, I'm eager to apply these insights, fostering a culture of adaptability and continuous learning to craft designs that seamlessly align with evolving technologies.
Design Next Steps
As other PTC products, beyond Windchill, progress in their transition to SaaS, this design will have to evolve to accommodate any additional steps and features required for integration. The roadmap for these products is currently in the planning stage, so stay tuned for updates!
