c# - should sign in occur in the front-end or the back-end of an asp.net project

Question

I am trying to build a web project that will include user sign in. It will have an asp.net front-end, and an asp.net back-end. I am trying to figure out how this should work with user context and where user sign-in should happen. I believe controlling user sign in is a back-end responsibility, but it seems that many 3rd party validation methods would prefer it to be front-end. As I understand it seems that if I was using something like google or Microsoft validation. It would try to bring up a window, but that window wouldn't be seen by my user, because it was coming from the back-end that is not serving them, and is instead serving the front-end server.

question from:https://stackoverflow.com/questions/65645994/should-sign-in-occur-in-the-front-end-or-the-back-end-of-an-asp-net-project

Answer 1

Based on your comments I'll try to summarize a bit here. Do note, that this is not a coding question and should really have been asked on https://security.stackexchange.com/, but I'll give it a go.

A few keywords you should read up on:

• Authentication: This is the process of verifying the identity of an entity (a person, device etc.)
• Authorization: This is the process of granting access to a given resource based on some parameters - usually based on a verified identity
• Identity provider: A system that manages and can verify the identity of an entity (in your example that would be Google or Microsoft)
• Service provider: A system providing a service to authenticated entities (in this case your server application)

OAuth, which you use as an example, is not an authentication protocol but an authorization protocol, which makes it important for you to understand the difference. However, OpenID Connect is a protocol/layer built on top of OAuth 2.0 and...

It allows Clients to verify the identity of the End-User based on the authentication performed by an Authorization Server [read: "Identity provider" under the hood]. [source]

Copied from Wikipedia (point 8 removed to avoid confusion):

The communication flow in both processes is similar:

1. (Not pictured) The user requests a resource or site login from the application.
2. The site sees that the user is not authenticated. It formulates a request for the identity provider, encodes it, and sends it to the user as part of a redirect URL.
3. The user's browser requests the redirect URL for the identity provider, including the application's request
4. If necessary, the identity provider authenticates the user (perhaps by asking them for their username and password)
5. Once the identity provider is satisfied that the user is sufficiently authenticated, it processes the application's request, formulates a response, and sends that back to the user along with a redirect URL back to the application.
6. The user's browser requests the redirect URL that goes back to the application, including the identity provider's response
7. The application decodes the identity provider's response, and carries on accordingly.

This is the flow you're asking about. The only thing the client (front end) does is follow the URLs it's provided from your application in order to visit an authentication server. This server then provides the proven identity that your client then passes on to your server again.

So bottom line is, the client/front end does not perform the authentication, that's handled by the identity provider (a 3rd party backend).