Aspnetcore.docs: The authentication middleware takes care of routing requests back to the handler

[Mike-E-angelo]

The documentation on this concept is very well-done. Thank you for putting the effort into explaining it all here. I was able to setup as prescribed without much friction at all.

The only friction I now have is this magic callback uri, /signin-twitter ... it would be very valuable to know how to access this file and override it as necessary.

FWIW, I am assuming this is possible as I have been exploring the identity scaffolding architecture and see a lot of functionality that can be overridden there. I do not see anything for /signin-twitter there so this is why I inquire here.

Thank you for any consideration towards adding more information around this.

---

Document Details

⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

• ID: cb577d84-a06b-4d3e-a1c4-92c8a97a85aa
• Version Independent ID: 528fcbb8-5b0f-8340-743f-df612319a229
• Content: Twitter external sign-in setup with ASP.NET Core
• Content Source: aspnetcore/security/authentication/social/twitter-logins.md
• Product: aspnet-core
• Technology: aspnetcore-security
• GitHub Login: @Rick-Anderson
• Microsoft Alias: riande

[Rick-Anderson]

The URI segment /signin-twitter is set as the default callback of the Twitter authentication provider. You can change the default callback URI while configuring the Twitter authentication middleware via the inherited RemoteAuthenticationOptions.CallbackPath property of the TwitterOptionsclass.

[Rick-Anderson]

@HaoK how to get access to /signin-twitter?

[Mike-E-angelo]

Yeah it is indeed set to that property. To add to the mystery, I believe I found its implementation here:

https://github.com/dotnet/aspnetcore/blob/fece4705eec5b2a118d9bd8b68eb867d2f573f7c/src/Security/Authentication/Twitter/src/TwitterHandler.cs

However, I am not quite sure yet how /signin-twitter maps to that implementation. My expectation was that this is something that could be scaffolded like the rest of the Identity API, but that does not appear to be the case.

[HaoK]

The authentication middleware takes care of routing requests back to the handler, see https://github.com/dotnet/aspnetcore/blob/master/src/Security/Authentication/Core/src/AuthenticationMiddleware.cs#L44

[Rick-Anderson]

@01binary should I add @HaoK comments to all the docs? It's also very discoverable from this issue.

[Mike-E-angelo]

In my case and FWIW, I looked to see if this was already discussed in the closed comments before posting a new one. I was eyeballing for "signin-twitter" in the title, however.

[Rick-Anderson]

@Mike-EEE but this applies to all the OAuth 2.0 providers, and twitter has about the lowest usage of all the articles.

[Mike-E-angelo]

Sounds good to me, @Rick-Anderson ... my only outstanding inquiry is that the title of this issue seems to have been renamed... and wanted to verify if that was intentional or not as currently, it reads like a sentence fragment. 😊

[Rick-Anderson]

Yes I intentionally changed it so it can be discovered by anyone wondering how this works with the non-twitter OAuth handlers.

Please suggest a better generic title that will aid discoverability.

[Mike-E-angelo]

How about: Additional Information around Authentication Middleware (/signin-google, /signin-twitter, etc.)

Otherwise, the comma was what was bothering me and it has been taken care of. 😁

[01binary]

@Rick-Anderson are you discussing this note being added?

The URI /signin-facebook is set as the default callback of the Facebook authentication provider. You can change the default callback URI while configuring the Facebook authentication middleware via the inherited RemoteAuthenticationOptions.CallbackPath property of the FacebookOptions class.

That sounds good to me. Sorry I haven't been back to ASP.NET ecosystem until now, hope these documents are useful and not too hard to maintain.

[Rick-Anderson]

@HaoK's comment

The authentication middleware takes care of routing requests back to the handler, see AuthenticationMiddleware.cs.

We'll just leave it in this issue for now.