Glad you like them!

I am glad it was helpful.

Glad it was helpful!

You are welcome.

Thank you!

Thanks!

Same here.... not an option to 3rd party this. 27 year backend vet here. Seen too much crap in that time. Oauth2 all the way, always.

I usually like Tim's videos, but the title of this video is inaccurate. This was just him imploring us to not implement our own 50x in a row. Cool thanks, now what are the differences between OAuth 2.0 authentication types?

You are welcome.

You are welcome.

Thanks!

I believe this is what you are looking for: azure.microsoft.com/en-us/pricing/details/graph-data-connect/

Thank you!

That would be a third-party system. A good choice, too.

But isn't it not maintained anymore?

My B2C course does cover how to set it up and use it. My Suggestion App course (free here on UKposts as well as paid) also shows you how to integrate B2C into a Blazor Server app.

@@IAmTimCorey Thanks! I'll check out the Suggestion App Course, as well as the B2C Course, I could do with a through coverage of the details. Boss has ok'd the time :)

Thanks for sharing!

That could be any number of authentication systems. Working offline is something that C# handles.

This is an answer to a question on the suggestion site. No telepathy needed.

You are welcome.

Either will do great, but I like B2C because it gives you 50,000 MAUs for free. That's a LOT, especially for a startup. Auth0 provides 7,500 MAUs for free. That difference can be a big deal when you are starting out. Once you hit the 50,000 MAUs, you should have a good revenue stream going to pay for those users.

Great!

I really like Azure Active Directory B2C. I use it for the suggestion site ( suggestions.iamtimcorey.com ) and I've rolled it out to a number of other internal sites as well. I've never paid a dime for it because I've never hit the 50,000 active users per month tipping point. It is really simple to implement and once it is running, it all just works. I created a course on how to implement it: www.iamtimcorey.com/courses/azure-active-directory-b2c-from-start-to-finish/ I also published all of the videos for how I built the Suggestion App here on UKposts for free: ukposts.info/slow/PLLWMQd6PeGY0cZFMqx5ijmdaD87sJKCsU

@@IAmTimCorey Thanks for the reply, I will definitely try B2C. Also, I really appreciate all the content on this channel!

@@IAmTimCorey Hi Tim I love your videos they are really helpful, thank you very much, A quick question, when you say internal sites, Does it mean We can use b2c to give users access to a site(web app) that, although it is in the cloud, is not for the general public and is intended only for use within a company?

Thanks for the suggestion. Please add it to the list on the suggestion site so others can vote on it as well: suggestions.iamtimcorey.com/

What do you usually do if you are told that all the good options are unavailable for you to use for some reason or other? I'm guessing they're past jobs for a reason.

A lack of money is no excuse for exposing your customers to a data breach. Besides, most authentication systems have a free tier to get you started. If your “business” cannot afford authentication by the time they are past the free tier, they aren’t a business. Business has to charge more than the cost of doing business. If a business says that they cannot afford to pay for an application, then they cannot afford to have that application. It is as simple as that. If they cannot afford a facility, they don’t just get to get one for free. If they can’t afford to buy supplies, they don’t just get them for free. If a bank couldn’t afford a vault, they wouldn’t be allowed to store your money in a shoebox. As for the fact that you built your own and “did not have any problems with it”, the problem is that you exposed your customers to harm. That is absolutely a problem. Just because something works doesn’t make it right. Did you have an external form do penetration testing? Did you constantly monitor updates from .NET and third party vendors to be sure that a bug wouldn’t lead to a vulnerability in your software? Did you ensure that the passwords used were one-way encrypted? Did you offer two-factor authentication? Just because you can validate a user doesn’t mean you can make them safe. Even if what you are protecting is inconsequential, people tend to reuse passwords. If your system gets hacked, you could be exposing them to being hacked in a lot more locations.

I played in traffic twice and didn't get hit by a car.... therefore playing in traffic is probably fine.

So as a question… how many of these 3rd party social system log the time, location, software etc information and sell it on or use it as data points?

Social system logins provide eula for their users. If you give them a few options, they can pick the company that they feel comfortable working with. If you don't want your user's login metadata used in some advertising system, pay money to host an active directory server privately somewhere and use that. There are probably n-1 providers that use the data in a way you don't like, so use the nth provider.

I am glad it was helpful.

I am glad it was helpful.

Not having authentication is a nice solution when you can do it, but it isn't a common occurrence.

Not yet. Please add it to the list on the suggestion site so others can vote on it as well: suggestions.iamtimcorey.com/

@@IAmTimCorey will do!

Nope. You can host it anywhere.

Great video... This is an area that is a bit mysterious to me and it was good to know where to start.

I am glad it was helpful.

Thanks for sharing.

Thanks!

That is spectacularly bad advice. It sounds great - own your own destiny by controlling the source. However, as soon as you start relying on your own auth system, even one from an open source base, you are now responsible for every line of code. You need to validate that the system is resistant to hacking, bugs, etc. You need to be doing regular penetration testing. You need to be monitoring for 0-day exploits on systems that your system is built upon. You need to keep up with every change from every vendor throughout your stack (browsers, devices, underlying packages, etc.) to be sure that they don't change how something works in a way that will negatively impact your authentication system. These companies spend hundreds of thousands of dollars on maintaining their authentication systems each year. You want to take all of that on yourself? That's a bad call. The only way you save money here is if you cut corners. Cutting corners is not the way to protect your customers.

@@IAmTimCorey yes, that's why I said if you have the budget. Trust me, no system is safe :)

This is good advice from someone with experience, instead of from a "trend-follower" with a youtube channel that goes on repeating mindlessly and without real arguments and lots of FUD exactly what the big industry players want you to think. Finally a thinking person in the comments.

@@IAmTimCorey MY UNDERLYING PACKAGE IS "IF". BEAT THAT. STOP THE FUD YOU SCAREMONGER.

@@IAmTimCorey "These companies spend hundreds of thousands of dollars on maintaining their authentication systems each year. " LOL you are SO NAIVE, dude! I can't even... Seriously. No company is spending thousands of dollars on making your clients safe, they are spending it on making themselves profitable. Only you have the true interest of keeping your clients safe therefore if you delegate that to others you have betrayed your clients.

Yep, that's always safe. But forget putting them at home. Bury them in the backyard. Maybe make a little map to them with a big, red x that marks where they are located.

​@@IAmTimCorey I can tell you for sure that the data protection using shepherd dogs at home is underrated compared to the cloud-based OAuth, and even compared to the backyard protection, which is vulnerable to mole attacks. p.s. Thanks for your tutorials, especially about logging!

Security isn't free. If you have customers, you should expect to have to pay something. Free is great, but it probably isn't a great option for your authentication unless you are growing towards a paid plan.

I'm not sure what you are disagreeing with.

@@IAmTimCorey with what you said at 14:46 and 14:59 for the reasons I wrote in my first comment.

I'm not sure what you are referring to.

Huh? Are you arguing that coding your own auth system is a good idea? Please tell me that's not what you are arguing. Of all of the "it depends" topics you could pick, that's not one of them. Here are just a few people telling you the same thing: * withblue.ink/2020/04/08/stop-writing-your-own-user-authentication-code.html * simplelogin.io/blog/do-not-create-own-auth-system/ * dev.to/jordanfinners/make-one-resolution-this-year-never-write-your-own-authentication-3nc1 Even if it wasn't extremely dangerous (and it is), why would you do it? There are companies that spend millions of dollars per year maintaining authentication systems that are really good options that also have free tiers to start out with (Azure AD B2C, Auth0, etc.) Why spend an enormous amount of time to do something that has already been done much more cheaply than you can do? And I reject any argument that includes the "I can do it faster/cheaper". The only way that argument works is if you cut corners and if you also don't continually update it for new security threats.

@@IAmTimCorey Yes, I am arguing that coding my own auth system is a good idea. It is interesting and very telling that instead of simply saying out loud the "killer argument" against my position, you instead have to appeal to authority and get 3 people against me. I remember Einstein once said to a letter signed by 1,000 scientists denouncing his findings, that if he were wrong, only one scientist would suffice. Anyways, I can argue my position very simply and clearly. Authorization is nothing but: - loading from a database a list of which permissions each user has; - doing an "if" on those permissions on each endpoint to see if it is okay to load that endpoint normally. That is absolutely all there is to it. Not everything needs to be a library. In the case of authorization, doing it yourself is better. Authorization is too simple (just "if's" over "permissions" which are nothing but unique strings associated to users's foreign keys on the database) to have to be abstracted over. And even after you have abstracted over authorization in C# with its standard offering library, you still end up having to writing an "if" on each endpoint (or on the middleware, depending on your access granularity) to ask whether the user has the required permissions; which means that, in trying to run away from simply doing what you cannot avoid, you adopted a whole bunch of boilerplate code from Microsoft that is nothing but an opaque layer over what should be simple business logic. What exactly is dangerous about my approach? Please answer with a "killer example". Again, my approach is something that you inevitably have to do with your approach as I just described above - nothing can spare you from doing an "if" on each endpoint (again, depending on granularity) over the user's permissions, so why not just do that and avoid the entire scenic route? "There are companies that spend millions of dollars per year maintaining authentication systems that are really good options that also have free tiers to start out with (Azure AD B2C, Auth0, etc.)" Yes, and they are the number one group of people invested in propagating an FUD narrative for their fans and clients to repeat. Again, you are not saying anything with substance. I am yet to see a "dangerous" example of a custom-implemented authorization system. It is just "if's" after all. "Why spend an enormous amount of time to do something that has already been done much more cheaply than you can do?" Because it takes me longer to (1) learn and then (2) maintain in the long term with (3) changing versions the (4) work of other people, who are usually (5) forced by their clients to shove too much functionality into a library that should be simple. Just look at the authorization videos on UKposts for the standard ASP.NET Core offering library, they're so long. Folks, it's just "if's" over unique strings that mean different permissions associated with the user. Nothing more than that. Please, let's stop complicating things unnecessarily just because of fear. "And I reject any argument that includes the "I can do it faster/cheaper". " Again, what I am saying I "can do" is simply the part that you are also forced to do: namely, to do an "if" on the permissions ("Claims") you've loaded from your favorite ASP.NET Auth library. The time I save is from having to learn an entire library around this simple "if" operation, which I consider unnecessary, but I can see how it can act as a safety blanket for people who are quick to believe the marketing narratives put out by service providers. "The only way that argument works is if you cut corners and if you also don't continually update it for new security threats." There are no security threats that invalidate the "if" operation. Hopefully through this answer you can better appreciate other perspectives and once again, I encourage you to show me and everyone else an example of a "dangerous custom auth" and for each one you do I can show you a badly-implemented Auth0 code that leaves a website vulnerable because of not understanding what the documentation was going on and on about. We would have very fast computers by now were it not for people like you afraid of what they don't know and what they readily believe from marketing narratives without checking. Please do your own homework - in this case, write your own auth library - so you can see for yourself how simple it is, and enjoy the freedom that comes with knowledge. I sincerely invite you to do so. Please ask any questions, thank you for engaging in this conversation with me, and I apologize in advance for being a tad rude - I don't mean to come across that way, but I am, so I do; it has nothing to do with you, so please forgive me.