This is a follow-up for /twebauth-question/24157/8
Can you please provide the entire Claims collection back to the pascal code from TWebAuth?
I have Azure schema extensions, so the JWT contains additional custom details and I need to access it. Because it's custom, simply extending TMicrosoftUserData with one-two more standard properties is not going to be enough, I need the entire JWT, basically, or all the claims at a minimum.
Another thing is that it would also be nice to be able to get just the first PKCE "code" from Azure and stop at that. I will then be able to pass it on to another server, which can exchange it for me for JWT and return me the properties I need, so that the actual JWT never crosses the browser - it's more secure this way. The way it currently works is not secure enough for enterprise applications with any degree of sensitivity.
Before addressing the feature request thread separately, we have a feeling a few things should be cleared up first so we are on the same page.
Authentication was implemented by using the JavaScript library provided by Microsoft:
The flow is the following:
Create initial request link based on property setting → Call login → Get access token → Make request to https://graph.microsoft.com/v1.0/me with access token → Get results
We do not receive a JWT. We get a JSON from the Graph API at the last step with user information. It needs to be checked if claims can be added as an extra, but for that we'll need to allocate time to investigate as it's currently unclear how to do that.
A login is a promise that will resolve with an access token. There's no PKCE involved on our side. It's possible the library itself implements it into the login flow, but we have no access and no control over that. Again, it needs to be investigated if the library allows a more manual approach.
If you see any specifics in the library documentation that you'd need, feel free to link it here so we can take a look with that in mind.
You actually get 2 tokens: access_token & id_token, I need id_token, that's the JWT I meant.
Yes, I know, using MS JS is the easiest. It's not the most secure way, though. And just reading /me back is (ironically) not enough for me. You can of course leave what you have intact, as-is, but at the same time you could expose the id_token back to the caller as well - even without parsing it, it would still be sufficient.
Ok, yes, MS JS may be skipping steps, expectedly, but it generally works the same as Sphinx, so PKCE is available, if desired. You can talk to Wagner, or I can provide more details. It would make it more secure.
I've never actually used MS MSAL JS directly myself, but I think it should be capable of doing it. - again, that's for the "code" with PKCE, the JWT you are already getting, but ignoring - it's the id_token in the redirect.
We can look to expose access to the idToken that arrives from the redirect. It can still be part of TMicrosoftUserData though, under the name of IdTokenJWT. Or do you need access to this before the /me request?
Thank you for the reference. This will need to be investigated with more time allocation.
That would be perfect. Whatever is the easiest, of course. No need to have it earlier than /me. In fact a successful /me call gives us an extra assurance it's all good and legit ;-)