The main difference between the two grant types is all about how the aforementioned OAuth2 access token is requested, obtained and handled; in short, how steps 2 and 3 are actually performed.

In a standard implicit flow, these steps are entirely performed by the client-side part of our web app--often using a client-side SDK such as the Facebook JavaScript SDK--and the external provider servers. More specifically:

• The pop-up window (step 2) will directly point to the external provider login/authorization page
• After the login and auth, the OAuth2 access token (step 3) will be directly fetched by the client-side part of our web application and then sent to a dedicated server-side API controller, which will use it to retrieve the user data and perform the account creation/login (step 4)

Conversely, when using an explicit flow grant type such as those provided by AspNet.Security.OAuth.Providers, Windows SDK for Facebook, or OpenIddict, these same steps take place in the following way:

• The pop-up window (step 2) will point to a server-side intermediate page of our app, which will then redirect the user to the external provider login/authorization page
• After the login and auth, the external provider will redirect the user to a specific callback URL along with an authorization code that will be used by the server-side part of our application to retrieve the actual OAuth2 access token (step 3) and then immediately use it to retrieve the user data and perform the account creation/login (step 4)

Either of these approaches is viable enough; however, they both have their pros and cons in terms of security and versatility, depending on the given scenario.