Improve Auth flow local vs Azure

[ericsche]

Proposing a small code update to run token validation only when the code is ran locally, when hosted in Azure we use EasyAuth.
When doing the lab we ran into issue because we had the double Token check, EasyAuth was accepting the token but we still got a 401 because some of the env Variables were not set correctly.
This took us 4hrs to troubleshoot. Proposing this new code so there is only one Authentication validation :
Local you check your code
Azure you check easy Auth.

FYI : @BobGerman @waldekmastykarz

[BobGerman]

How does one debug a 401 when Copilot is calling Easy Auth directly and there is no way to look at the token? I agree the double auth should go and was an oversight on my part, but I suggest removing Easy Auth not the coded validation ...

[ericsche]

actually Easyauth has a very good troubleshooting wizard on azure where you can see what is wrong without seeing the token. on top of that the token validation is not that easy in the code. Envoyé à partir de Outlook pour Android<https://aka.ms/AAb9ysg>

…

________________________________ From: Bob German ***@***.***> Sent: Friday, November 1, 2024 3:53:24 PM To: pnp/copilot-pro-dev-samples ***@***.***> Cc: Eric Scherlinger ***@***.***>; Author ***@***.***> Subject: Re: [pnp/copilot-pro-dev-samples] Improve Auth flow local vs Azure (PR #14) How does one debug a 401 when Copilot is calling Easy Auth directly and there is no way to look at the token? I agree the double auth should go and was an oversight on my part, but I suggest removing Easy Auth not the coded validation ... — Reply to this email directly, view it on GitHub<#14 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AIP3UEFV6USVOSYFP6W7DK3Z6OIWJAVCNFSM6AAAAABQ75JJHOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDINJSGAYDQNJYHE>. You are receiving this because you authored the thread.Message ID: ***@***.***>

[waldekmastykarz]

While I understand the point, I think it's a dangerous pattern to introduce. The proposed approach means including a branch of code that's used only during local development and doesn't match how the API will run in production. Say that there's a bug in the local validation logic: is there a chance that developers might waste time fixing it while the production version would work just fine?

If we want to show implementing custom validation logic, I suggest we use a different sample that doesn't use Easy Auth in production and uses custom validation both locally and in prod. That way, we have a realistic setup that's relevant to developers and teaches them a pattern they're likely to use in real life.

[ericsche]

Yes that would be the best approach functionally speaking but security wise I guess it is better to use service auth vs custom code 😁. I tried myself and actually it is not that simple to implement Envoyé à partir de Outlook pour Android<https://aka.ms/AAb9ysg>

…

________________________________ From: Waldek Mastykarz ***@***.***> Sent: Monday, November 4, 2024 8:53:06 AM To: pnp/copilot-pro-dev-samples ***@***.***> Cc: Eric Scherlinger ***@***.***>; Author ***@***.***> Subject: Re: [pnp/copilot-pro-dev-samples] Improve Auth flow local vs Azure (PR #14) While I understand the point, I think it's a dangerous pattern to introduce. The proposed approach means including a branch of code that's used only during local development and doesn't match how the API will run in production. Say that there's a bug in the local validation logic: is there a chance that developers might waste time fixing it while the production version would work just fine? If we want to show implementing custom validation logic, I suggest we use a different sample that doesn't use Easy Auth in production and uses custom validation both locally and in prod. That way, we have a realistic setup that's relevant to developers and teaches them a pattern they're likely to use in real life. — Reply to this email directly, view it on GitHub<#14 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AIP3UEGIYTIPM4ABB7DZWNDZ64RWFAVCNFSM6AAAAABQ75JJHOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDINJUGAZDKMBUGA>. You are receiving this because you authored the thread.Message ID: ***@***.***>

[waldekmastykarz]

100% that service auth is preferred because it minimizes the chance of developer error. Like you noticed, it's not trivial and requires a solid understanding of security.
That said, I suspect that some organizations might have to/prefer to use a custom solution and we should meet them where they are too 🙂

[BobGerman]

A compromise idea is to add logic similar to what @ericsche proposes but instead of checking for local hosting, it would check for Easy Auth headers.
If the headers are there, the code would use them, and show how to access the user name and upn as well for authentication. This would be more interesting in the Trey Research sample where we could assign consulting projects to the actual user. If Easy Auth headers are there, Waldek's lib won't help anyway since they do not include the original token.
If the headers are missing, the code would use Waldek's library as written.
Thus the code would work with or without Easy Auth.

@waldekmastykarz would that address your concerns on having 2 code paths? One might go untested - in particular the Easy Auth one which doesn't work locally ...

[waldekmastykarz]

I'm trying to decide based on: is this code you'd put in production. In my eyes, you'd either use Easy Auth or not, but not both, and you'd align the code based on your architectural decision. I suggest we keep the sample simple and focused on the scenario: if it's meant to illustrate using Easy Auth, let's do that. If we want to show custom validation logic, let's show that, in as close to real setup as possible.