The describe solution does not follow OAuth best practices #5358
Description
Type of issue
Other (describe below)
Feedback
Hello,
I can see an issue with the configuration described in this document.
In the step 4 of the section "Register the add-in with Microsoft identity platform", the application is registered as an SPA.
However, a SPA is known as a "public client" in OAuth framework which means that it cannot securely store a secret -> conflict with the section "Add a client secret".
Additionally, a SPA, which, by definition, is running within a web browser cannot expose an API -> conflict with the section "Expose a web API".
As you may be aware, there are more and more cyber attack exploiting misconfigured OAuth App in EntraID. That the reason why we are spending a lot of time and money educating our developper on OAuth best practices. We would appreciate if Microsoft could also follow those best practices and does not mix public client and confidential client in the same app registration.
My understanding is that the app registration is representing a resource server when SSO is used to authenticate the user but it is representing a client if SSO fails and the authentication must fallback to webpage. Is it really the case?
I understand that it is easier for the developper to have a single app registration which cover all the use case. According to the Secure Future Initiative (https://www.microsoft.com/en-us/trust-center/security/secure-future-initiative), security should come before convenience.
I would appreciate if you could update the configuration guide (or even better, the design of the solution) to follow security best practices.
Best regards,
Léonard
Page URL
https://learn.microsoft.com/en-us/office/dev/add-ins/develop/register-sso-add-in-aad-v2
Content source URL
https://github.com/OfficeDev/office-js-docs-pr/blob/main/docs/develop/register-sso-add-in-aad-v2.md
Author
Document Id
120ecfb2-3d09-21bf-211e-e1e89050b52c
Platform Id
8f8e76fe-b0d2-4cef-cb6b-92a1717d141a