Closed jiscfoo closed 9 months ago
Hello @jiscfoo !
Sorry for the late response! I can understand the desire for this feature. However, I personally lack concrete OIDC use cases and especially the know how to implement it 😉
Do you have the time and desire to contribute this? Or someone else?
I'm wondering what the added value would be, since OIDC-tokens are passed through a back-channel..
That was my first thought, too. But since I don't know OIDC well enough, I wasn't/am not sure if there could be a meaningful use beyond that?
So, what do we want to do? Does anyone here see the possibility of extending SAML-tracer in a meaningful way?
I found this StackOverflow answer by @scottwtang: https://stackoverflow.com/questions/72817883/how-or-where-can-i-access-my-vault-oidc-logs-and-jwt-claim-metadata/72825112#72825112 Scott describes how one could retrieve some information when the authorization code flow is used.
SAML-tracer could certainly reproduce these steps. But that would be a process that would really deviate a LOT from the current process for tracing SAML tokens...
Any thoughts?
Me neither... I was expecting it to be a few extra regexes and formatting and that doing so would make OIDC more accessible (in the same way the SAML tracer makes the flow so much easier to understand). I thought it wouldn't be too onerous having used an Edge extension which does both SAML and OAuth2 [1] and, from the few times I've used it, has provided useful information from the assertion
I don't want to say: "Stop using SAML-tracer" 😉 But if the other extensions works for you, isn't that okay?
As I personally do not currently have the need for OIDC support, I believe that this lack of need would make implementation more difficult for me. Do you know what I mean?
I don't want to rule out the possibility of this need arising one day. It probably won't be too long before one of my customers insists on OIDC and I think to myself: Oh, if only SAML-tracer supported this... 😉
Since Tim and Thijs don't seem to be passionate about this topic either, I'll close the ticket (for now). Especially as you also have an alternative with the other extension.
I don't want to say: "Stop using SAML-tracer" 😉 But if the other extensions works for you, isn't that okay?
Not exactly, as it requires the use of Edge... but I understand the reasoning 😸
Given that many SAML implementations now also support OIDC and that this plugin also supports WS-Fed, it would be very useful for this plugin to also support debugging/tracing OIDC flows.