Identity: ASP.NET Core Identity as a service

[danroth27]

Add a layer to ASP.NET Core Identity that exposes identity as a service.

This service should provide an opinionated and turn-key identity solution that enables customers to easily migrate to Azure AD B2C. The service should support flows for Web Apps and Web APIs as supported today by Azure AD B2C. Apps interact with the service using standardized protocols (OpenID Connect, OAuth 2.0, JSON Web Tokens) while abstracting the user from protocol details. Client token acquisition will be supported through the Microsoft Authentication Library (MSAL). The goal is to provide a consistent identity offering for in-app, on premise, and cloud scenarios.

Benefits of exposing ASP.NET Core Identity as a service:

• The actual app code is much simpler and decoupled from its identity concerns
• Support for established authentication standards and patterns simplifies security concerns and builds trust
• The identity service can live in a separate process
• Reuse user identities across multiple apps
• Support for issuing JWT tokens for Web API security
• Enable apps to easily migrate to use Azure AD B2C, or any other OpenID Connect provider
• Consistent client library story (MSAL) for acquiring tokens
• Consistent identity story across in-app, on premise, and cloud scenarios

Out of scope:

• Support for all OpenID Connect and OAuth 2.0 flows is not a goal. Supported flows will be limited to those supported by Azure AD B2C
• Other features not supported by Azure AD B2C are out of scope as they would impede migration

[brockallen]

When the title here says "service", do you mean an HTTP-based API on ASP.NET Identity, or is this issue just a general feature list for the already developed Azure on-prem STS as mentioned here: https://twitter.com/PinpointTownes/status/857772475400290306 and several times on the ASP.NET Community standup?

If it's an HTTP-based API on ASP.NET Identity, then I think this is a great feature! So many apps need decoupling from the in-memory only programming model of ASP.NET Identity.

If it's the on-prem STS, then in the past I've heard this positioned as "a STS where your client app can just change a URL and use any STS you want", but these two things:

• Client token acquisition will be supported through the Microsoft Authentication Library (MSAL).
• Other features not supported by Azure AD B2C are out of scope as they would impede migration

will make it product specific, and thus the client application code is also then tied to the Microsoft STS product(s). If this is publicized as the goal (and also the constraint), then fine. But if it's positioned as compatible with any other OIDC token service, then it will be misleading.

If the client apps (I guess in the templates) use client libraries that were OIDC RP certified (https://openid.net/certification/#RPs), then you'd have a more believable story for compatibility.

So can we get official clarification on some of these questions? I think it would help the community in evaluating their options.

[danroth27]

This is only about adding limited OpenID Connect support to ASP.NET Core Identity that aligns with Azure AD B2C, not adding a broader HTTP API over all of ASP.NET Core Identity. Client apps use the standard OpenID Connect and OAuth 2.0 flows for interacting with ASP.NET Core Identity.

[brockallen]

So in short, this "service" is a package that implements OIDC and uses ASP.NET Identity internally to manage the identities, and this OIDC server will behave exactly as Azure B2C?

Is that a fair one-liner summary?

[danroth27]

Yup, the goal here is to build an aligned identity story across in-app, on premise and cloud scenarios. We want to make it easy to migrate from ASP.NET Core Identity to using Azure AD B2C as a cloud identity service. That said, Azure AD B2C itself produces OIDC compliant messages and we will too, so you can just as easily decide to use any OIDC provider you want (like IdentityServer4, or OpenIdDict).

[brockallen]

That said, Azure AD B2C itself produces OIDC compliant messages and we will too, so you can just as easily decide to use any OIDC provider you want (like IdentityServer4, or OpenIdDict).

While technically correct (and this also includes any other OIDC implementation), each has their own programming model, assumptions, and features. So just because they all do OIDC, it doesn't mean they all do the same thing or provide the same features for you or your security architecture.

Yup, the goal here is to build an aligned identity story across in-app, on premise and cloud scenarios. We want to make it easy to migrate from ASP.NET Core Identity to using Azure AD B2C as a cloud identity service.

So yes, thanks -- I think this clarification is helpful so people can make an informed decision.

[kevinchalet]

Personally, the main concern I have is that the project names you've chosen are way too generic for what appears to be basically a limited "B2C emulator" (credits go to @leastprivilege for the name!) or an "on-premise B2C server". Why not adding the Azure(AD) moniker in the packages name if that's really what it is?

Another (cool) option to consider would be to decouple the OIDC handling part from the abstractions/core components (like the token primitives or the applications/tokens stores), that wouldn't be tied to any OIDC implementation and could be reused and plugged into existing stacks like IdSrv or ASOS.

[danroth27]

Yeah, we've considered putting B2C in the name to make this clearer, but then folks might think you're actually using B2C, when you're not using B2C at all.

We've definitely open to refactoring things so that they are more generally usable. Can you share more details on what factoring you'd like to see?

[brockallen]

Then call it B2C on-prem, or non-cloud B2C, or non-cloud Azure on-prem B2C or some such. If you give it a generic name, we'd not want people getting confused about what they were really getting. As we know, confusion on this platform is already at an all time high.

[danroth27]

We're open to this. We just need to come up with a name that signals alignment with B2C, but not usage of B2C. Will discuss more after BUILD is over.

[leastprivilege]

B2C Emulator - isn't that what it is?

[leastprivilege]

Refactoring doesnt make sense to me. We certainly wouldn't use it - and you are not building a framework.

In spirit this is a closed source product. I mean - it needs to mirror the exact feature set of a closed source product. So why even open sourcing it?

[danroth27]

In spirit this is a closed source product. I mean - it needs to mirror the exact feature set of a closed source product. So why even open sourcing it?

There is still value in making the code open source. By making the code open source you can read the code, debug it, build it yourself, incorporate it in your own projects, contribute bug fixes, fill in feature gaps, etc. Not all open source projects will have or need to have an open ended community driven scope. Some projects may have a fixed scope, even a scope tied to a particular business strategy or commercial product, and that should be ok.

[Bartmax]

The actual app code is much simpler and decoupled from its identity concerns

when you say much simpler you meant this?

[danroth27]

That's the identity code, which certainly isn't simple, but I was referring to the actual app code. The app code for most of our templates consists of a single HomeController with Index, About and Contact views. If you enable authentication today then a good chunk of the identity code gets intermingled with your app dwarfing the actual app logic. By separating out the app code into an area and wrapping it in a standard service interface your app and the identity code are decoupled to the point that you can delete the entire identity folder and replace it with an out of process identity provider of your choice.

We plan to simplify the identity code as well. All the code in the Extensions folders we plan to move into framework packages. We want to revisit how email confirmation and two factor auth get setup to make it simpler and purely additive (no more dummy IEmailSender and ISmsSender interfaces). We are also looking at ways to package the controllers and views so they don't have to live in the template.

[Bartmax]

@danroth27 thanks for the reply and eager to see the improvements coming. Btw, speaking of "We are also looking at ways to package the controllers and views so they don't have to live in the template." This is something that would be useful for a lot of scenarios! Whatever option you enable or recommend that we developers can use is very welcome. I was waiting for something to do exactly that for a looong looong time already.

[danroth27]

We might do something targeted for the identity controllers and views (still under discussion), but if you're looking for a more general purpose solution you should check out the sweet modules framework the Orchard folks built on top of ASP.NET Core for Orchard Core: https://channel9.msdn.com/Shows/On-NET/Sbastien-Ros-Modular-ASPNET-apps

[kevinchalet]

the sweet modules framework the Orchard folks built on top of ASP.NET Core for Orchard Core: https://channel9.msdn.com/Shows/On-NET/Sbastien-Ros-Modular-ASPNET-apps

There's even a built-in OpenID Connect module designed by @jersiovic (that uses OpenIddict under the hood) :trollface:

@danroth27 any idea when the IdentityService repo will go public?

[danroth27]

All the code for this feature will show up here in the Identity repo. We should have the first PR in place this week.

@javiercn @Eilon

[kevinchalet]

@danroth27 I started playing with the new VS templates and it looks like there's now no way to create a Web API/APP using Identity (aka "individual authentication") without the B2C emulator, which is of course a real PITA.

Is there a plan to fix that?

[danroth27]

What issues specifically are you running into? We want the app decoupled from its identity concerns by default so that you can easily swap to a different identity provider.

[Bartmax]

We might do something targeted for the identity controllers and views (still under discussion)

please don't and keep the discussion going.

With all the respect to Orchad and what they have implemented which indeed looks awesome. The need to reference two different packages, inject services, have a middleware running to get the concept of modules on an application may be fine but not to package a library with controller(s) and view(s). (As clearly is your scenario and many others).

I strongly believe this is something missing from asp.net framework, and I would love to see First Class Citizen support for this, the fact that you need this also kinda proves my beliefs.

[kevinchalet]

What issues specifically are you running into? We want the app decoupled from its identity concerns by default so that you can easily swap to a different identity provider.

That's also what I want. I don't want to have an embedded B2C emulator when I have actually no plan to use OIDC at all in my Identity-based app. There should be a new option the individual authentication dropdown list offering you to create a "local B2C server".

[danroth27]

@PinpointTownes We only plan to offer two options for authentication with individual user accounts: in-app or cloud. Having a third option would leave the user with a confusing choice. The use of OIDC for the in-app case has the benefit of allowing the user to easily swap out their identity provider and it is largely transparent to the user.

[danroth27]

@Bartmax Whatever we do for identity for the controllers and views we will make sure it's something that anyone can do.

[brockallen]

We only plan to offer two options for authentication with individual user accounts: in-app or cloud

In-app means the same as we have today in VS2017, right? Or if this only means you only allow the B2C emulator, then what about those projects that want to build their own STS using ASP.NET Identity?

[kevinchalet]

The use of OIDC for the in-app case has the benefit of allowing the user to easily swap out their identity provider and it is largely transparent to the user.

Meh. It makes absolutely no sense to use a local OIDC server when you know you don't want to use a remote identity provider. What I want is a template similar to the existing Identity template (in VS 2017).

[kevinchalet]

In-app means the same as we have today in VS2017, right?

Nope. When you select individual authentication with in app users store, the B2C emulator is automatically added and you have no way to avoid that.

[brockallen]

Nope. When you select individual authentication with in app users store, the B2C emulator is automatically added and you have no way to avoid that.

Well, then, that's wrong. This is like saying you'd force the MVC template to only run in Azure App Fabric.

[danroth27]

This is like saying you'd force the MVC template to only run in Azure App Fabric.

Not at all! The only thing the app is tied to is OpenID Connect (and a limited amount of OIDC at that). There is nothing in the template that is tied to B2C or any other Azure specific service. This means that you can easily switch to any OpenID Connect provider (like IdentityServer4 or OpenIdIDict). This setup allows for more choice, not less.

[brockallen]

But where's the ASP.NET Identity starter code? I guess I'm confused, and admittedly I have not installed any of the preview stuff yet.

[kevinchalet]

This means that you can easily switch to any OpenID Connect provider (like IdentityServer4 or OpenIdIDict).

There are many cases where you don't want to use an OIDC provider - local or remote. Embedding the B2C emulator, IdSrv, OpenIddict, ASOS or any other OIDC provider makes no sense when all you want is a simple application with cookies authentication and a local users database.

[danroth27]

@brockallen All we are doing here is adding a layer to ASP.NET Core Identity that wraps it in OIDC (specifically the flows that Azure AD B2C supports). We then put all the ASP.NET Core Identity code in an area in the template and the app interacts with it through OIDC. If you later decide that you want to use a different identity provider (Azure AD B2C, IdentityServer4, OpenIdDict, etc) you simply delete the entire area folder and configure the app's OIDC options to point at the identity provider of your choice. You can see this in action at the tail end of the Intro to ASP.NET Core 2.0 session at BUILD.

@PinpointTownes To be fair though, using ASP.NET Core Identity was never really simple. The AccountController alone is over 400 lines of code. And that code and the database setup is all still there, virtually unchanged. The addition of the OIDC endpoints was purely additive. We've tried to make the fact that you have a mini OIDC provider in-app as transparent as possible to the user. For many users it should be an implementation detail that we now do a standardized OIDC dance to setup the app cookie, instead of an app specific form post. If you think it's still causing unnecessary friction someplace let us know and we can try to address it.

[kevinchalet]

To be fair though, using ASP.NET Core Identity was never really simple. The AccountController alone is over 400 lines of code. And that code and the database setup is all still there, virtually unchanged.

So your solution to that is to add much more code in the templates - @Bartmax's screenshot is eloquent - making the authentication flow way more complex for people who only need local authentication and don't want to use OIDC? You can't be serious.

If you later decide that you want to use a different identity provider (Azure AD B2C, IdentityServer4, OpenIdDict, etc) you simply delete the entire area folder and configure the app's OIDC options to point at the identity provider of your choice.

I do understand why you're doing that from a business perspective, but forcing people to use your stuff by including it in the base templates without offering a way to opt in/out is unacceptable. What's next? Bloating all the templates with stuff promoting all the Azure services?

To be clear, I have no problem seeing stuff that help you sell more Azure services in the templates, but they must be opt-in. One should be able to create a new app with the minimum stuff needed, instead of having to remove everything manually.

[kevinchalet]

If you later decide that you want to use a different identity provider (Azure AD B2C, IdentityServer4, OpenIdDict, etc) you simply delete the entire area folder and configure the app's OIDC options to point at the identity provider of your choice.

Not really. Getting rid of the B2C emulator artifacts is way more annoying:

• You have to move the models/views/view models/controllers from the IdentityService area folder to the root project.
• You have to manually remove the area folder.
• You have to remove the related extensions in the Extensions folder.
• You have to merge the two AccountController.
• You have to rename and update the DbContext to avoid inheriting from IdentityServiceDbContext.
• You have to manually add the Identity services in the main Startup or copy them from the IdentityService hosting startup file.
• ... and I'm probably missing other steps.

[mcquiggd]

Just wanted to reinforce what I believe @PinpointTownes is asking at several points (please correct me if I am wrong):

A1. Scenario: I have already built my own system comprising IdentityServer / Openiddict. I use ASP.Net Identity exposed via my own UI / Web API. Or, I use it directly within my application.

A2. Desire: I want to treat ASP.Net Identity simply as a building block I can wrap with whatever interface, and persist in whatever storage medium I desire (I don't use SQL, I use DocumentDB). Or, not use it at all.

A3. Requirement: It needs to be completely standalone, opt-in only, and not be tied to a service interface that must mirror a closed source product. It must be able to be used in conjunction with data persisted in a jurisdiction of my choosing for compliance purposes. It must be extendable by the community.

Essentially, if ASP.Net Identity is no longer customisable / extendable with a fair probability that future releases are not going to break that, I cannot put my valuable user data into it, and I will create my own / use a truly open source alternative.

I am not trying to sound antagonistic, I just want to outline the typical scenarios for my own company and my clients. If we wanted to migrate a particular customer to B2C, we would achieve that by other means, and not require that all applications use an Identity product that is tied to it in case we want to use it in the future.

[cesher]

At this point in time the appeal of ASP.NET Core is that it is open source, cross-platform and friendly to startups and small application developers. Azure AD B2C on the other hand is not open source, has a tremendously slow release cycle, lacks many features (some of the more important ones are on private preview now, announced at build) and is incredibly expensive.

I'm sorry, but when you compare Azure AD B2C to something like say AWS Cognito, it is pretty clear that one of them is not targeted at the main market of ASP.NET Core. I understand, that this feature will allow anyone to go in and replace B2C with something else, and that's fine, but seeing as to how B2C is not a real viable option for so many at the moment, as stated before it should be an opt in.

Either an opt in, or AD B2C needs to become a compelling service that can justify its pricing with top notch features. But even then, AWS Cognito coming in at at least half the cost of B2C speaks miles about who they are really targeting as their customers.

[Bartmax]

This is not about which OIDC provider is chosen on the templates, pretty sure everyone agree that having B2C as default with a simple "replace point" it's perfect.

The point here is about when you don't want OIDC at all. That's why you have Windows Auth, cookies is just as good as any other option and every option is aimed to solve different scenarios. Current templates lacks the ability to have a cookies provider which is a very most common approach in MVC application.

[mcquiggd]

@Bartmax

This is not about which OIDC provider is chosen on the templates, pretty sure everyone agree that having B2C as default with a simple "replace point" it's perfect.

_Keep the current options and add another for Azure B2C for those that want to and can use it.
Keep the other templates free from cruft._

But, essentially as long as the actual Identity implementation retains the current level of extensibility and is self-contained without other dependencies / tied to the needs of a closed sourced SAAS interface, then I personally would be happy. I'll just create my own template and use that.

If it isn't, I would hope Brock would fire up MembershipReboot again and let the community rally round and contribute.

[PericlesSouza]

+1 for @brockallen continuing Membership Reboot.

We need options, choice of membership. Identity Server and OpenIddict are far more attractive than very expensive Azure B2C. It is just not commercially viable for many people.

[danroth27]

@PericlesSouza We completely agree! This feature adds OpenID Connect support ASP.NET Core Identity in a way that aligns with Azure AD B2C, but it doesn't use or rely on or use Azure AD B2C at all. By using OpenID Connect you can then easily update your app to use any identity provider you want, including IdentityServer or OpenIdDict. You have complete control over which identity provider you use.

[danroth27]

@mcquiggd

But, essentially as long as the actual Identity implementation retains the current level of extensibility and is self-contained without other dependencies / tied to the needs of a closed sourced SAAS interface, then I personally would be happy. I'll just create my own template and use that.

Yup, no extensibility was removed by adding this feature and no dependency was introduced on Azure. We are simply adding OIDC support in a way that makes it easily to migrate to our Azure identity services or any OpenID Connect provider that you want. For folks that don't want OIDC support at all you can still use ASP.NET Core Identity to do forms based cookie authentication like you always have been able to do.

[kevinchalet]

For folks that don't want OIDC support at all you can still use ASP.NET Core Identity to do forms based cookie authentication like you always have been able to do.

Not without having to manually remove your "identity service" thingy from the default templates. And it's a total PITA: https://github.com/aspnet/Identity/issues/1187#issuecomment-301136216

[danroth27]

We want to make the OIDC support as transparent as possible to the point where, for most users, it should be an implementation detail. We can also improve the template so that removing the OIDC stuff is more painless for folks that want that (ex. we're already in the process of removing of all the code in the temporary Extensions folders).

[kevinchalet]

We want to make the OIDC support as transparent as possible.

It really sounds like you're trying to force people to use your OIDC server (otherwise you'd accept offering a default template without any OIDC stuff, just like in VS2015/2017).

[danroth27]

It really sounds like you're trying to force people to use your OIDC server

We're really not trying to force anyone to do anything. We're trying to decouple apps from ASP.NET Core Identity so that you can choose whatever identity provider you want. We're doing this by wrapping ASP.NET Core Identity in standards complaint service endpoints. By decoupling identity from the app in this way you can then switch to whatever OpenID Connect provider you want whenever you want to. If you don't want the OIDC endpoints at all you can remove them, but we think most customers will want this level of flexibility.

[kevinchalet]

If you don't want the OIDC endpoints at all you can remove them, but we think most customers will want this level of flexibility.

If you're so sure people will want that, why not offering a way to opt out (using a checkbox?) for those who don't want to use OIDC? :smile:

[ketrex2]

We're really not trying to force anyone to do anything. We're trying to decouple apps from ASP.NET Core Identity so that you can choose whatever identity provider you want.

This seems disingenuous when you describe the issue you're trying to solve as:

This service should provide an opinionated and turn-key identity solution that enables customers to easily migrate to Azure AD B2C.

This doesn't imply flexibility in the Identity service as the goal, but rather, a push/promotion for Azure AD B2C. It definitely flies in the face of the open and composable goals of ASP.NET Core up to this point.

[danroth27]

@ketrex I can understand how that statement was a bit confusing, so I've updated the issue description to say "easily migrate to Azure AD B2C, or any other OpenID Connect provider". Obviously we would love for you to use our Azure services, but there is nothing that constrains you to do so. Use whatever provider you'd like.

[Ponant]

@danroth27 , what is difficult is that the user needs to decrypt the code to understand it. The template in ASP.NET 2.0 Preview 1 shown above is too abstract, which is the price to pay for the decoupling you mention. While I think the idea is nice, it would help to point to a short tuto that goes through the code (a 20 min video would be best perhaps as this is a preview). Cheers

[danroth27]

@Ponant Absolutely! You can see the template in action at the end of the Introducing ASP.NET Core 2.0 BUILD talk, but we will work on putting together a more complete walkthrough in the weeks ahead as the template code settles.

[Ponant]

@danroth27 , I saw this video a few days ago but that was not enough for me except in getting a general idea. The problem with abstraction is that you lose the basics of understanding code, namely follow a method which calls another method etc (I may be too old for that ;) ). I would rather go for something like Adam Tulliper did once https://mva.microsoft.com/en-US/training-courses/customizing-aspnet-authentication-with-identity-8647?l=1Yef8hF1_7604984382, but in a short version until you clean up the code. After that, people will adopt it in my opinion because you offer a better separation of concern.

[danroth27]

@Ponant Yup, totally agree. I'll shoot for getting something out by early June.

[danroth27]

The initial code for this feature is now checked in, so I'm going to go ahead and close this issue. However, please feel free to continue to comment if you have further questions. Even better, give the ASP.NET Core 2.0 Preview 1 bits a spin and let us know what you think!

[PericlesSouza]

So after all these comments, the only change is the words describing what you have done. But what we _get_ is still the original intent.

This service should provide an opinionated and turn-key identity solution that enables customers to easily migrate to Azure AD B2C.

There was not much point in allowing discussion if you do not listen. This is the biggest problem with all Microsofts "open source" efforts. e.g. project.json vs .csproj. It is a waste of time discussing these choices when the decisions have already been made in an office at Microsoft.

If you want people to use your B2C product, lower its price to something less _insane_. Herding customers into using it by making other options painful will not work. People will just leave your stack to somewhere where they do not get their arms twisted by the vendor i.e. _real_ open source.

[luisgizirian]

With a separation as a Service, it seems to me that more complex scenarios are getting into the Identity equation. So, I ask again if support on Mutitenancy (TenantId into AspNetUsers table) is still out of reach. Please refer to #1047 & #266.

SaaS apps were neither AzureAD nor IdentityServer are a fit, would greatly benefit of this construct right from the library itself.

Thanks!
Luis

[danroth27]

@PericlesSouza It certainly wasn't the intent to ignore any feedback. We've been monitoring this issue closely and I've opened the following issues to track the feedback we've heard. If I missed something please do let me know:

• Consider renaming the packages to make clear the alignment with Azure AD B2C. We are open to this, but we want to avoid causing confusion where people think these components have a dependency on B2C, when they don't (https://github.com/aspnet/Identity/issues/1198)
• Reduce the complexity of the template additions that support OIDC as much as possible (https://github.com/aspnet/Security/issues/1212, https://github.com/aspnet/Identity/issues/1199, https://github.com/aspnet/Identity/issues/1201)
• Consider adding a template option that only adds cookie auth without the OIDC pieces (https://github.com/dotnet/templating/issues/800)
• Provide a way to ship controllers and views as a binary/package (https://github.com/aspnet/Home/issues/2030)

Your specific feedback has been about not forcing folks to use Azure AD B2C, which this feature does not do. It sounds like you are particularly interested in preserving choice of identity provider, which is exactly what this feature is about. This feature decouples your app from ASP.NET Core Identity making it easy to switch to IdentityServer, OpenIdDict or any OIDC provider you want.

[danroth27]

@luisgizirian Unfortunately, I don't believe we have any new plans around multitenancy. However, the Orchard folks have been hard at work on Orchard Core and they have multitenancy support built-in.

[luisgizirian]

@danroth27 That's a deal-breaker for us.

We're a proprietary SaaS platform supporting multiple websites for our customers . We're stuck into ASP.NET Identity v.2 (with multi-tenancy addition). We have already +50K users among our tenants (sites with customers of our customers). We shall decouple from v.2 Identity (while keeping existing passwords) to allow our code base to evolve an be upgraded to .NET Core.

We operate on top of Azure using a combination of IaaS, SDN, PaaS, and several Azure services (Microsoft offered and 3rd Parties as well thru Marketplace) over multiple DCs.

It's a big deal to us the negative on moving on with multitenancy for ASP.NET Identity Core, but I hope it is for the best somehow. At first look, Orchard Core is not in our best interest as its a big tradeoff with a steeper learning curve that deviate us from our core.

[jersiovic]

@luisgizirian I don't think @danroth27 would mean you should move to OrchardCore, simply that you can look on it to see how multitenancy was solved to bring ideas to your platform. So, instead of forcing others to have a tenant id in user table that maybe we don't want to use, you could adapt to what exists using
a different user table per tenant.

[Bartmax]

This feature decouples your app from ASP.NET Core Identity making it easy to switch to IdentityServer, OpenIdDict or any OIDC provider you want.

What a lie, created a new project and tried to swap to another provider... it's just imposible.
After that I did create new blank app, and got auth stuff done in like 15 minutes.

@danroth27 The definition of the word easy that you use in every comment on this issue is not what you think it is.

Even better, give the ASP.NET Core 2.0 Preview 1 bits a spin and let us know what you think!

As sincere as possible, I think the new auth template it's useless/confusing/complex (at least for me), it also doesn't work right (neither the former template so was no surprise) and I have no plan to invest anymore time on it or this issue.

What I get from this and the many times that I tried to contribute to the way authentication is done, point out defects on the templates, etc. is that I just need to forget that Microsoft has any authentication "stuff" and move on. 😫

[danroth27]

@Bartmax It's certainly not impossible. If it helps, take a look at my IdentitySwap sample that's preconfigured to allow you to swap between local ASP.NET Core Identity, Azure AD B2C, and IdentityServer4 for sign in by changing a single line of code. This is the same demo app I used at BUILD. There's certainly plenty of room for improvement (it's only preview1), but hopefully it gives the idea of what we're trying to enable.

I can tell your frustrated (sounds like there's some history here), but if you'd be willing to share where you ran into issues I'd love to hear what they were. You're probably one of the first people to try out the new templates, and we greatly appreciate the early feedback.

[minhnhat2807]

@danroth27 Where can I change grant_types_supported because when I looked at this link xxx/v2.0/.well-known/openid-configuration it's always empty

I tried to use ASP.NET Core Identity for issue token to user, how?

[danroth27]

@minhnhat2807 Please note that we recently made a decision to postpone the identity as a service work until after 2.0 so that it has more time to bake.

The configuration document is provided by the IdentityServiceConfigurationController in the template. See https://github.com/aspnet/Identity/blob/dev/samples/IdentityOIDCWebApplicationSample/Areas/IdentityService/Controllers/IdentityServiceConfigurationController.cs#L23 for the latest implementation of this endpoint. Note that the route for this endpoint is [HttpGet("tfp/IdentityService/signinsignup/v2.0/.well-known/openid-configuration")] to match the behavior of Azure AD B2C.

[PericlesSouza]

Typical of how .Net Core is mismanaged.

Make a decision to go off on a tangent that nobody asked for (while ignoring the most wanted features), and then swerve to another direction at the last moment.

You guys need to be managed by the folks that carefully husband the C# language. They know what they are doing.

[gregoryagu]

@danroth27 So what does this mean? Will it have to wait until aspnetcore 3.0? Or will it get released as part of an update to 2.0?

[kevinchalet]

@gregoryagu

The following items (and items related to them) were cut completely from the 2.0.0 release due to them being deemed not ready. We will revisit them in 2.1:

• Convention-based configuration in our sub-systems (aspnet/MetaPackages#117)
• Identity as a Service (STS)

https://github.com/aspnet/Announcements/issues/253

[chassq]

In general the identity xp over the years has been a tumultuous one (e.g. ASP Role/Membership, Identity, AD Integration, OWIN OAuth, etc..) It has kind of bounced us all over the place and caused a good bit of complexity and time consuming R&D. I hope this implementation ultimately comes down to making it easier for us not more complex! I want to spend more time thinking about my business requirement implementations than an Identity framework. Its not only the code to implement but also maintenance and longevity too!

For our Web Apps and APIs we are looking at Identity Server 4 for a unified solution. IDS 4 looks great but just seems more than we need/want. We were also are looking at Azure AD B2C but when you factor in user storage, authentication and Multi-Factor the cost becomes far too big for a small startup.

I guess we would like to see this be a seamless very low friction implementation to a low cost backend service that does what Azure B2C does (or here is an idea. MAKE AZURE B2C CHEAPER! :-)). Love the idea of having a unified identity service for our APIs and Web Apps but please make this as low friction as possible. Also please do something MS will stick with for years to come, if possible! Otherwise it is really very little help.

My $.02....

[mcquiggd]

@chassq

I agree with your points regarding the 'identity journey' we have had over the last few iterations. Also agree with the cost of Azure B2C

IDS4 is actually a very good attempt at making a highly complex subject, easy to use. The samples and documentation are thorough, and its essential to understand the concepts behind the industry standards it employs, whatever backend you choose, in order to properly secure your applications.

My experience so far with IDS4 has been very good - flexible, efficient and scalable. The initial investment will pay dividends.

[Eilon]

One of the goals here is to at least standardize on the OpenID Connect (OIDC) protocol. That makes it a lot easier to swap out the back end. If you started with one backend and need to switch to another, you still have to figure out how to migrate your data (that's nearly always true anyway), but at least the app's frontend shouldn't need to change.

[gregoryagu]

@mcquiggd, @chassq I looked at the current cost of AzureB2C. For less than 1,000,000 users, the cost works out to 18 cents per month based on 50 logins per month ($0.0028 each login), plus 1.1 cents per user per month. Add in Multi-Factor auth at once per month at 3 cents each.

That seems pretty reasonable pricing to me.

Am I missing something?

[gregoryagu]

I watched @danroth27 build demo of Identity As A service and it seems pretty cool to me. Is there a way to get the bits for this so I can give it a spin?

[chassq]

The azure price calculator (see https://azure.microsoft.com/en-us/pricing/calculator/ ) has 1 million stored users at $1,045.00/Mo. Add 1 million authentications = $2,660.00/mo. Add 10,000 multi-factor = $300/mo for a total of $4,005.00/mo. So please tell me what I have wrong here. Am I not using the calculator correctly?

[gregoryagu]

Your calculations comes to one half cent per user, per month. If it's a totally free app with several million users, I can see the case for rolling your own auth. But that seems pretty reasonable to me for a paid app.

[chassq]

Yep. If they drop the price they could gain more adoption and become a defacto for Identity. And make it far easier on the dev community by having one place to turn for Identity. Just look at the costs for Azure Functions. An execution is next to nothing by comparison. Why is Identity so expensive? A stored user cannot take that much disk space and an authorization should be on par time and resource wise as an Azure Function call. You can get 10 million Azure function executions (assuming under 1 sec and less than 128kb) for $13.60/month. Azure AD B2C just seems way over priced to me as compared to other Azure cloud services.

[mcquiggd]

You will always have considerably more Azure B2C _authentications_ than 1 per user per month, even if a proportion of your users are using a third party such as Facebook, with long-lived access tokens. Refresh tokens could kill you if you are not careful. Not requiring people to periodically re-authenticate is fraught with problems.

When going B2C, you have to allow for cost to rapidly increase, and switching identity providers means downtime / risk. Iv'e contracted for several startups that went under because they were popular, but they hadn't planned the cash flow / cash burn, while building a potential customer base.

Compare the above cost estimated by @chassq - $4,005.00/month. (thanks for that) which assumes the very low active authentication rate of 1 per month.

Hosting my own IdentityServer on an auto-scaled App Service, Standard Level, even with _3 permanently running S1_ instances that never auto-scale down during quiet periods, will cost me an initial $223 per month (database costs added below), and can easily handle the same load and scale to peak demand. In practice it would be less due to auto scale down.

Combining that with Cosmos DB (DocumentDB) using:
10GB of SSD based storage (that's a whole lot of user profiles).
4000 Request Units per second, 744 hours each month. Thats about 2000 authentication requests per
second.
And just for the hell of it, an additional 40,000 Request Units per minute provisioned throughput, 744
hours each month.

$320.57

So, total cost $543.57. And capable of dealing with 10s of millions of user profiles, and 100s of millions of authentications each month. Double that price if you want Geographic Region Failover. Still considerably more performance for a quarter of the cost.

With the spare $3000 per month you can add as many regions, load balancers, traffic managers as you want. Or load it into a Redis cluster with the CosmosDB for permanent storage.

Azure B2C for 1 million user accounts (which is not much for B2C), and only 5 authentications (and don't forget those refresh tokens - each is another chargeable 'authentication') per user, per month, is $12,105.00.

$145,000 a year _for logging in_ might be lost amongst all the other costs. For me its not acceptable. And you still wouldn't be able to login at your own domain name.

If users choose login with username and password as they want to use their password managers... oh dear!

eCommerce - start adding up those multi-factor authentications ... boom.

Seriously, feel free to spend more than you need to if you wish; perhaps you have a high margin product, and no investors wanting to minimise your spending of their money.

Every cost adds up and eats into profitability; especially during the growth phase of a startup.

[Bartmax]

Just to be clear, Auth0 is kind-of the same stupid 💸 pricing model.
When one player enters the market and takes all the developers don't 😢 and said we didn't warn you.

I wish I could use xxxx (insert name Azure, Auth0, whatever) for identity.
As of right now, we are strongly suggesting all our customers/clients to roll their own login mechanism. With libraries like open iddict I really don't see much value added from Auth0 nor Azure and the pricing is insane, IN-SANE

[benaadams]

@chassq multi-factor is sms based; which has a 3rd party cost per auth. You are better using the authenticator app version for 2fa that's in 2.0 (also advised to use it instead of sms based 2fa as per current security advice) so that shouldn't be a cost worth worrying about?

[Ponant]

@danroth27 , any idea on when Identity as a Service will come up now that it is removed from 2.0?
Is it expected for 2.1?

[danroth27]

It's being actively developed, but when it will ship is still TBD.

[gregoryagu]

@danroth27 Can I beta test it for you?

[danroth27]

There's no beta to test yet. It's still very much a work in progress.

[brockallen]

There's no beta to test yet. It's still very much a work in progress.

Turns out that building a token service is a lot of work :)

[mcquiggd]

@brockallen

That's why I admire the people that open-source theirs...

[brockallen]

That's why I admire the people that open-source theirs...

Well, OSS is not free and not typically a charity. You have to evaluate the motivations of those that do. Ours is to sell consulting and services. Microsoft's is to sell Azure.

[mcquiggd]

@brockallen

The difference being I can use your OSS without paying for the _optional_ consultancy... and assess the quality of it's implementation, compare it to OpenIddict for example. I can also submit fixes.

You put it all out there for everyone to look at, if you pardon the expression...

[brockallen]

Sure, but Microsoft will (if not already) OSS theirs.

The most important thing, which you've somewhat gotten at, is what's the right token server for you. If you plan to use and move to Azure B2C, then I suspect the Microsoft one will be the right choice. But if you're not sure, or you need more features or flexibility than Azure B2C, then the Microsoft token server will probably not be the right choice for you.

I hope Microsoft has the courage and honesty to be very clear on this point as they move forward promoting their token server. They have a huge amount of power and influence in what developers hear and think (regardless if the info is correct or not) in their marketing and in things like the File->NewProject experience.

[Ponant]

@brockallen , in what do you want MS to be clear on and how can you know what they are doing in the details? I know there are lots of discussions on this topic and surely they are not the most glorifying ones, but my point is that if you are concerned about their implementation then why not explaining what are those limitations of their future OSS. Otherwise it is perceived as a negative critic for free not mentioning a biased one.

[brockallen]

@Ponant I thought I was clear... the Microsoft token service (from their own words if you piece enough of it together) is designed for eventually moving your users and token service to be hosted in Azure B2C. It's not a more general purpose or flexible token server. That's all.

What I'm trying to protect against if when people are told half-truths and manipulated in order to sell a product that's not appropriate for their needs. I'm not saying Microsoft has done this in regard to their new token service, but I have seen it done elsewhere for other products in other scenarios. So I'm just trying to keep Microsoft honest about what they are building and what it does.

[Ponant]

While I considered using AB2C, I decided not to do it (priced too high and lack of customization and unclear data sovereignty rules). You may be right but I understood their answers differently, quoting parts from @danroth27 and @Eilon ,

Enable apps to easily migrate to use Azure AD B2C, or any other OpenID Connect provider

We're really not trying to force anyone to do anything. We're trying to decouple apps from ASP.NET Core Identity so that you can choose whatever identity provider you want. We're doing this by wrapping ASP.NET Core Identity in standards complaint service endpoints. By decoupling identity from the app in this way you can then switch to whatever OpenID Connect provider you want whenever you want to. If you don't want the OIDC endpoints at all you can remove them, but we think most customers will want this level of flexibility.

One of the goals here is to at least standardize on the OpenID Connect (OIDC) protocol. That makes it a lot easier to swap out the back end. If you started with one backend and need to switch to another, you still have to figure out how to migrate your data (that's nearly always true anyway), but at least the app's frontend shouldn't need to change.

I think what they are doing is an invariant OIDC-compliant protocol, I recall Dan made this demo
https://github.com/danroth27/ProjectConstruction/tree/master/IdentitySwap

[brockallen]

I think what you are referring to is the MVC/ASP.NET Identity templates that consume an OIDC token service, which is separate from the token service itself that is being provided as the migration path to Azure B2C.

And I think, in a sense, your slight confusion has illustrated the exact concern I'm trying to raise. By blurring the distinction between the consuming app and the token service itself (or another way to look at it is by failing to explain with extreme clarity the distinction between the two), it's easy to fall into the situation where File->New Project has led you into being spoon fed a token service whose design is to funnel you into Azure B2C, unbeknownst to the developer. That's the power of owning VS and the File->New Project message that is delivered to developers. Most folks don't know any better that this is not the right choice for them or their companies or projects. For many it is, but again, if it's the only choice how would a developer differentiate?

IMO, those should be two different project templates. But that doesn't demo well on stage at conferences and during keynotes.

[Bartmax]

@Ponant :
@brockallen asking/saying/hoping that ms will be clear in their strategy is not for free, MS wasn't clear and _lied_ in the past about this.

bonus: my opinion shouldn't _feel_ biased.

[chassq]

IMHO,

1) MS needs to lower the cost of Azure B2C drastically and make it along the lines of the cost of say a storage account (store users) + a function execution (per auth) + email/sms call (optional for multi-fac) + AD/365 Integration (optional). If they did that then AD B2C becomes a more viable option for what is really needed and there is no more feeling that they are leading us into overpaying for something that should be a cloud commodity. AD B2C is not a commodity today at its current cost.

2) Keep the identity programming model simple as possible. Today ASP NET Identity is just to disjointed with crap you have to think about (e.g. RoleStore, UserStore, UserManager, TokenStore, ClaimsStore, PasswordHasher, SecurityStamp, etc.. etc.. etc...). Put on top of that the lackluster docs on how to set that stuff up and override it and bad method design (e.g. VerifyUserTokenAsync returns a bool when it should return an object which specifies at least success or not and if not gives an error message) and you get a framework people begin to dread to use.

I guess my point is that if identity is going to be made so hard to deal with that many developers will simply not use it and opt for a "home grown" path of least resistance solution which could have major security problems. I personally have seen this time and again in code for which I have had to take responsibility.

If we can make identity streamlined and simple more people will use it and hopefully more applications will be safer for it. Don't just think big tech company with tons of resources to field a dedicated dev security team. Think startup/small/medium/big business that is not led by technical people and do not know how to run their company as a tech company but want a technology based product. I know that sounds crazy but I see it all the time. They don't give devs the time and resources to do the right thing. So making identity one thing they can count on not to be a time/maintenance suck really helps!

3) I totally agree in keeping the identity and backing store separate but out of the gate there should be an easy path or 2 for the new folks so that they do not have to put to much time and effort into getting a great secure auth/auth framework setup and implemented.

I am not trying to advocate for MS but they are in a unique position to make this happen for a great number of people and make our eco-system safer. Just want them to do the right thing.

Hope that input makes some sense.... Sorry, I rambled.... Sorry so long....

[brockallen]

I guess my point is that if identity is going to be made so hard to deal with that many developers will simply not use it and opt for a "home grown" path of least resistance solution which could have major security problems.

The problem is that identity is just as much a business feature as anything else, while also concerning security. The reason IdentityServer is so popular is that because identity is not something you can productize as a cloud hosted SaaS offering and control and customize. IdentityServer does take care of the security stuff, while designed to allow the developer to do the customization they need. So it's an option for you instead of doing a "home grown" solution.

[chassq]

Hey @brockallen ,

I guess its perspective. I think I was more talking about implementation than security in general. Agreed security is part of requirements. But I see ASP NET Identity/IDS4 today as a frameworks a dev can employ, not quite like custom business specific logic to meet a set of consumer feature requirements. Much like we put custom logic in using frameworks (e.g. EF Core is to data access as Identity is to auth/auth).

Trying to be pragmatic I find most decision makers do not think like I do when it comes to this stuff. They just assign value to consumer features that they can see and take for granted the ones they cannot (e.g. security) until its too late. So making the identity implementation more straightforward without a bunch of ceremony makes for a far better story to your boss and dev team. For example, app security will take us 4 hrs vs. 4 days of coding and testing. My thoughts are not necessarily about one implementation vs another I guess just more about the need for more straight forward identity implementations that are easy to follow, put in place and transfer to other devs on a team.

[brockallen]

From the client app perspective, I think you're right and that can be achieved in the templates or just by adding the AddOpenIdConnect authentication handler into DI. It's minimal code, so in a sense, there's already not much ceremony to it.

[Ponant]

Well, then it is maybe a good time to sell IdentityServer to MS :) Cheers

[Bartmax]

@Ponant it's free...

[Ponant]

@Bartmax , their expertise is not for free and valuable. Anyway, that was a (half) joke to stop turning in circles until MS clarifies or outputs a "template".