Span linking during redirects

[denysandriyanov]

I'm currently working on implementing an OAuth2 authentication system utilizing the code grant flow. However, I'm encountering an issue with span linking during redirects. I'm using Quarkus 3.6.0 along with the latest OpenTelemetry.

The challenge I'm facing is that every redirect in the code flow seems to create its own span, resulting in separate tracks and new traceId flows. I'm striving to maintain continuity across these redirects, ensuring that all spans remain under one trace. This is essential for comprehensive visibility within tracing systems like Zipkin or Jaeger.

Adding the traceparent header manually doesn't seem to link the spans together. Instead, it creates a new span that attaches to the base process as the last one before initiating a new trace for the required endpoint. Unfortunately, this new span lacks necessary tags or information.

In essence, I'm seeking guidance or suggestions on how to link one span with another, ensuring the retrieval of all the essential tags throughout the OAuth2 authentication flow amidst redirects.

Has anyone encountered a similar issue or found a solution to maintain continuity in spans across redirects in an OAuth2 flow?

Your insights or ideas would be immensely helpful. Thanks in advance for your assistance!

[sberyozkin]

@denysandriyanov
Indeed, it is a tricky challenge, and I agree with your updating the title since redirects are possible not only with OAuth2/OIDC.
I can only imagine that one has to trace cookies. If you work with quarkus-oidc, then a transient q_state cookie is available during the redirect, but you'd intercept requests before the security code removes it, probably a Vertx filter would have to be used.

Also CC-ing @brunobat who is busy right now but will be online soon.

[denysandriyanov]

@sberyozkin I am not using quarkus-oidc, rather having own implementation as we have some specifics in the flow, could you please elaborate more how to use the aproach you suggest to solve the issue I am trying to solve.

Thank you

[sberyozkin]

could you please elaborate more how to use the aproach you suggest to solve the issue I am trying to solve.

Well, I can't imagine how spans can be linked across redirects unless a cookie that can be used to associate the current request with the one which was running before the redirect started is used to link such requests. So I'd look into using cookies

[denysandriyanov]

@sberyozkin that part is clear, but the question is then how to link. Let's assume I am using cookie to transport some info to the redirect request. What's next. How to link it?

[denysandriyanov]

I mean, yes we can get the traceId and spanId of parent trace and send it through cookies so the following resource recieves it. No problem with this, but the problem is then how to associate this request using this data.

For example scenario below:
The scenario involves an initial request directed to the /login endpoint, followed by a subsequent redirection to the /login/other endpoint. This sequential flow generates separate trace IDs for each request, leading to the creation of distinct traces. The primary objective is to consolidate these requests under a single trace ID while establishing a relationship where the /login/other request is a child span of the /login span.

The challenge we're facing is the need to set the parent span ID and trace ID somehow before the trace initialization to ensure that both endpoints contribute to a unified trace. The current method generates two separate traces:

The trace initiated during request initialization, which lacks the required trace ID and parent ID linkage.
The trace created through subsequent manipulation, containing the desired trace ID and parent span ID but lacking essential information from the initial trace.
The goal remains to correctly link these spans under one trace while maintaining the parent-child relationship between the /login and /login/other spans. We're exploring strategies to set the context beforehand, preventing the creation of separate traces and ensuring proper linkage within a unified trace.

May be there is some way we can intercept/filter request before span context is set and set it with our values of traceId and parent trace id? Or may be there are some headers we can set that quarkus will read and understand that there is not standalone/new request but rather a part of the other flow and will use data from headers accordingly to set traceId and parent spanId?

Your insights on how to effectively manage this tracing scenario would be greatly appreciated.

[brunobat]

Issue about this problem: #37211