Hi All,
In the Microsoft login connector core forge component having one REST API which has No Authentication. Will it cause any issue ? Is there any chance of stolen the client id and client secret due to this REST API ?Please find the below screenshot and provide your thoughts on the same.
Thanks,
Ajit Kurane.
Hi,
the REST operations on the screenshot are consume operation. For code exchange e.g. OS posts client id and client secret to the token endpoint of entra to retrieve id and access token. OS communicates via SSL with Entra so at least the transport is encrypted. However, as written in your other question on the forum, PKCE increases security here.
The "Authentication" on the screen refers to how the consume operation authenticates against the endpoint which does not apply to the token endpoint of an OpenId Identity Provider like Entra.
Stefan
Thank you so much for your response.
So could you please guide me How can I implement PKCE in the current implementation and exactly in which part of code or component we need to implement it ? Please provide your detailed inputs that will be guide us to follow the steps and improve the security. Your inputs on this crucial scenario will be highly appreciated.
Best Regards,
Ajit Kurane
Please check out my Multi OAuth Account Linking Demo on Forge, that has a basic implementation of PKCE support using my OAuthTokenExchange component. Note that this demo shows account linking and not signing in, but it should give you guidance on how to implement PKCE support.
I have checked the demo you suggested but that code in which part of login connector component I need to use that I am not getting?
Could you please provide me the specific code area where I need to implement this PKCE support code ?
My Apologies for so many doubts on the same concept.
You have to modify the OAuth2_CreateAuthorizationRequest and the OAuth2_GetAndParseToken actions. Here is a documentation that explains a sample PKCE server side flow https://www.oauth.com/oauth2-servers/server-side-apps/example-flow/
Hello Stefan,
In below action I am not gettting where exactly I need to use this PKCE concept, Could please guide me for the modification ?
You have to start with the Authentication request url. (so the GetAuthenticationRequestUrl action). The url needs to include the challenge and challenge method.
Stefan is right, the component doesn't necessarily support PKCE as it exists right now, but it would be fairly easy to incorporate it yourself. Please reference this Azure documentation page as it has detailed instructions on how to include your code verifier in the URL generation step and then how to include it in the callback step which actually retrieves the access/ID tokens from Azure. In broad strokes:
Hello Grayson,
Thanks a lot for the suggestion.That would be great if you provide me sample oml with modification in existing code of the MS login connector so that in another action I will replicate the same. I am facing technical difficullty to implement the same in the existing component server action which stefan has mentioned in the above reply.
@Stefan Weber , @Grayson Udstrand :
My understanding of this component is as follows:
However, I’m not sure whether implementing PKCE would actually make this more secure. If PKCE is implemented then the Callback Page automatically retrieves the stored challenge from the database and sends it to the token endpoint. This means that even if another user manually calls the Callback Page with the same parameters, the server would still fetch the stored challenge and successfully exchange the authorization code for tokens.
Is my understanding correct?
PKCE just adds an additional layer of security to the mechanism regarding code spoofing. The code alone without the challenge is useless as for a successful exchange for a token both are needed. With PKCE to retrieve an access token you need to pass both the authorization code received plus the generated challenge you created before redirecting the user to the page.
Thanks, @Stefan Weber . PKCE will indeed enhance security, as the challenge isn’t available to the caller, preventing unauthorized token retrieval.
However, in this component, the CallbackPage can be explicitly invoked with a code and state, which then fetches the token and logs in the user - regardless of whether PKCE is implemented. Even if PKCE is used and the challenge is sent, invoking the callback page directly bypasses the intended flow, and the user ultimately still gets logged in. This effectively makes the callback page as a backdoor.
Not at all, the callback page isn't a "backdoor" it's a fundamental part of the OAuth 2.0 authorization code flow as it's the part where your app gets to exchange a single-use nonce (the authorization code) for tokens from Azure. Abusing this is mostly almost entirely prevented by setting a whitelist of allowed callback screen URLs for this callback to occur from in Azure so you cannot just get a token from a page an attacker set up. In order for the security of the callback page to be jeopardized, the attacker would either need to intercept the authorization code in transit (extremely unlikely) or guess the authorization code, which is basically mathematically impossible. The PKCE challenge adds one final layer that renders the event where the authorization code is stolen basically moot as well since the final gate where the code challenge is retrieved from the database and sent with the token request happens entirely within your own server.
I strongly encourage everyone who uses this plugin to familiarize themselves with the fundamentals of OAuth 2.0 before trying to use it. Once you understand the basics of how all the spec works, the way this component implements the authorization code flow will make sense to you.
Yes. PKCE is not a security measure for the callback page, it only protects against spoofing. So retrieval of state and code by a man-in-the-middle. Without the challenge this attack vector is mitigated.
There are several additional mitigation actions that can be applied at callback level, like checking the origin. For a much higher security a MTLS certificate can be applied at entra level.
Thank you for the details.
When are you planning to update the component code for these PKCE challenge? Is there any update on this ?
I am not sure what the other authors of the component have planned, but I am not planning on adding PKCE to the component. I suggested that you should be able to customize the component yourself and add PKCE with relative ease.
Thanks for the clarification, @Grayson Udstrand - you're absolutely right that the callback itself isn’t a backdoor but a core part of the OAuth 2.0 authorization code flow. I was referring specifically to how this component’s CallbackPage behaves - in this implementation, it can still be directly invoked outside the normal login flow, potentially allowing token retrieval without the expected initiation sequence.
That said, this doesn’t imply a weakness in OAuth or PKCE itself. Proper server-side validation, along with mitigations like origin checks keeps the flow secure even if the callback is directly accessed.
Thanks @Stefan Weber for your inputs.