@ABHATTCHRYA Q1: 

When a React page connects to Pega using DX APIs, it uses two components for authentication: the Auth Profile and the OAuth 2.0 Client Registry. Here’s how they work together.

The OAuth 2.0 Client Registry contains the client details like client_id, client_secret, and scopes. These are used to generate a token when the application connects to Pega. This token is a key that confirms the client’s identity and permissions. The Auth Profile defines how this token is used for API calls, such as whether the token is sent in the headers or as part of the request.

For example, imagine a React page calling a DX API to get case data. First, it uses the client ID and secret from the OAuth 2.0 Client Registry to get an access token. This token is then attached to every API request as proof of authentication. The server validates the token before allowing the request. While it is technically possible to use different client IDs in the Auth Profile and Client Registry, it is not recommended, as it can lead to configuration mismatches and errors. Q2: The access token and refresh token serve different purposes. An access token is short-lived, often valid for just 15 to 30 minutes, and is used to authenticate individual API requests. A refresh token lasts longer, sometimes hours or days, and is used to get a new access token without needing to log in again.

For example, if a React page fetches data every few minutes, the access token will eventually expire. Instead of asking the user to log in again, the application uses the refresh token to get a new access token. This process is seamless for the user.

Token timeouts work with the Pega session timeout (defined by the access group). If the access group timeout is shorter than the token timeout, the session may end even if the token is still valid. On the other hand, if the token expires first, the application cannot make API calls until a new token is issued. This ensures security while allowing uninterrupted application use. Q3:   

When tracing DX APIs like data_view or assignment, you might notice that the tracer sometimes shows data from a different case. This happens because the tracer captures multiple threads or requests at the same time, and the UI may mix them up.

For instance, if you are tracing Case A but another request for Case B is running simultaneously, the tracer might incorrectly display Case B's data. This is a known issue with the Pega tracer.

To work around this, you can use filters in the tracer to focus only on the specific case ID you are debugging. For example, if you are working on Case A, set a filter to include only the pyID for Case A. Additionally, you can enable the "Capture only current requestor" option in the tracer settings to limit the logs to your current session. This reduces the chances of seeing data from unrelated cases.

Example: 

Imagine a healthcare application where a React page shows patient information. When the page loads, it first requests an access token using the OAuth 2.0 Client Registry. This token is then attached to all API calls (e.g., fetching patient details). If the token expires, the application uses the refresh token to get a new one without interrupting the user.

If you encounter issues during testing, such as seeing patient data from another case in the tracer, you can filter the tracer by the patient’s case ID or limit the capture to your session. These practices ensure a smoother debugging experience.