How to avoid Perils of Implicit Grant Flow/ID Token?

Siegfried Heintze 1,861 Reputation points
2020-05-12T17:19:13.72+00:00

After fighting to get some tutorial examples from 9781484250396 working, I learned that most of the examples required that I check the ID tokens feature for Implicit grant flow.

The text on the port.azure.com on the page for registering an AAD webapp and configuring the authentication says this under "Implicit Grant":

"Allows an application to request a token directly from the authorization endpoint. Checking Access Token and ID Token only recommended if the application has a single-page architecture (SPA), has no back end components and does not use the latest version of MSAL.js with Auth Code Flow, or invokes a Web API via JavaScript. ID Token is needed for ASP.NET Core Web Apps. Learn more about the implicit grant flow".

Is this correct? It sounds wrong where it says that ID Token is needed for ASP.NET Core Web Apps! I was hoping the Microsoft Examples of WebAps for .NET Core 3 would not require me to use the ID Token. If this is correct, it sounds like the only salvation is to use the latest version of MSAL.js instead of C# for all authentication.

What about .NET Framework? Do WebApps written in .NET Framework require ID Token?

Where can I find some tutorials that don't require ID token/Implicit Grant Flow that don't authenticate with javascript?

Microsoft Entra ID
Microsoft Entra ID
A Microsoft Entra identity service that provides identity management and access control capabilities. Replaces Azure Active Directory.
19,559 questions
0 comments No comments
{count} votes

Accepted answer
  1. soumi-MSFT 11,716 Reputation points Microsoft Employee
    2020-05-21T09:28:59.633+00:00

    @SeigfriedHeintze-9929, We have never said that Auth Code Grant flow is not a secure alternative for Implicit Grant Flow. But as mentioned in my previous response until now, we only recommended implicit grant flow for SPA (javascript based applications) by implementing MSAL.

    With the advent of of MSAL v2.x now MSAL.js is capable of implemeting Auth-Code Grant flow. You can take a look at the sample present here: https://github.com/Azure-Samples/ms-identity-javascript-v2

    For web-apps or any other desktop/mobile apps Auth-Code Grant flow is always recommended. You can check the following url to check the samples available for various platforms including ASP .net core and ASP .net Frameworks: https://learn.microsoft.com/en-us/azure/active-directory/develop/sample-v2-code#web-applications

    For PKCS (Public Key Certificate Services) is something that is a certificate which can be used in place of the app secret in the app registration. This certificate can be used for authenticating the application with an IDP. It can be used with any of the OAuth flows what needs a client secret to be produced in the request. I have not came across any samples that have used PKCS with any of the OAuth flows.

    Hope this helps.

    Do let us know if this helps and if there are any more queries around this, please do let us know so that we can help you further. Also, please do not forget to accept the response as Answer; if the above response helped in answering your query.

    0 comments No comments

6 additional answers

Sort by: Most helpful
  1. soumi-MSFT 11,716 Reputation points Microsoft Employee
    2020-05-15T08:57:08.25+00:00

    @Siegfried Heintze , I would like to share the answers to the questions you sent. Please find them below:

    (1) Did you mean MSAL.js?

    Ans: Yes, the library would be MSAL.js since we are using javascript to create the SPA application.

    (2) I've been exploring the many examples and have noticed that many of them use implicit grant flow because they are SPAs with no back end. Can some one please point me to a tutorial example that correctly uses MSAL.js to securely call a back end?

    Ans: You can consider using this example here: https://learn.microsoft.com/en-us/azure/active-directory/develop/tutorial-v2-angular
    This is an Angular SPA though. But should help you with the understanding.

    This is a Javascript SPA application calling Microsoft Graph API sample available: https://github.com/Azure-Samples/active-directory-javascript-graphapi-v2
    Both of the above examples uses Implicit Grant Flow using MSAL.js

    One more interesting code sample you might consider, that is with the latest MSAL.js version. This sample implements Auth-Code Grant Flow for an SPA using MSAL.js:
    https://github.com/Azure-Samples/ms-identity-javascript-v2

    You can also check out this page, it has all the samples available: https://learn.microsoft.com/en-us/azure/active-directory/develop/sample-v2-code

    (3) Let's suppose I follow your recommendation and call my ASP.NET/MVC WebAPI with MSAL.js. Please confirm that it is not possible for my custom WebAPI to securely use azure features such as azure queues (protected by AAD) via REST as described in create-queue4 as this would require implicit grant flow and these features must only be called directly from the browser via MSAL.js.

    Ans: Not sure on this one. but looking into this and trying to get a confirmation. But overall I can say, if you are using ASP .NET/MVC application using C#, it is advisable to go ahead with one of the libraries available, preferably MSAL (since its the newer version) and following an OAuth flow apart from the implicit flow. Most preferably the On-Behalf-Of flow of OAuth if you land up in a service-to-service communication. You can look into the samples available here.

    Few points that I would like to point out is:

    • In case you are developing a web api (using ASP .NET/ASP .NET Core), that would only be validating the tokens, then that part is not done by MSAL. For that you would have to write our own code to validate the token using Open ID Connect.
    • In case you are creating a Web App, thats where the authentication of the web app comes in to picture, where the web app needs to fetch a token which it might be using in the future to call a AAD protected API, for this we can implement MSAL library for ASP .net/ .net core to just fetch the access token.

    (4) I've been studying TodoListController.cs and README.md. I'm struggling to understand the difference between the insecure implicit grant flow (when coding in C# inside a webapp to access the back end) and the behalf of flow. The documentation v2-oauth2-on-behalf-of-flow uses the term service-to-service and I'm wondering why this cannot work for webapp-to-service? Can I use the behalf of flow in the C# in a webapp to securely call a back end as a secure alternative to the implicit grant flow in C#? Is there a tutorial example of this I can study?

    Ans: Yes, you can use On-Behalf-Of flow with C# to call a webapi securely by implementing an auth library i.e MSAL.

    Hope this helps.

    Do let us know if this helps and if there are any more queries around this, please do let us know so that we can help you further. Also, please do not forget to accept the response as Answer; if the above response helped in answering your query.

    0 comments No comments

  2. Siegfried Heintze 1,861 Reputation points
    2020-05-21T04:14:41+00:00

    I've been bing searching, reading books, studying your examples and others examples and I've learned about PKCS and was delighted to see that the ms-identity-javascript-v2 example works.

    (1) Is there a reason you did not recommend PKCE & Auth Code Grant Flow as a secure alternative to the Implicit Grant Flow? I have read that implicit grant flow was insecure from the beginning and was only defined because in 2010 browsers did not have CORS and now that browsers have CORS there is no reason to use implicit grant flow. Is this consistent with your understanding?

    (2) Is there an example of the PKCE & Auth Code Grant Flow with a C# web app that demonstrates securely calling a C# back end Web API with C# (instead of JavaScript AJAX)? I was surprised that I could not find a Microsoft example. Can you recommend a C# example of PKCE & Auth Code Grant Flow that is secure for web apps & back ends?

    Thank you!

    Siegfried

    0 comments No comments