If the title of this episode didn't give it away... we are talking about logging into and accessing the content in web applications. Albert Starreveld spends a lot of his time implementing authentication and authorization workflows for his clients. There are a lot of factors that determine how to handle these implementations correctly. Are you still using role-based authorization? What identity provider are you using? Are you using SSO? Are you using claims/scopes? Do you know how to set up claims transformations? These are just some of the questions to ask when dealing with authentication and authorization. In this episode, we discuss these questions and more with Albert. Have you had to implement auth in a web application? How did it go? Let us know on Twitter at @dotnet_Podcast.

Hello and welcome to another episode of Adventures in.net. I'm Shawn Clabough, your host, and with me today from New Orleans, Caleb Wells.

 

How's

 

Hey,

 

it going,

 

y'all.

 

Sean?

 

It's going good. It's going good. It's hot, but it's, you know, we've got lucky we haven't had any forest fires really that many this year, so I

 

Yeah.

 

haven't had to bring out the smoke filters and things like that. So that's pretty good.

 

Yeah, we haven't really had too many issues with hurricanes yet. Knock on wood, of course.

 

Yeah,

 

Lots

 

there's

 

of mosquitoes, though.

 

still a lot of that season left though, so a ways

 

There

 

to go.

 

is. There is a lot of season left. But

 

Yep.

 

so far, so good.

 

All

 

Yep.

 

right, great. Let's bring out our guest today, a new father. We've got Albert Starveld. Welcome,

 

Hello,

 

Albert. Hey.

 

thanks for having me.

 

Hey.

 

Yeah. Thank you. So

 

So Albert, where

 

Albert,

 

are you

 

why don't

 

at?

 

you give us, yeah.

 

Yeah.

 

Sorry.

 

Give us a little bit of introduction about yourself, where you're at and what kind of things you do and how you got into.NET.

 

Well, as you said, I'm Albert Starreveld. I'm from the Netherlands. I live in Utrecht and I work for a consultancy firm called VX Company in Baarn. And well, I help a lot of clients shifting to continuous delivery. So I work with a lot of different topics like how do you make your application smaller? How can you... introduce the deployment pipelines, how do you automate testing, but there's also a big component in that when you chop your application in smaller parts, then how do you deal with authentication? And I think that is something that we're going to talk about today.

 

Yeah, definitely, definitely. So how did you end up in the.NET world?

 

Well, I had this internship at this company and they asked me to validate 900 IP addresses and I had to use RDP and I had to log into all these servers and then type my username and password, click start, configuration panel, TCP IP settings and it just took forever and I figured how can I do this in a simpler way? And then I found out that there was this Windows management interface, which I could type some code with, and well, I started using that. And next to me, there was this man and his neighbor had a company and they were writing software to manage networks in.NET. And he said, you guys should maybe talk to each other. So I started working there and they taught me what.NET really is. And from there, well, I started getting another job and another job and I started learning more and more and more and here I am, I think about 15 years later. So that's how it all started.

 

Nice. So you mentioned we're going to talk about authentication. So where's the best place to start our discussion about authentication today?

 

Well, actually, I think since I started this first job at this network monitoring software company, a lot has changed. And I figured maybe that's a nice place to start because when I just started working with.NET, we had this thing called Forms Authentication, and you could deploy the stable structure in your database, and then you could store your username and your password. and then people could log in and then you would log in with the session and everything would work. But then things started changing and this concept called single sign on was introduced and we started making stateless APIs and we started doing things with tokens and well, a lot of things changed because we were not storing usernames and passwords in our applications anymore. and we were storing things in other places, we started using other services to authenticate, like you could log in with Google and you could log in with maybe your GitHub account. And that would also mean that, well, logging in was not logging into just one application, you started logging into a lot of applications. And well, that really changed a lot of things because now you had this thing called, well, claims identities in.NET. I don't know. You know it, right? So basically, what happens is somebody logs in on some external service, some identity provider, and you get this token and you start posting that to your API. Then, compared to forms authentication, in forms authentication, when you would log in, People used to work with roles. So you would assign a role to a user. You would say, you are

 

Used to.

 

maybe, yeah, yeah. But

 

Some people

 

when

 

still do.

 

I wish, I

 

some.

 

wish, I wish used to. Some of us still stuck with it, but yeah, yeah. Keep

 

Yeah,

 

going, you're right.

 

but that's a really interesting topic because things really started changing there because instead of having roles that apply to your application, instead you would have some identity from some external provider saying, hey, this is John and he has red hair. So now how do you say if he has access to your accounting application, yes or no? So you had to start thinking about policies instead of assigning a role or something like that. And that really, you really had to change the way you thought about authentication. Things got more complex because now you had to have this identity provider, but this identity provider contained some information which well, was really generic, but how do you deal with that in your application? And there are several ways to do that. Maybe it's interesting to start with some situations that I see a lot in organizations. I always compare with Spotify because... What we see in organizations is basically the same thing as logging into Spotify in the sense that you can log into Spotify with your Facebook account. So there's this well abstract identity provider and your well specific application, but you're not only logging into well, Spotify with your Facebook account, you're also logging into maybe, I don't know, Instagram. And they're all completely different applications. So you could say that the... identity information that you would receive from this identity provider is not complete enough to apply a policy that makes sense in your application. So we see the same thing in organizations. So say you have an organization and you have different services for for different clients. Say maybe you have an organization that sells some accounting software to people, but also some CRM software. So in abstract, that might be the same thing because as an organization, you have one customer, which is a customer to your organization, you want him to log in with one account. Another great example that you can compare it with is Office 365. You log into Office 365. and you can use Microsoft Word, you could use Excel, but you could also use a Jammer. So those are all things that may be in your subscription, yes or no, and all these applications require different information. So what we see a lot in organizations is that they introduce their own identity provider. and they federate that identity provider with another identity provider. So they delegate the authentication process. Somebody comes back to the organization specific identity provider. And what happens there is they do add claims that are specific to an organization. Say they have a unique customer ID. So that is something that gets added to. to the IDP that is internal to the organization. But then there's this development team and they need to work on it. They say, hey, but I need to have this license maybe for this part that I'm building. So, can you put it in your IDP? And then the team goes like, no, we can't. And well, then the team goes, but why not? And then they say, well, we just don't want to have all that information. And then they say, why not? And... Basically, why you do not want to do that is because the nice thing about OAuth and OpenID Connect is that you are delegating authentication now. The big advantage of delegating authentication is that you can keep adding applications to that. And if you want to have more and more applications using that authentication service, you got to make sure that you don't leak all sorts of information about the specific applications in this identity provider, because then the thing gets bigger and bigger and bigger and bigger. And at some point you're getting stuck because, well, you need to make a change to your application. But there's probably something specific to your application, maybe in this identity provider now, you need to update that too. So you want to prevent the situation. that you need to keep updating an identity provider and an application when you release a new feature. So that's why you wanna say, I wanna have an identity provider which only has identity information. And then when you put application specific context about a person in your API, well, you're now in control of what you add to it. So this makes it easier to add more applications because your your your IDP doesn't grow and it makes it easier for the team that is working on this specific API maybe because they are in control of whatever they're adding to it. But this gets interesting because you need to store information maybe identity information in your application now, which is something that you don't want, right? Because, well, we all need to be GDPR compliant. When somebody calls and says, hey, I don't want to be in your ID landscape anymore, what we don't want is go to all the departments and say, hey, I got John here on the phone and I was wondering if he's in your database, could you maybe look him up and maybe also in your Blob store, and I don't know what maybe in your event stream and so forth. that's not really a situation that's very manageable. So what you want to have instead is a situation. You want to have a

 

Well,

 

situation.

 

I would just. Yeah, you can keep

 

I can't

 

going.

 

hear you Caleb.

 

I was just going to ask a question. You can't?

 

Yeah, we can hear you Caleb.

 

I can't hear you now.

 

You

 

Yeah,

 

cannot?

 

go ahead.

 

You can't?

 

We can.

 

OK,

 

And everything

 

hold on.

 

all good.

 

Okay, I was going to ask a question, but go ahead.

 

So instead what you want to have is you want to have a situation in which you have well, identity information, personally identifiable information in one part of your landscape, your identity provider as the name implies, and you want to disconnect that from data that is specific to your application. So When you log in with OAuth, you get this access token. You post it to your API, you probably have done that. And what you will see is this token contains some claims. And one of those claims is the subject ID. And this is an ID that is unique to the person that is logging in. And what you can do with it is you can use it to store maybe license information. And if you link a subject ID to maybe license information or something like that. you will create a situation in which all the information about a person's identity is in one place and all the application specific information is in another. So if John calls and says, hey, I want to be forgotten, all you need to do is go to the identity provider and remove John there because all the personally identifiable information is there. And the other information is in the application and that's fine. And maybe when John comes.

 

So you get a token and then do you have to do something to get the claims out of that? And what's the process there? Or does the token just kind of expose those claims? And then of course, what are claims?

 

That's a good question. What do you have to do? Well, not much because Microsoft has made it really easy. But maybe it's more interesting to talk about what this token actually is. Because it looks like some encrypted form of data, but it's really not. It's a base64 encrypted string, and this string contains JSON. So you can just base64 decrypt. any access token that you can see in your network tab in your browser. When you use a website that uses OAuth, you can just grab that token and well, base64, degripped it and what you will see is that there is a bunch of data in there. And it will contain different information. It will contain the subject ID, it will contain the audience, it will contain scope. So it's just raw data. It consists of three parts. There are two parts that are really interesting. That's the section in the middle. The parts are divided by dots. But the section in the middle is a JSON that contains information about the person. And the third part contains some form of a checksum that you can use to validate if the token has been tampered with. It's encrypted with the private key from the identity provider. and you can ask the identity provider, hey, this person has sent this base64 encrypted, well, encrypted formatted data and how do I know he didn't put somebody else's name in? So you can go back to the identity provider, say, I got this Jackson here, is that correct? And that's something really important. So if you want to see what the claims are, what you really need to do is, well, base64 decrypt it. then you can just read anything that's in there. And well, all the entries that are in the JSON are basically pretty much claims. And what's really important, don't forget that. Make sure that nobody has tampered with it and use the last section to validate that.

 

So

 

So...

 

is it best to validate that every time you get a request from

 

Well,

 

the user?

 

the best thing, because if you look at this is all OpenID and all that stuff, and it's really quite complex. And what we also see over time is the protocol keeps changing all the time because people start keep finding holes in it, which get patched all the time. So it's really important not to build this yourself. Use some standard component that you can find something that is in a Microsoft. or something that is maybe some out of zero library, something like that. Something built by a trustworthy company. You can use these packages to do all of this for you. In.NET, this is all built into the.NET framework. So if you post a access token to an API, and you have configured it correctly in your app config, and if you have added the right packages, then Microsoft does all of this for you. So,

 

Nice.

 

yeah, it's quite complicated really. And it's also important to understand that it's important to do it right, not just go like, hey, I got this header here and it's an access token and it looks complicated. So it's probably right. That's not the way to go.

 

Yeah. Yeah.

 

Yeah.

 

So the identity provider, all they're doing is they're just doing authentication, right? You still do all the authorization parts on your

 

Exactly,

 

side based

 

exactly.

 

upon that,

 

Yeah,

 

on that

 

yeah.

 

token. Okay. And the claims. Yep. Okay. Got it.

 

Yeah, well,

 

when

 

also,

 

using

 

they're.

 

an identity provider. Yeah, when using an identity provider, what do you suggest? Do you suggest that if someone feels the need that they have like a identity server or a Dwinday in their setup or internally, or do you suggest they use something like Azure or Okta or something else?

 

I have a terrible answer. It depends. It really depends. And

 

That's always the best

 

Got you.

 

answer.

 

yeah,

 

Yeah.

 

well, the thing is, don't build it yourself. First of all, don't do that. That's just a common best practice, not to build these things yourself because like I said, it keeps changing all the time and it's really complex. So you can use a couple of things to well... You can take some off the shelf products. I am familiar with Outzero, which I really like. It's a identity provider as a service basically. It's very well documented. I really like to use their documentation for OAuth anyways, because they really explain it well. But you can also maybe use Azure Active Directory, something like that. All of these products are all OAuth kind of products. But like I said, it depends. Azure AD might be something that is in your organization. People use that to log in anyways, and then that's a really good choice. But there are also scenarios where you have to federate with all sorts of third-party companies which don't really follow the standards, and that might get complicated sometimes. So if you use a standard identity provider with something like Auth0, have a pretty big chance that it's not going to work because it's just not compatible. So you can write your own plugins there. But there's also this product I really like. It's called Identity Server. It's an open source product in.NET. And they built an OAuth slash OpenID implementation. And it's basically as well, you can use that as a component in your API landscape. There's this other thing that I discovered recently. It's from the Java world. You can host it in a container and it's called KeyCloak. Basically, the big question that you need to answer is, can I use something in the Cloud? Are maybe my users logging in in some company network, maybe in Azure AD? Or do I want to host it myself and not pay for the monthly active users because in all these hosted solutions, you pay for monthly active users. something really important to keep in mind, how many people need to use it. And then you can choose to maybe host something yourself and there are standard solutions like Keycloak and Identity Server that you can use to do that for you.

 

I got another question and this is around single sign-on but more from a company perspective. So for instance, you know, it's not going to be Spotify but say, right, you're a payroll company or

 

Mm-hmm.

 

a travel company like my company, right?

 

Mm-hmm.

 

And so your clients are other companies and all of their users are logging into their system. whether it's Active Directory or whatever, and then they want to be able to click a link inside their system and be logged in directly to yours. Have you dealt with that much? And what are some of the gotchas there? I know for one, we've had to deal with some clients who are still using SAML over OpenID.

 

Mm-hmm. Mm-hmm.

 

So yeah.

 

Yeah, I dealt with that.

 

Ha ha ha!

 

What can I say? Well, in Holland we have this thing, it's called Digidee. And probably never heard of it. This is this mechanism that we use in Holland to log into like the IRS and do all your legal stuff. And it's an identity provider. And when you want to have an account, they will send you a letter and... you need to scan your password with NFC chips. And that's why they make sure that you are really you. And they're using SAML. And I built a couple of websites where we had to integrate with that. And yeah. What were some of the gotchas? SAML is a protocol and you really need to... know the protocol because there are like URLs or namespaces that you need to define with certain dots in between and if you don't do that, your standard implementation doesn't work. And that's where I messed up most of the times that I didn't read the Sommel specification good enough and I would request them to configure things and they would do so, but I did, I asked for values that were not in specification. So that were not good. the specification so that that was kind of a stupid thing to do and most of the times

 

We've all

 

when

 

been

 

we

 

there.

 

had

 

At least I have.

 

yeah that's good to hear but I have to say all the other implementations where we had to federate with something OpenID connect kind of protocols like OL2 and that would all go quite smooth I must say didn't really have big problems there There's another thing that does get interesting and that is say you federate with multiple identity providers. So say you log in with DigiD, but you might also log in with Gmail. You might have the possibility that the person who's logging in is actually the same person, but you get a different ID. How do you deal with that? That's also quite an interesting question. So whose ID do you use and where do you manage that? Well, I think there are all sorts of correct answers. You could choose to maybe say, I'm gonna make a list and somebody logs in with ID Gmail1 and Digiday5. that's Albert and I'll give him ID X. And then you can use your X ID inside of your company network. But you could also say, hey, maybe it's not really required to make sure that this is one same person. So these are all things that you need to consider because it makes things a lot more complex.

 

You know, that's interesting because it makes me think of some of these services like Spotify or GitHub or something else, right? And they have multiple ways you can log on or multiple single sign on clients. And if, if I haven't like save the username and password, or I don't quite remember, you know, I may have created an account directly through them. And then I come back in and I'll log in through Gmail. And now I have two accounts, right? And it's

 

Mm-hmm.

 

not going to send me to the first account I created because it doesn't know right there. Like you said, there's no correlation unless the system has that built in some way. And there has to be that extra step to tie those two together. Yeah.

 

Mm-hmm.

 

No.

 

And there's also another thing with OpenID Connect that is really big time voodoo, is if you federate with one

 

Hehehe

 

service, maybe they federate with another and maybe they federate with another and maybe they even federate with another. So you get a chain. So if you click log out, where are you logging out?

 

you're logging out from. Gotcha. Yeah. Hmm

 

So one situation I've been exposed to sometimes is, single sign on doesn't become single sign out. It becomes single username and password, where an organization has multiple applications spread out to different departments, things like that. And they're using something like Okta, but yet you still have to sign on to everyone that you go to. So. What's going on there? What's the issue where you're not really getting that single sign on where you can move from application to application, but you still get that single username and password?

 

Yeah, well, I don't know really Okta specific things. I haven't really used Okta, but you're touching a very interesting subject there because a single sign-on is, the big question is, what are you signing on to? So, and that tends to go wrong because what you want to have is you want to have an identity provider which you log on to. And you can have a session there. And... Also, if you look to OAS, the protocol, you can see that it has different ways of signing somebody in. And a little while ago, Outserror used to have this nice flowchart where you could choose which way you should use to log on. And one of the questions they were asking is, do you trust your application with the username and password from the client? And if the answer is no, make sure that the, the person who's logging in is answering his username and password in a secure place being the IDP. And that's a really important thing to keep in mind. So you want to have your IDP be the secure place to be logged in and to have a session and to type your username and your password. And this is basically the safe haven. And it just makes sure that you are you and nobody else is stealing your. You're hijacking your session, stealing your identity, and so forth. So that means that if you log in there, you want to stay logged in there. And the APIs that you're maybe using across the landscape, they are supposed to be stateless. So you get this token, which allows you to use it on behalf of you. But a token is something that is valid for an X period of time. So maybe. this token says that you're allowed to use an application for half an hour. After half an hour you want to be able to get a new one. Or if you navigate to another service you also want to get another token there. So this is all in a timeline. So usually you're first using your CRM application and then maybe you go to your accounting application. And what's important is that then your IDP still has you logged in because the application will say, the accounting application for example, say, hey, I don't know who you are yet. Mr. IDP, can you please tell me who this is? So you make a round trip to the IDP and gives you back a token and says, hey, this is Albert. Then you go to the next application and because, well, it is stateless, it will say, hey, I don't know who this is and it will go to the IDP, say, who is this? It will get a token and say, hey, this is Albert and so forth. What is important to realize is that if you use OpenID and OAuth, is a token is not the thing that says you're logged in. You're logged into the IDP and the token is just something that you can use for a little while. So also when you log out, you need to invalidate the token and you need to log out on the IDP. So there are two separate things and this tends to go wrong often.

 

So if each application requires a new login, even though they're using the same IDP, then that probably indicates that they're using different, what keys or authorization. So the IDP thinks that they're not all the same and won't share that login.

 

Maybe there are different tenants, something like that. So it's not configured as a single sign-on for the entire landscape. It's just maybe a tenant on Okta for one application and maybe a tenant for another application. So you get like multiple IDPs and there's

 

Yeah,

 

not one

 

that

 

So

 

shared

 

makes

 

they don't

 

sense.

 

session.

 

talk to each other. Yeah.

 

So

 

Yeah. Gotcha. So, they

 

yeah,

 

don't

 

they're

 

talk

 

just

 

to each other.

 

separate IDPs

 

Yeah. Gotcha.

 

and that's something you don't want. You want to have one central IDP. So you really get that single sign-on

 

Yeah, so

 

effect.

 

the IDP knows the same username and password, but it's saying, okay, I'm not gonna give you the same token that this other application had that's under

 

Yeah,

 

the same organization

 

that

 

because

 

could

 

you're

 

be

 

using different

 

or

 

stuff. Yeah, yeah.

 

maybe you're saying, I got this

 

Got it.

 

IDP and maybe I want my users to log out after one minute automatically. So I don't want to keep the IDP logged in. That's also another common thing that happens. So you get this token

 

Okay.

 

and you can use this token for an hour, but maybe the session on the IDP expires, maybe it's configured to expire after half an hour. So you go back in time and... the server will say, hey, you need to log in. So these are all different possibilities that you can see there.

 

Yep, lots of challenges.

 

Definitely. It's just a

 

That's

 

very

 

why we

 

abstract

 

need people

 

topic.

 

like Albert.

 

That's why we have a job.

 

Yeah.

 

Definitely.

 

That's why

 

Yeah.

 

Albert has a job.

 

Yeah, yeah. But it's quite interesting as in, another thing that we really see in the industry a lot is that, well, like I said, you get this token with this person and you need to store information that you use to authorize. So what I see really often is, is somebody supposed to see information about customer X. So what do you do? Where do you do that? What I see a lot is that you get these MVC applications like RESTful APIs, and you get code and it says like, okay, I'm going to look at this access token. This is Fred. I'm going to go to the database, see if Fred is in company X. And then if he's not in company X, then I'm gonna throw a not authorized exception, and then I'm gonna go to my repository, and then I'm gonna query, and I'm gonna query where an organization has IDX, and so forth, and so forth. And what you end up with is an application that just mixes up authentication logic and application logic. And what's a really complex question is When is something authentication logic? And when is it business logic? And how do you separate the two? And well, this is something, well, you can solve in different ways, but what I really like in the.NET framework is that you can use claims transformation to do that. So you can really pull the two apart. So they introduced this concept a long time ago. It used to be, I believe, claims augmentation. I have this colleague and he always keeps referring to SharePoint when I say this, because apparently it was a thing there. But in the.NET framework, there was this thing called claims augmentation. Now it's called claims transformation. What you can do basically, it's based on the.NET pipeline, execution pipeline. And what you can do is when somebody posts this access token to your API, or when somebody is logged into some MVC application, which also works with an API token. You get this identity object and in the pipeline, you can say before it actually goes to a controller, like I wanna do something with this identity. I wanna replace it. I wanna add things to it. And this is really nice because if you do that, you can pull the two apart. You can use the.NET authentication framework. you can use a concept called policies. So what you can do is when somebody posts to the API, add the context that makes sense to your application to the identity. You can add claims and further down the chain, your application will think these are really authentic claims that come from the identity provider. And you can use them to apply a policy. In the.NET framework, there's this nice tag called a policy, and you can configure it to execute some business logic. So you can say, maybe if somebody is accessing endpoint, slash organizations, slash five, slash orders, you can use this policy to make sure that this person is actually a member of organization five. What happens is then code that's being executed is going to do only what it's supposed to do, just get this data from this database and you don't need to bother about authentication logic anymore. And this really makes for a neat, clean code. So this is a concept that we really use a lot and that I would really recommend. But also another thing that's interesting in the way that this is set up is that when you use the Microsoft framework, it's talking about policies. And I think this is also something really interesting. If you look at OAuth by itself, then it's talking about, there was actually a question somebody asked says, so OAuth is this authorization protocol, right? So then why can you not use OAuth to actually authorize? And well, in OAuth, there's this concept called scopes, and it's also a claim. So when somebody logs in, you as a user can give consent to use an API. Or you can have your identity provider validate if somebody is allowed to do something. But there's a problem with that, because if you do that, you get into the situation I mentioned earlier. You get an IDP which needs to know everything that is in your API, all the scopes that are in your API. So instead what you want to have is something abstract so that you can apply a policy. And if you have a policy, like the word implies, it's just a rule that is being executed based on your identity. And it's also not bound to time. So if you use the example of say, you have an employee and he is going to stay with the company for maybe a year. So... what are you going to do after a year? Will you maybe change this person's scopes? Do you want to do this manually? Or do you want to say, hey, I have this policy and my policy is that the end date of the contract, if that is earlier than today, then I don't want people to be able to use my application. So by doing so, you can automate your security policy in your application directly so that you get Well, you have less work to make sure that everybody who is allowed to use something is actually using it or is being denied access. And that way of thinking is, I think, really an interesting thing to do. It's not always applicable. Sometimes there are reasons that organizations say, hey, I need to actually have a person allow and deny a person access because otherwise I'm not complying to regulation x y or z in that case that these kind of concepts don't fly but if if you're possible if it's possible to apply a policy it's really gonna save you a lot of headaches so I would definitely recommend that

 

So I had a question about thinking about GDPR and tokens and identity providers and things like that. So somebody calls into your organization and says, I want you to wipe my information, whatever, that identifies me from your system. So you go

 

Mm-hmm.

 

out your identity provider and you remove their records. But the organization still has the data that they had generated or had been generated about that person. So do... If somebody then calls back in and says, hey, I need my data back. Do they usually have some sort of a, something that the customer only knows and able to be able to restore that identity information? Or once somebody says, wipe it, you know, you just, there's no way to relink it back to that person.

 

It depends. There's,

 

Yeah

 

I mean, it depends like what he is logging in with. So say you are logging in with your Gmail account, then you get, well, like I said, you get this access token and this access token and also the ID token contain this claim called subject ID. So I have a unique ID which is provided to me by Google. And if I have an IDP in my organization, which federates with Google, it will always get my Google unique ID. And if I use that in my landscape, and if I linked say a license or something like that to that ID, and when I log back in, then I will just get my old stuff back. But say

 

Okay.

 

you implemented identity server for example, so you're doing this yourself. Or maybe you have Azure Active Directory, and you're removing this account from there, and you're creating a new account, it's very likely that you will have another subject ID. When you log back in then, then it's gone, and there's no way to find it

 

Yeah.

 

back because it's just a random ID. You really don't know.

 

Yeah. I was just thinking that maybe if you did store some sort of a secondary information that the user volunteered. That was encrypted somehow. And they said, this is me and here's my little secret passphrase that I used in my original login. You could get it back that way. But yeah, I totally understand that if it's only the connection between your application and the IDP has been broken, you can get it back fairly straightforward. But if the actual account. in the IDP has been deleted, then that's gonna be a much bigger challenge to reconnect if somebody wanted to do that. So

 

Exactly.

 

yeah, that makes sense.

 

Do you think things like GDP are going to become more common? I know they make things more difficult for us as developers and for companies but I do appreciate right the the focus on privacy and protection of users data. Do you see it? I don't know that we'll ever do it here in the US but do you see it happening elsewhere in the world?

 

Oh my. Uh...

 

Hehehe

 

Um... This is a trick question,

 

I don't

 

right?

 

know, how well has it gone, I guess? That's kind of, you know,

 

Yeah, that's that is a

 

we're

 

good

 

not

 

question.

 

in Europe. We're not in Europe. So,

 

Right.

 

I mean, how well has the GDPR process gone? You know, I haven't heard of anybody getting those humongous fines that could potentially come along with the GDPR violation. But, you know, we get different news than in Europe. So how well has it gone?

 

Frankly, I think we have a long way to

 

Hehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehe

 

go.

 

Gotcha.

 

Yeah. Yeah, but it's not only things like the subjects that we're talking about right now, but what we see a lot here is, it's in the news that some agency, like some federal agency made booboo and somebody downloaded like personal data of like, half of the Dutch population, things like that. But what we see a lot is that companies don't... that the different departments in organizations don't take responsibility. They say, hey, this is not my responsibility, it's their responsibility. And that department says the same thing. But I think like GDPR, security, things like that, it's everybody's responsibility. What's also a thing is we I don't think we often enough realize that there are really mean people out there that abuse your software. So I really like this concept of threat modeling when you have a user story that you also think about how could somebody maybe abuse this and how can we make sure that that doesn't happen because I think most of the the place where things go wrong is in functionality that we just didn't look too carefully enough. So, but that's, that's my personal opinion.

 

OK,

 

No,

 

with

 

I appreciate

 

that said,

 

that. Yeah.

 

is there anything else we should cover before we move on to PIX?

 

Uh, uh, uh, blah blah blah. I don't think so. What do you, what do you think?

 

I think that was a really good discussion. I think there's a lot that we went over in kind of a short amount of time. And hopefully it provides some good information to our listeners, so that would

 

I hope

 

be great.

 

so.

 

And if you do think of something that we didn't cover, whatever, we can have you back on the show sometime. ["The Time Is Now"]

 

Cool. Will do.

 

Okay. All right. So we'll move on to picks then. And I guess I will go first. And my pick this week is season three of lock and key. I've really enjoyed this

 

Hmm

 

Netflix show and you know, really wasn't that long ago that season two came out, but just this week they released season three. So I'm going to be starting to watch that this weekend and, you know, really see what's going on in the show. So. I really liked it, so.

 

I haven't seen it yet. What's it about?

 

You haven't seen either of the seasons? Oh, it's, well, let me give you the spiel here that they have is, you know, after their dad's murder, three siblings move in with their mom to this ancestral estate where they discover there's magical keys that unlock powers and secrets to different abilities that the people can have. And so there's lots of different things that they just, you know, different types of keys with different powers that they find. And of course, then other people are also trying to. get the keys and so on and so forth. And then lost lots of mystery and things like that going on with it. So yeah, if you like kind of that kind of thing, locking key is really addictive. So sit down and binge watch it if you need to, but it's really

 

Sounds

 

good.

 

great, I'm

 

At

 

gonna

 

least

 

do

 

watch

 

that.

 

the trailers and check it out. Yeah.

 

Nice.

 

All right, Caleb, what's your pick?

 

Yeah, so my pick is a book I've been reading. Very interesting topic. It's called A Lifespan, Why We Age and Why We Don't Have To. And it goes deep into the research that's being done around aging. And we've all just come to accept. that aging is going to happen when it's, from the perspective of the author and the research, aging itself is a disease. And there are ways to combat it and slow it down and have a longer lifespan as well as, you know, better quality of life. So I'm not done with it, but it's involved, right? It gets pretty deep, but it's been a really good read so far. So yeah, lifespan.

 

Okay, cool. All right, Albert, what's your pick for us?

 

Yes, I definitely have a pick and that is definitely my daughter and my girlfriend. Because

 

There you go.

 

May 10th, three months ago, my daughter was born. And what I really hope is that maybe in 20 years, my daughter will find this episode on the internet and that she will hear that she's definitely the best and that I'm really proud of her. So, yeah,

 

Good.

 

that's definitely

 

And what's your

 

my

 

name?

 

pick.

 

some.

 

Her name is Chloe. Chloe Adriana after my grandmother, her great grandmother. She's really proud. So it's really great.

 

Very nice, very nice.

 

Very cool.

 

Okay, so Albert, if our listeners have questions and they wanna get in touch with you, what's the best way to do that?

 

So I have this blog and I write on Medium. It's ab-stadeveld.medium.com and I have some articles there which you can respond to. And you can also email me to a-stadeveld.vxcompany.com and definitely reach out if you have questions.

 

OK, thanks Albert, and thanks for coming on the show.

 

Well, thanks for having me.

 

If our listeners have questions or feedback for the show, we'd love to hear from you. They can reach me on Twitter. I am at.NET Superhero.

 

da da da and I'm at Kaleb Wells Codes. I love that part

 

All right.

 

of the show I can't help it.

 

Thanks everybody. And we'll catch our listeners on the next episode of AdventuresIn.net.

 

Bye y'all.