Learning about authentication in aspnetcore

[jaredpar]

Looking to add GitHub based authentication to a razor site that I run. Could not find any solid tutorials on the web for doing this. Instead I started at the OAuth Providers site and worked out authentication from there.

The samples there are good but they're still based in MVC. There was no example on how to do it with only Razor pages and / or hand route mapping. I managed to get it working though here. That commit is basically the delta between dotnet new razor and getting GitHub authentication working.

Even though I have it working now I still have a few questions:

1. Ended up defining a SignOut page just so I could use PageModel.SignOut. That feels really heavy weight and indirect particularly because signing out really doesn't have a UI. My instinct was that I should use endPoints.MapPost("/signout", ...) but I could not find a way to actually sign out from that context. Is there a way to do this or do I need to define a page in order to sign out?
2. I want to add claims based on the GitHub user name but I'm unsure where to do that? I assume there is a method I can hook for when a user is authenticated and then I can map GitHub data to claims in my app. What method should I hook though? Can't find that.

Thanks for any help here.

Note: I'm brand new to both razor and authentication so if u think I'm doing something incredibly wrong please make sure to say so because I probably am 😄

[Pilchie]

@javiercn any thoughts here?

[javiercn]

1. Ended up defining a SignOut page just so I could use PageModel.SignOut. That feels really heavy weight and indirect particularly because signing out really doesn't have a UI. My instinct was that I should use endPoints.MapPost("/signout", ...) but I could not find a way to actually sign out from that context. Is there a way to do this or do I need to define a page in order to sign out?

You can inline the handlers within an @functions block in the razor file. and that way you don't need the backing pagemodel.

Logging out is not as simple as it looks if you provide a button for it. Even though you could create an endpoint through .MapPost and then trigger the sign-out from there you would be subject to Cross-Site request forgery attacks (which I imagine is not important for this app, but that is the case in real-life)

For logging in, you don't need a page at all if you don't have a button on the UI to perform the action. (Instead, you can slap [Authorize] on the page model or use @attribute [Authorize] on the page and it will trigger authentication automatically.

One improvement you can do in startup is to setup the GH auth handler as the default handler for a Challenge (as shown below) that way, when a user visits a protected page it automatically starts the authentication flow.

services.AddAuthentication(options =>
{
    options.DefaultScheme = CookieAuthenticationDefaults.AuthenticationScheme;
    options.DefaultChallengeScheme = GitHubAuthenticationDefaults.AuthenticationScheme;
})

In conclusion:

• If you are not doing something to deploy to the public, you can get away with mapping and endpoint and issuing the signout from there.
• For real-life you would need a real page or a Controller:
  • I normally prefer a controller if I don't have any UI associated with it.
  • A page is fine if you want to display some UI after you've logged out the user instead of redirecting him to the home page.
• Configure the GH scheme to be the default challenge handler if you don't want to add a login button.

Other than that, the sample you have there looks right (other than small things you don't need from the signin and signout pages, but nothing problematic)

WRT docs there seems to be not much, just this

[jaredpar]

@javiercn

Even though you could create an endpoint through .MapPost and then trigger the sign-out from there you would be subject to Cross-Site request forgery attacks

Interesting. Never would have thought that. Is there a place I could read up more on how that could occur?

If you are not doing something to deploy to the public, you can get away with mapping and endpoint and issuing the signout from there

This site would be available publicly, even though not advertised or expected to be used by the public. Still though would like to act as if it was used by the public and do things correctly.

I normally prefer a controller if I don't have any UI associated with it.

Is there a reason for this? This does seem to be the general style that I saw in a lot of examples that I saw. Thought it may have been that samples just hadn't fully updated to Razor. Given your comment though it seems mixing MVC and Razor this way is somewhat expected, not an artifact of old habbits.

Configure the GH scheme to be the default challenge handler if you don't want to add a login button.

Will try that.

Thanks for the help!

[javiercn]

Interesting. Never would have thought that. Is there a place I could read up more on how that could occur?

Not sure if the docs here have it, but essentially, someone from another origin can force a post request without you knowing and logging the user out, although this is less prevalent these days since most browsers support samesite cookies, which prevent this too.

Is there a reason for this? This does seem to be the general style that I saw in a lot of examples that I saw. Thought it may have been that samples just hadn't fully updated to Razor. Given your comment though it seems mixing MVC and Razor this way is somewhat expected, not an artifact of old habbits.

It comes down to a matter of preference. Razor pages perform antiforgery validation by default, while in MVC is an opt-in feature. That is because Razor pages are explicitly designed to write UI code while MVC controllers are more flexible and allow you to write UI code and APIs, so performing antiforgery validation by default would be cumbersome for API authors (they would have to disable it, not to mention it was not on by default for historical reasons and turning it on by default would break a lot of customers apps).

I wouldn't pay too much attention to the samples in the asp.net core repo, in many cases they are a playground for features and don't necessarily reflect best practices. I believe there are more "canonical" sample apps in the docs.