S8 E14 | Auth for Modern Angular | Alisa Duncan - The Angular Plus Show

Episode Transcript
Available transcripts are automatically generated. Complete accuracy is not guaranteed.
Speaker 1 (00:08):
Welcome to the Angular plus Show. We're app developers of
all kinds share their insights and experiences. Let's get started.

Speaker 2 (00:21):
Hello, and welcome back to another episode of the Angular
plus Show.

Speaker 3 (00:25):
I'm going to be your host today.

Speaker 2 (00:26):
My name is Brian Love and I am joined today
by Lara and Chow.

Speaker 3 (00:30):
Lara. How are you today?

Speaker 4 (00:32):
I'm good. I'm good. Happy to have made it to
the year twenty twenty five.

Speaker 3 (00:43):
Crazy crazy.

Speaker 2 (00:45):
Those people that are like, like whatever, younger are probably like.

Speaker 5 (00:49):
What do you mean?

Speaker 2 (00:49):
That's it seems totally normal to be here in twenty
twenty five. Choo, good morning, Good afternoon.

Speaker 3 (00:56):
How are you. How are things going good?

Speaker 6 (01:00):
Just got hit with the tons of snow?

Speaker 3 (01:02):
Yeah, you guys got blanketed.

Speaker 4 (01:05):
I got zero of the snow, and I kind of
want my money back. I mean, I live in Iowa.
We are in the like we should.

Speaker 6 (01:13):
Yeah. Yeah, I got like fifteen inches or something.

Speaker 3 (01:17):
Oh that's great.

Speaker 4 (01:18):
I'm so jealous.

Speaker 2 (01:21):
I am I'm a skier. Sound jealous as well. I'm
sure some people are like.

Speaker 4 (01:24):
No, amazing to me, wrapped at home, Like my favorite
state of being in the winter is trapped at home
by the snow.

Speaker 2 (01:34):
I believe that there is nothing about that statement that
I would argue with.

Speaker 3 (01:38):
I believe all of it anywhere.

Speaker 2 (01:42):
How you just said you were you're running a little late,
you're debugging something in Prague. Give us the thirty second spiel.
What did you what was it and what did you
have to fix? Or what is still broken? What is outstanding?

Speaker 6 (01:54):
It's actually authentication, just nice, it is authentication. It has
to do with Samil so one of the enterprise customer Yeah, yeah, yeah, yeah,
out and stuff like that.

Speaker 2 (02:09):
I was just saying to our guests, and I'll introduce
Alssa here in a second, but I was just saying
to our guests that, you know, I'm curious about some
of the different, the newer, different things that are kind
of happening in the AUS world. I've been working for
like a year and a half with a large enterprise bank,
and everything is windows off and Samil and all that
kind of stuff, you know what I mean.

Speaker 3 (02:28):
So it's like we don't getting used on any of
the cool tools.

Speaker 2 (02:30):
But that's okay, I guess once you get in and
off like you're fine, so to speak. But anyways, good
to have both of you here. Thanks Laura, Thanks to
appreciate it.

Speaker 3 (02:41):
Yeah.

Speaker 2 (02:41):
So, our guest today is Alisa Duncan is a secor
developer advocate at OCTA, a conference speaker, Google developer expert,
Angular Lural site author, and community builder who loves the
thrill of learning new things. When not coding or volunteering,
you can find her planning her next travel destination, checking
out the local food scene, and drinking a glass of wine.

Speaker 3 (02:59):
Welcome to the show, Lisa, go.

Speaker 2 (03:02):
Ahead and introduce yourself and say hello to the good
people of the Angular world.

Speaker 5 (03:07):
Hello Angular Podcast audience with Angular Plus show audience, and
hello to Laura, Brian and Chow. It's so good to
be here. Yes, I do love traveling and checking out
new vacation places. So luckily I moved from Chow's neck
of the woods, where we would have had twelve inches

(03:27):
places of snow in Kansas City to the Pacific Northwest,
where we have a lot of just great days, and
so I feel like a lot of beach vacations. Are
you know, really yeah, needed any days while you.

Speaker 4 (03:40):
Was in bond, like we were in bond together last time.

Speaker 5 (03:42):
I said yes, yes, yeah.

Speaker 4 (03:49):
Dumpy Beethoven state statues like they're because he was born there.

Speaker 7 (03:54):
They have these little dumpy golden statues everywhere and it's
really weird, is true, Like I don't know was he
stumpy man?

Speaker 3 (04:02):
Like I don't know the answer to that, do not
know his pipe?

Speaker 5 (04:08):
It is true, It's like it is a tour of
stumpy Beethovens all over you go all over the place.
It was funny.

Speaker 2 (04:15):
That's good, Alisa, are you going to be I know
you said beach vacations as a new member of the
Pacific Northwest, will you be going to the beach here
in the state of Oregon or the state of Washington.

Speaker 3 (04:26):
What do you think? I mean, it's pretty nice.

Speaker 5 (04:30):
Yes, I'm not sure i'd go right now because it
is pretty, you know, gray and rainy. But we have
been in the winter. But in the in the summer
when the weather clears up, it is just so pretty
to walk around the beach and the Oregon coast it
is very pretty so and the Washington coast.

Speaker 4 (04:49):
So does it ever get warm enough to go in
the water?

Speaker 3 (04:54):
Well, you want to, but you do not.

Speaker 5 (04:56):
Go in there. I don't think so it's still too cold.

Speaker 4 (04:58):
Yeah.

Speaker 2 (04:58):
Yeah, I think like the brave souls, like there are
people out there with like wet suits on and like
July and August like surfing, but it's like super dangerous,
you know what I mean. There's like a lot of
like riptides and like and it's it's really cold, and yeah,
you generally just kind of look at it and enjoy
the view.

Speaker 4 (05:16):
I don't want to go in the ocean anyway, because
there are fish in there and that's gross.

Speaker 3 (05:20):
So there's ocean. Yes, sorry, I've been hanging out with
my two year old a long time.

Speaker 5 (05:28):
Fish in the ocean.

Speaker 3 (05:29):
Oh my goodness.

Speaker 5 (05:31):
Fish in the ocean is the problem. Got it?

Speaker 6 (05:35):
My fam my family lovet the ocean. When we when
we went to California back in the summer, my kid,
So we were there for like a week and my
kid I went out to the ocean. Uh maybe ten times. Yeah,
lunch lunch, ocean dinner, ocean lunch.

Speaker 8 (05:57):
I can get behind this.

Speaker 4 (05:58):
I could I fully this lifestyle.

Speaker 5 (06:01):
Yeah, that's a good beach schedule. I agree with that one. Yeah,
I like it.

Speaker 2 (06:07):
Okay, now that we've covered all of the critical content
for this for the episode of this podcast, child, best
of luck with your pride issue, Lara, Best of luck
with your house selling a Lisa tell us a little
bit about what we're going to be talking about today,
and tell us a little bit about what you do
at OCTA.

Speaker 5 (06:26):
Sure. Yeah, so today we're going to talk about everybody's
favorite topic and it might be child's favorite topic right now,
very relevant authentication security. And what I do at Octa
is I'm a developer advocate. Octa is a company that
handles identity services and I help y'all succeed. That's my goals.

(06:47):
Make sure that y'all can succeed and have good authentication security.
And then if you have any issues, which I hope
you don't, but if you do, I take that back
to Octa to say, let's see if you can find
a way to fix this.

Speaker 3 (06:58):
So it makes a lot of sense.

Speaker 2 (07:00):
Are you mostly focused on like web apps or do
you do a lot of authentication outside of web apps
as well as part of your role.

Speaker 5 (07:08):
I mostly do web apps, although the Octa product does
include like mobile SDKs and such, but I haven't really
played a whole lot with that. It might be one
of those things I want to try at one point,
but yeah, yeah, I haven't gotten to it.

Speaker 2 (07:26):
Okay, cool, So browser based authentication and you're working at
Octa and Octa. I know it's like old news obviously,
but Octa acquired at zero a couple of years back,
so if you're using A zero today, you are kind
of an Octa customer as well. So tell us a
little bit about kind of some of the things that
are going on in your world around authentication and security

(07:48):
and identity.

Speaker 5 (07:49):
I guess, yeah, yeah, I think it's a pretty exciting
time because there's a whole lot of things that are
coming out that have come out, and a lot of changes,
which is my be a little scary, a lot to digest.
But the good news is there's always always coming up
with the new methods to help protect all of us. Right,

(08:13):
there's ways that we would do so from a like
a physical manner, we could talk about that a little
bit with biometrics and things, but then there's also ways
that we can implement things programming that programmatically that will
help improve our security possure. Why do we want to
do this, Well, because passwords are really insecure, right, They

(08:34):
say eighty percent of databeates come from stolen credentials, so
we obviously want to move away from that. It is
not recommended anymore, and so we need to find better
ways to protect the front door into our applications.

Speaker 2 (08:48):
Yeah, you know, it's funny, like I don't know, I
don't know of anybody that likes passwords.

Speaker 3 (08:53):
I got to be honest, Like.

Speaker 8 (08:55):
It's kind of like do you know what I mean,
Like my wife.

Speaker 3 (08:58):
I'm not going to throw under the bus, all right,
I'll stop that, Okay.

Speaker 2 (09:02):
Yeah, So like nobody really likes passwords, but we all
just kind of deal with it. And not only that,
like there is like we keep kind of like maybe
this is a bit of a rant, but we kind
of keep bandating the problem. It's like we've got like
a like you know, we've got like a wound, and
we're like, oh, we'll just like we'll keep fixing it
or whatever. Like we've got one password, We've got these

(09:22):
password apps. Mac Oes just came with the password app
this summer or the last release of mac os. So obviously,
like passwords are not going anywhere, but nobody seems to
really like them.

Speaker 4 (09:35):
So what do we look super bad at them? Like
I don't know how many people in your pai you have,
They're like my passwords is just my name and my
birthday and my dog's.

Speaker 2 (09:45):
Name and it's the same one for like, I use
that same one on some like junkie like let's just
say quote unquote junkie website. Of like I'm buying like
a concert ticket from like a secondhand place to like
my bank account, right or my email account.

Speaker 3 (09:59):
Or whatever it is.

Speaker 2 (10:00):
It's like, so I just kind of reuse the same thing,
or I throw a dollar sign on the end because
this website requires a special character and this one won't
allow the dollars signed.

Speaker 3 (10:09):
And like it's a mess. It's like a giant, disgusting mess.

Speaker 2 (10:14):
But we're left dealing with it, right, And so like
in my password app, I have like eight hundred passwords,
you know what I mean.

Speaker 3 (10:21):
It's like that's insane.

Speaker 2 (10:22):
Like or maybe that's just what we have, So like
is there hope or are we just like is it
just it? Like what are we left with as both
developers and as users?

Speaker 5 (10:33):
Yeah, so I completely get it. So I don't know,
I've heard something like most people have with a couple
one hundred accounts, which many of them require passwords, right,
which then feeds into it you just have so many
and then some sites have password complexity requirements, don't. Some
it's just all over the place. So the question might be,

(10:56):
what if we just didn't do that right, what if
we got out of that business? And some ways that
we can have a better security would be with the
multi factor authentication, but even beyond that, we can move
into biometrics. So let's tell me that.

Speaker 2 (11:13):
Yeah, tell me a little bit more about biometrics, and like, yeah,
let's just dive right into go ahead.

Speaker 4 (11:20):
Well, and I think we could also talk like clear
up what multi factor authentication actually is, because I think
there's some misconceptions out there about what that really means.

Speaker 3 (11:31):
And I think if before if we want before we
get into the biometrics.

Speaker 2 (11:34):
And the other thing that I was thinking is like
there's also like this there was anyways this kind of
push to like no passwords, right, like I'm going to
just send you like a sign and link or I'm
going to send you a text message or so you
just my web app or whatever it is.

Speaker 3 (11:47):
My app has no password.

Speaker 2 (11:48):
It's just like your phone number is your credential or
your email is your credential, and then I'm going to
give you this like one time use good for so
long kind of link or whatever code and then that's
how you get into my system and so like there
is like no password idea, but it's kind of related,
I think to your question Laura in terms of like MSA.

Speaker 3 (12:09):
So that's why I thought I would bring.

Speaker 5 (12:10):
Up Yeah, exactly, that's that's perfect magic link, that email
link with magic link, Yes, magic link with a time
based one time password, top t ye. Those those are
that's an example of a a secondary or an alternate
factor authentication instead of fitting in a password. And of

(12:30):
course you could do the same thing with with SMS,
although it is not a recommended factor anymore. Yes, smishing, yes, submishing.

Speaker 8 (12:45):
Thank you.

Speaker 3 (12:45):
I'm glad you have. I was like, I know all
of this stuff these guys are.

Speaker 5 (12:53):
Yes, it's it's basically fishing. But when you have a
with SMS and some cards, if somebody steals your some
card and is able to replace it, so yeah, so
it's not it's.

Speaker 4 (13:06):
Not very easy to do, right, Like, yes, that's the thing.

Speaker 2 (13:10):
To somebody's phone, pop it out. I mean now they're
like e SIMS so they've kind of moved away from that,
but yeah, I mean just pop it out, grab it.

Speaker 5 (13:17):
Interesting, right, So you can also have a authenticator apps
on your phone. You can have push, you can have
a time based password, you get the ped in. Like
there's different ways that you can have different sorts of
factors for authentication. The best ones that are the ones
that are completely like non fishable, right, they're fishing resistant

(13:38):
and so it's finger right, something that is very unique
to you. Yeah, and that that would include biometrics such
as your eyes or your face or your or your fingerprint,
or it could be a combination with some sort of
device that you have to carry with you, such as
U bikey right that requires your finger print or something

(13:59):
like that.

Speaker 9 (14:00):
So yeah, how many I don't want to be the
like the doubter, but I'll come in because from the
good people for the listeners, because they're probably curious how
many people actually using like biometric authentication, Like I understand,
like I can use it with my at my laptop
and like use it for some of those things like

(14:20):
in your is your devre you know, like in your
customers and speaking with your clients.

Speaker 2 (14:25):
Like how many people are using this kind of stuff
or is it just kind of is it a slim
majority or people kind of migrating towards it or kind
of what's the what's the trend?

Speaker 3 (14:33):
Around that.

Speaker 5 (14:34):
I think people are starting to migrate towards it now.
Of course for me, I think maybe for most of us,
just on a personal use, we probably use it every day, right,
we probably just either look at our phone or yeah,
use our fingerprint on our phone and where we're we have,
we're authenticated with it, We're confirmed, identity is verified. But
it's also moving into the applications that we use for businesses.

(14:57):
Maybe it's your favorite, I don't know, a third party
app that you use that is also starting to move
to that because it's becoming easier. So the idea of
moving beyond physical devices that help with identities such as
those keys or security cards or pivtcards or things like that,

(15:18):
have now moved into things that you always have on you,
like your fingerprint right, well except for the winter when
when it's very dry, that could be a problem, but
you have your eyes or you have your face and
that you can use that anytime. And now we have
this idea of being able to pass that verification through
your favored ecosystem device. Ecosystem will say and that's what's

(15:42):
called pass keys. So that can also make things even easier.

Speaker 3 (15:51):
Because I use.

Speaker 6 (15:54):
I'm just I'm curious because I use pass keys for
everything that kind of like supports passkeys, right, But I
don't really I never actually looked into why how oh
why on how networks same?

Speaker 2 (16:08):
I know the respec, right, it's like the web off
web off end whatever it is.

Speaker 3 (16:13):
There's a spec.

Speaker 5 (16:14):
Yeah, yeah, it's a. It's a it's a combination of two.
Actually it's web often so that's a you know, a
new API as well as using the phyto two authenticators.
So it's it's actually you have to have a device
as well as a as well as using web of
then so your browser application has also support it.

Speaker 2 (16:37):
So I'm just going to say, as an Angular developer,
that sounds like something I probably shouldn't be coded.

Speaker 3 (16:45):
I'm just guessing it seems.

Speaker 8 (16:47):
Like I should probably stay in my.

Speaker 3 (16:49):
I should probably stay in my lane here.

Speaker 2 (16:51):
That seems like I gotta go read this spec you said, Fido,
I think, dog, I don't know what that is?

Speaker 3 (16:58):
Like? What am I left in you here? As a
as an Angler developer.

Speaker 5 (17:02):
Yeah, fair enough, I totally agree. I would also absolutely
mess it up as well. So here's the thing. Well, one,
the idea of past keys is still getting really vetted
and figured out and how it can grow and evolve. Right. So,
and I think as developers, most of us have a
product to get out the door. We're not we don't
want to spend all day doing authentication. That's not that's

(17:24):
not the value that we bring to the company, nor
is that what the company wants us to keep doing.
So we really should just rely on and delegate that
out to a company that where there that is their
full time job and can figure it through them. So
that's using an identity provider, and it could be any
there's paid ones if your company requires paid ones with

(17:45):
like threat you know, insights and all sorts of things.
And there's also free ones that are OSS or open
source right that you host yourself. So what's your voy
you want to go? You should really just leave that
to those people and we can focus on things that
are really important for us to get our product out
the door and rely less.

Speaker 4 (18:06):
Than I learned in software engineering was don't roll your own, right,
I just don't.

Speaker 5 (18:14):
Just don't.

Speaker 6 (18:15):
Yeah, I have a question, so I mentioned off at
the beginning because I kind of like the person that, oh,
like the authentication story for uh the NX product, even
though like I do understand, Hey, don't roll your old
off U used like a third party identity provider. Well,

(18:38):
that was our customers use, right, So for I guess
like connect to SAMO or all off that's our customers use.
But as a developer, I would still have to code
the integration with that h third party. So I guess
my question is will there be or ease there anything
that kind of like alleviate job of the developer to

(19:01):
integrate with all of these like different part different part
of the ecosystem, different apps, even though yeah, that guy
uses top of the lie identity provider, but I mean
I don't.

Speaker 5 (19:14):
Yeah, right, absolutely, Well, I think there's a couple of
things here that we can discuss. One of them is
if you are building, if you are bringing an authentication
into your application, is that you should be using either
the SDK is provided to you buy your identity provider,
or you should be using an open source SDK that

(19:38):
is certified right embedded for your authentication standard. And I
say that very ambiguously because I do recommend. I feel
sorry for you actually right now having to deal with Samuel,
because that sounds really awful with all that XML. But
I like to use authono I d C right, so
open id connect and oh auth they have standard certified

(20:02):
libraries that you can utilize, and also they are open
source available. I recommend using one of them, so you
don't as long as everything confirms the suspects. You just
add those configurations pieces and then it should handle that
authentication part for you, and then you could just move
on from oh, I have an authenticated state and it
is good. Now, how do I want that? How do

(20:24):
I want to work that into my application? Right? How
do I want to now enforce access controls or whatever
that might be. And then the other way you might
want to consider is delegating log into somebody else as
an sso it's a single sign on, say so social
identity saying, oh, log in with my Google credentials or
log in with whatever else that might be, and then

(20:46):
going that way, and a lot of larger applications such
as you know, we'll pick on Google again has that
ability to say, you know, ad ad Google as a
social provider for my authentication and then you just need
to bring that in into your into your app. They
have SDKs and they have that support as well, and

(21:08):
then you could also utilize that for SSO for your
enterprise customers. So let's say your bank uses I don't know, well,
we'll just pick on Octa for example. Because Octa is
you know, a big enterprise sort of I d P.
They use Octa, and you have your your application that
this bank wants to use. You can just then say

(21:30):
delegate the authentication to doctor with an S s O
and then you don't have to worry about it, so
you don't have to write that code in a customized
you know, customize the code for yourself.

Speaker 3 (21:44):
Yeah, and then stuck though.

Speaker 5 (21:48):
Yes, yeah.

Speaker 4 (21:52):
As a user, it's such a better experience too, because
then I mean, if I can choose to log in
with a different like a provider that's already set up
for me, then I'm going to do that because I
don't have to make a new password. I don't have to.
Like it kind of gets around that password issue. I mean,
I still have a password for the provider I've chosen,

(22:14):
but it just it makes things a lot easier. I'm
always so happy and I'm like, oh, good, I used this.

Speaker 6 (22:25):
The thing is, I don't I don't mind samol or
anything of that that, but it's just like there are
so many different providers, and each of them has slightly
different configuration, especially like SAMIL that you have, I guess
Azure Opta ping identity. I don't even know what that is.

(22:45):
Somebody just came in and say, hey, do you guys
support ping identity?

Speaker 3 (22:47):
Like what is that?

Speaker 8 (22:50):
I don't know?

Speaker 3 (22:53):
Probably not supported.

Speaker 4 (22:55):
Maybe are you talking about schmishing again?

Speaker 3 (23:02):
That was good, so Alisa.

Speaker 2 (23:07):
So so the biometric stuff, if I understand correctly, I'm
a as a web developer, I'm not like coding against
the biometric like device or whatever.

Speaker 3 (23:17):
Right, I'm not writing C plus plus or whatever it is.

Speaker 2 (23:20):
Right, So I kind of hand that off through like this,
you know, API or whatever it is, web off N
and that kind of thing, and my browser handles that
or whatever it is.

Speaker 3 (23:31):
Then native kind of.

Speaker 2 (23:32):
Platform handles that that the actual biometric part of it,
and then your recommendation is then actually do all that
integration with web N and all the kind of the
pasty stuff is use an open source library or or
a service provider, an identity IDPs identity provider, identity provider provider.

Speaker 3 (23:55):
Identity provider to kind of middleman.

Speaker 2 (23:59):
That is, that's the right way to think about this,
as like an angela developer. So I bring in this
SDK from Octa zero or Azure or whatever it is,
and then they kind of handle some of the nuance
around that, and so I'm just using their API. Does
that lock me in though, to that particular identity provider?
Am I kind of locked in at that point because

(24:20):
now I've integrated directly with them? Or kind of what
does that look like? What are kind of the pros
and cons of making those choices?

Speaker 5 (24:29):
Yeah? I think the I do recommend using an identity
provider to handle that for you, because how you would
normally authenticate or the safest way, so purest way to
authenticate as you are redirecting to the identity provider's page
and letting them, yeah, host what that sign and page
looks like, and then it refrects back into your application.
At least it is that way for open id connect

(24:50):
the what's your second question?

Speaker 3 (24:55):
Oros and cons shoes?

Speaker 8 (24:58):
Yeah, like I get it seems.

Speaker 2 (24:59):
To me, and I don't know, this is just my experience,
but it seems to me like I'm going to defer
to an identity provider.

Speaker 3 (25:06):
I'm going to use it.

Speaker 2 (25:06):
There's some sort of open source provider and maybe kind
of roll some of my own code, or I'm just
going to reach out and use an existing provider out there.

Speaker 3 (25:15):
What are the pros and cons of kind of choosing one?

Speaker 2 (25:17):
What are the pros and cons of like using or
not using an identity provider?

Speaker 3 (25:21):
You know? Where?

Speaker 2 (25:22):
Might I want to just you know, bring in an
open source library and kind of do it, might do some.

Speaker 3 (25:27):
Of it myself. Kind of it feels like there's a
lot of.

Speaker 2 (25:30):
Trade offs in those various options, and so I'm just
kind of curious broadly speaking, and I imagine every every
implementation is slightly different, but broadly speaking, what are some
trade offs sources?

Speaker 3 (25:41):
Like I'm going to do the whole thing myself.

Speaker 2 (25:43):
I'm going to just use like a library, open source
and kind of maybe roll some of the things around
that versus like a full on identity provider, and I'm
going to defer to them to do pretty much all
of that stuff for me.

Speaker 5 (25:54):
I'm going to suggest a highly recommend to always use
an identity provider. Again, it doesn't have to be a
paid identity provider, because what you're going to get from
that is you're going to well like a stepping back
if you're implementing authentication for as a first you know,
now I'd recommend it using open id connect and then

(26:17):
using like oh ath if you you know, at two
point zero underneath the covers, if you need the access control.
So if you do that, then you can follow. What
you want is you want identity provider, a trustworthy one
that will provide that authorization server for you so you
don't have to stand your own of that. And you're

(26:38):
you're like, let's I'm gonna pick on kick isn't the
right word. I'm going to select key cloak as an example. Right,
it's it's open source. Yeah, so you don't have to
pay for it. You can, you'll just find a way
to host it someplace out on the cloud, right someplace,
but you don't have to to pay for it. If
it's following the specifications of open ID and connect connected, oh,

(27:01):
you should then be able to say, at some point, oh,
I am tired of paying some cloud company lots of
money to host this the server anymore. I want to
now use a just a fure cloud hosted SaaS solution
from somebody else. And then you should be able to
just point over the configuration now on the back end,

(27:21):
if you make a lot of changes though then yes,
I think it will be difficult to unwind from it. Right,
So if you do all sorts of very specific configurations
that is supported by key cloak, finding that those sort
of configuration options available in another IDP might.

Speaker 3 (27:39):
Be difficult, so understood.

Speaker 4 (27:42):
Yes, I feel like anytime you're using a third party
provider for literally anything, whether it's authentication, whether it's feature flags,
whether it's your grid, like, you should always insulate your
application from the provider specific code. Like you don't want
to and I know this from experience, you don't want

(28:04):
to integrate deeply the implementation for one provider all through
your application because if at some point your management comes
in and says we're not paying for that anymore, then
you get to spend the next you know, five sprints
desperately trying to pull all of that back. So the like,
anytime you're using anything third party provider, I highly recommend

(28:26):
figuring out like that sort of the wall between your
app and the wrapper that you've created to manage that
service for you.

Speaker 3 (28:35):
Yeah, for sure, for sure.

Speaker 4 (28:38):
So there are changes, right, Like, things happen all the time,
especially in security and authentication. There's advancements that happen, Like
you may want to switch. Maybe you were on a
less robust solution and you need something more robust, Like yeah.

Speaker 5 (28:55):
Yep, absolutely, that can absolutely happen.

Speaker 3 (28:58):
I think it was interesting that you mentioned that key Cloak.
I've heard of them, and I've heard of a couple others.

Speaker 2 (29:03):
But yeah, so this is kind of like that maybe
that middle solution that I was kind of talking about.
So instead of like rolling my own versus going all
the way to an identity provider, there's kind of that
middle solution of like I'm going to get some sort
of open source, kind of well tested, well trusted type
of thing, and then I'm gonna you know, containerize it
deployed into my own infrastructure or whatever into my cloud infrastructure,

(29:27):
and then I'm gonna like use that use their APIs
and that kind of thing, so that way I can
still run it locally rather than like a SaaS provider.
So I have to imagine, and it's just me thinking
out loud, like Opta and some of these id pis
they must have on prem solutions as well, right or
is it all SaaS?

Speaker 5 (29:48):
It is all SAS, I believe, Okay, Zero, I don't
know what they if they have an on prem.

Speaker 3 (29:59):
Ch'all knows.

Speaker 6 (30:00):
Uh they do, they do have on prem.

Speaker 3 (30:05):
But it's uh containerized.

Speaker 6 (30:08):
Yeah, but but but but also there's uh that like
their on prem opera is a little bit weird and
I'm not sure if I'm speaking the fact here, so
take it with a rand of salt, is that we
do have a couple of on prem customers that using
all off zero, but it's through US we manage those
instance or tendons for them.

Speaker 3 (30:30):
Ah interesting, okay, gotcha.

Speaker 5 (30:33):
Yeah. I do know that if you have a very
specific like especially GDPR with you know, European rules, if
you need to have your instance hosted in very specific
regions like that is possible for both zero and.

Speaker 2 (30:51):
I would think, so yeah, you can just kind of
cheat the region or maybe have like duplicates or like
US region, euro region or whatever it is, and it'll
kind of it'll handle hopefully some of that synchronizing and
all that kind of stuff for.

Speaker 3 (31:04):
You, which might be kind of a complex but very cool.

Speaker 2 (31:08):
So you you kind of talked, We talked about the
biometrics and that kind of thing. We talked about kind
of some of the pros and cons. We talked about
kind of some different choices you might make as an
Angular developer. What are some of the other kind of
specs that are on your radar as a developer advocate
that are either in draft or are kind of newish,

(31:30):
or that kind of thing that you want to kind
of educate the community about.

Speaker 5 (31:35):
Absolutely, this is where it gets really exciting. There's some
really cool things that have already come out or on
the cusp of coming out. So two that have already published.
And this actually happened last, so not October twenty twenty four,
but I think October twenty twenty three. It's really started
to gain some traction now. One of them is called

(31:56):
step authentication challenge, and I actually covered this last as
a little hands on workshop, And that's the idea where
during the authenticated state, there might be a time where
you need to have extra identity assurances about the user.
For example, let's say that let's say that you have

(32:17):
user dam password as your authenticated state, and then all
of a sudden in your app, you want to have
the user perform and action that requires some extra verifications,
such as they're making a really large financial transaction, or
maybe they're doing something a little bit more sensitive in
an admin section, and you want to have extra identity assurances,

(32:39):
you can bump up the factor of authentication for that
particular task, so you can say, now I need you
to send back in or I need you to add
a secondary factor of authentication to perform this action, and
there is a spec for that. There wasn't a spect
before to do that in a standardized way, so that
was really cool. And then another one that I think

(33:02):
is pretty interesting, I think very helpful for Angular in particular,
is well, we know that Angular is a browser based application,
which means it can't keep secrets right. We can just
open up the developer tools and see just about everything
in there, which means that it's highly vulnerable if somebody

(33:23):
is able to steal your sensitive tokens that you got
from after authenticating. The spec for demonstrating proof of possession
or DEEPOP is one where we can add possession proofs
to the tokens that only ensure that the person from
who that access token was issued too is the one

(33:44):
that could utilize it. So standard ooth uses you've heard
everybody knows or has talked about, like oh, I use
a JOT or I use adjacent web token a bearer token.
Bearer means that anybody who holds the token can use it.
So if somebody steals it and they can replay things,
then they can perform whatever sensitive action that you are

(34:08):
trying to guard. There's ways that we try to ways.

Speaker 10 (34:11):
To manipulate those too, right, Like I was, I actually
sat through a conference talk I think it was one
of your colleagues a couple of years ago that went
through how easy it is to actually manipulate a jot
if yeah, how to protect it?

Speaker 5 (34:25):
So hacking go ofth Yes, yes, that's one of its
popular things. So, yeah, so what you don't want to
do is allow for that token to get in somebody's hands.
And we can do things like decrease the timeline the
length of time that the token is valid, and that's
standard way to go. Yeah, But another option is to

(34:49):
add a possession proof that is associated with the token,
and it is required for every call that you make,
and you have to create a new possession proof for
every call you makes. You can't reutilize the token. You
can't reutilize even the same interesting yes, and with this,
what you're doing is you're using asymmetric encryption to sign

(35:11):
everything together as well. So you do have now a
private key that you have to make sure that you're guarding,
but it doesn't have to be in the same storage
options perhaps that we're using before tokens.

Speaker 8 (35:23):
So tell us a little bit more about that.

Speaker 3 (35:26):
I'm curious as best as.

Speaker 2 (35:28):
You're able to anyways, So before I put this bearer token,
I don't know you stuff it anywhere. You can just
keep it in memory you really want, right, that's maybe
the best place.

Speaker 3 (35:39):
But if you want to.

Speaker 2 (35:40):
Make it more permanent, maybe I put it in like
an SSL htt only cookie, or I can put it
in local story if I.

Speaker 3 (35:47):
Want, you know what I mean.

Speaker 2 (35:48):
That's a commonplace to kind of kind of toss this
little uh this little string help nobody goes sniffing into it.
But like, tell me the difference between that and what
you just mentioned in terms of like I still have
this You mentioned you still have a private key is
deepop And maybe I just caught on that one particular
aspect of what you just said.

Speaker 3 (36:05):
So you said a lot of great things.

Speaker 2 (36:07):
There, But tell us a little bit more about Yeah,
let's dive into that a little bit. So I self
have to have a private key, I self to kind
of sign everything on every request. That feels as an
uninformed person, that feels like a.

Speaker 3 (36:18):
Lot of work.

Speaker 5 (36:19):
Yes, it definitely it does. It does feel like a
lot of work, and it's a lot of extra overhead
for sure. But if you're in a really sensitive application
or you're performing an extra sensative past like asking for
this tokens in the first place, then that's where it's
really where you know, you do financial application, that's where
it's really important to have this right. There was a

(36:42):
way to do this in what's considered confidential clients, so
that means that there are applications that can maintain secrets,
of which Angular and SPAS are not. They're considered public
clients because everything is open, we can see everything. So
in confidential clients and those sort of systems, there's way.

(37:02):
There was ways before where you can have an extra
level of security. You could use even network encryption with
mutual TLS and things like that, but that isn't possible
for public clients like Angular. So this is where it's
really interesting. Business is really made for this spec is
made for spas, so this is where it could be

(37:25):
really really useful. Now that token or that private key
we do have to guard it. The only place where
we can really do that is an index dB, and
then we also need to business not you can't extra
filtrate it. And then we also use like the crypto

(37:46):
APIs to only use like only referred to it by
hashes and such. So that's the way we can keep
everything secure. And yeah, it's actually pretty cool to walk
through this. I do have a post where we walk
through the you know, curl commands, seeing it in the browser,
things like that, and it is kind of interesting to
kind of pick it apart to see how that works.

Speaker 3 (38:08):
Got it. So you've got a there's a public key,
private key.

Speaker 2 (38:12):
The client kind of stores this private key and then
uses that to kind of sign this is again kind
of sign every request, and then the servers and has
also like has a private key I soon or whatever
or the share public key, and then it like off
like verifies each request.

Speaker 3 (38:32):
Is that what's happening?

Speaker 5 (38:34):
Yes, that is correct. So I should point out the
when we're now sending requests from Angular, we're sending two
pieces of information. We're sending the access token, which has
the proof built into it, right to job, but we're
also sending up the proof itself. So the proof, the
proof itself is what has the access has a reference

(38:55):
to the access topen and we've signed that. Yeah, so
we've signed the method that we're calling. We're signing the
endpoint that we're calling. And oh oh yeah, it's really interesting.

Speaker 2 (39:07):
It's not just a global like trust me, trust me,
I can do this. It's like no, no, no for this,
this request, this HTTP verb whatever, it's.

Speaker 3 (39:17):
Like the whole like thing. It's like, I have access.

Speaker 5 (39:20):
To this right and very agree that. Not only that,
you're also adding a length of time of which this
is valid, so there is an issued at time and
you'd be checking that as well as adding a unique
ID for the job. So the proof is also in
JOT format, so you're also adding a unique ID to that.

(39:41):
So it can't even be replayed. Even if you are
making the same you get users called twice.

Speaker 3 (39:48):
It also kind of sounds like a pain in the
butt as a developer.

Speaker 2 (39:50):
I can't do like write click replay x HR and
my develop and my current and my dev tools.

Speaker 8 (39:55):
Oh yeah that was with me, dude, you're hamstering and MEO.

Speaker 6 (40:05):
Yeah, now interesting, Yeah, all of that information is really
really cool. Now, but I want to kind of like
ask a question very specific to Angler. So, uh, you know,
we all know that Angler is kind of like going
to the direction of like silver side rendered first, right,
and most of the stuff, most of the authentication stuff

(40:26):
that we've seen related to Angler before in terms of
like resources online, it has always been client sided only authentication.
So do you have any strategies or any resources to
go into like a servi side rendered first, especially for Angler?

Speaker 3 (40:41):
But developers, great question.

Speaker 5 (40:45):
Yes, so the this actually leads into the upcoming speck.
Now it might even be I think it's still a command.
I don't think they published it yet that you had
also asked about, Brian is the token. It's actually oh
OFF Security best Practices for browser based applications, and it

(41:06):
talks about patterns to use for angular right and for
a client side authentication like what cha was mentioning, but
also brings in recommendations and patterns for delegating that authentication
to the back end. So you have like token mediation,
or you have patterns like a back end for front

(41:29):
end by BFF where you're saying the back end the
one actually does the authentication handles the tokens for you.
You don't even pass the tokens over to the front
to the front end at all, and then you would
have some sort of a authenticated state, you know, session
cookie or something like that.

Speaker 2 (41:45):
You would have a session cookie so server to identify you.
But then it's persisting those tokens in a wherever, database memory,
whatever it is however, yeah, read it whatever, It's got
some sort of yeah hash table that pulling it from
to actually hold onto the tokens, and then kind of
it's like almost like a secure proxy if you want.

(42:07):
I don't know, that's the way I'm thinking about, right,
kind of proxy and all my requests and it's going
to go out speak to the other a PI S
or whatever it is, could be other internal APIs or
micro services, bring that back and then kind of send
it back down to the client. The way the client
isn't pulling on to the keys.

Speaker 5 (42:22):
That is great, And in some cases you actually wouldn't
even send the token at all to the front end,
so the front end has no idea as token, right,
everything is delegated.

Speaker 11 (42:30):
To Yeah, you could have a cookie that yeah, yeah, yeah, dude, like.

Speaker 2 (42:44):
I don't know, like yeah, I mean, it's all good,
but it also feels like, I don't know, this just
feels like a lot.

Speaker 3 (42:52):
Yeah.

Speaker 5 (42:53):
It is hard.

Speaker 6 (42:54):
Yeah, it is hard. It is hard, and especially when
you when you get into uh like thing that custom
would asked for like how secute, how secure you app Yeah,
they were like, I don't know, right, So that's hard.

Speaker 3 (43:11):
It's really hard. It is really hard.

Speaker 2 (43:13):
Yeah, and I think maybe this is why the bank
that I've been working with, they just do everything to
Windows Authentication and make you Citrix in, but then they're
paying the Citrics overlords. Which yeah, so anyways, very interesting. Yeah,
so we talked about DEEPOP. I was looking at an

(43:33):
article and I don't know if you know the question
to this, so bear with me. I apologized, but I'm
looking at an article. I'll drop this in the show
notes so those people that are listening can kind of
follow along. But I'm looking at a Microsoft article about
DEEPOP and it says there's like a warning kind of
at the top, and it says, hey, the strength of
the pop protocol depends on the strength the pop keys.

Speaker 3 (43:53):
Microsoft Frimen's recommends using hardware keys via the Trusted Platform
Module TPM, where possible. Do you know anything about that?

Speaker 2 (44:01):
I've never heard of this hardware keys? Is that something
that's in your realm or not?

Speaker 3 (44:06):
Really?

Speaker 2 (44:08):
I know I'm dropping. This is like I feel I
should not have. Maybe we'll put on some Jeopardy music.

Speaker 8 (44:15):
There's something here I should not have, Like I feel
like I do this? Yeah yeah, yeah, right.

Speaker 4 (44:20):
Act can you provide the music?

Speaker 5 (44:22):
Laura?

Speaker 3 (44:22):
How's your house sale going? Well?

Speaker 8 (44:26):
Here is a good good score about this.

Speaker 11 (44:29):
Yeah.

Speaker 5 (44:30):
I do have to wonder though, if this is actually
going to be applicable for Angular because it says that
it's a Microsoft authentication library for gotten net, so that
might imply that it's for a confidential client. It is
not something I'm familiar with.

Speaker 2 (44:43):
Okay, I appreciate you. Yeah, I was just like, oh,
I've never heard of this. Okay, go ahead, Laura.

Speaker 4 (44:49):
I say so, all right, Say, I'm an Angular developer
and I'm feeling like super overwhelmed right now because I
just have a like relatively small client. They just need
to be able to log in. Like how much do
I have to know and understand to prevent.

Speaker 5 (45:07):
This? Yes? Yeah, that's exactly I think. And that's most
of us, right, I mean, honestly, once again, we all
have to get out the door, but I don't, like.

Speaker 4 (45:17):
I don't work on the security team, Like we have
literally a team that does all of that for us.
Like could I go work over there? Sure, but that
would literally be what I do. And so you know,
but then you get into like smaller clients where like
my first job, I was the security team and so
if I made a mistake, I would be the one

(45:38):
that handed the keys to the bad guys. And so
so yeah, like what are what are some of your
recommendations to help people in that situation? More specifically, I
guess where you don't have a whole team of people
whose literal entire life is worrying about security.

Speaker 5 (45:57):
Yes, I would definitely use an identity provider and let
that be their problem. And there's there's there's all different
price points, right, so it's being talked about some free ones.
There's all different price points depending on what your needs
are and how much threat detection and customization and the
feature sets that you might need. Then always use the

(46:19):
standards of good quality standards. And I'll just say that
if for me, it'd be using open ad Connect and
no off and use a certified libraries for that, And
then with that you're really in good shape right that
you have a lot of it. Luckily for us, Angler
has a lot of built in capabilities to protect you
from making really bad security mistakes, really like terrible ones.

(46:44):
So we have some protection there. But that's uh, I
think that really gets you a good way through. There
are free tools if you are really strapped and you
know in a buying there are some free tools that
you can utilize to help check for builder bile, a
wasp has a lost zapp and such that you can

(47:05):
use to run against your application to make sure that
you've got some of those big issues addressed. So they'll
probably gets you a good part of the way. Yeah,
this is yeah, I get it. This is tough. Yeah.
So okay.

Speaker 4 (47:19):
One thing that I encountered when I worked when I
was the lonely sad loan developer, we went through a
security audit and we had to prove our security. I
know that for example, with Angular, any of the dependencies
that Angular pulls in Angular, like Google vets those for

(47:40):
their internal security. And so my company, if I'm using
Angular inherits the security that's been vetted through Google. Is
that something that authentication providers do as well. So you
can say I use ooth, here is their security audit,
Therefore I inherit their security If that makes.

Speaker 5 (48:01):
Sense, I'm not. I mean I think you would in
terms of the library that you might be pulling in
Perhaps cence that is the case, but I'm not sure
that would be necessarily applical before an entire application security audit.

Speaker 4 (48:17):
Oh no, no, yeah, definitely, because you'd still have to
prove that you weren't like doing something like oh, I'm
just directly putting whatever they told me to print onto
the page, Like there's top ten stuff that you still like.
Just because you got your authentication down doesn't mean you're application.
There's still like a whole other department of ways people

(48:37):
can fork up your system.

Speaker 5 (48:40):
So right right, yeah, exactly, Yeah.

Speaker 6 (48:45):
But yeah, kind of like right on top of that,
we actually had an audit before and they mentioned that
if you use a third party off oh a specific
library or providers, then the most important few is a scope. Yes,
so it really depends on like the scope that you're

(49:07):
requesting from the provider that might affect the audit result.

Speaker 5 (49:14):
Yeah, absolutely fair enough. I mean, at least privilege still
applies to to a lotoscopes and what sort of actions
people can perform, right, it's not just a dB sort
of thing.

Speaker 4 (49:28):
Yeah, because you can still like mess up authentic like
you could if you give everybody admin rights, like oops,
that's right.

Speaker 2 (49:43):
I'm curious child. Have you done any authenticy Have you
done some of the stuff with server side rendering with Angular?

Speaker 4 (49:50):
I have not.

Speaker 6 (49:51):
I yeah, I've just been playing with Brandon and Analog Jazz. Yeah, yes,
sense okay now, but but for server side rendered in general,
just like Alissa mentioned, you would just do everything on
the server side and the client would just have like
a surrender secure HD only cookie, well a very minimal thing.

Speaker 2 (50:15):
Yeah, and so then you but then so you wouldn't
you would never provide the token down to the Angular
server or the Angular client in this case, right, they
would just have a cookie to the back end, and
then you just use.

Speaker 3 (50:26):
Like uh like whatever Express or middleware on the back
end to kind.

Speaker 6 (50:31):
Of pretty all of that pretty much every single So
if you have if you use like a server technology
that has a middleware like Express, then yes, you would
have like a layer of middleware to check every cookie
that coming in.

Speaker 3 (50:46):
Yeah, yeah, yeah, that's it.

Speaker 5 (50:50):
Yeah.

Speaker 3 (50:50):
So in a server side rendered world, so to speak,
with Angular.

Speaker 2 (50:56):
You're obviously the first render, everything comes back from the
server and you kind of bootstrap or lazily kind of whatever. However,
you kind of wire everything up and you get to interactivity.
And then when the user starts interacting with the application
and actually starts to make a request, then you're you're
not going to go directly to like that third party
API or whatever it is. You're always going to still

(51:16):
loop back through your your server side.

Speaker 3 (51:19):
Is that what you're saying.

Speaker 6 (51:21):
Uh, it really depends on uh the I guess the
ttail of the of the actual data. So it's like
like user doesn't really change much, user information doesn't really
change much. Yeah, we have a separate thing for like
user configuration that can change. But then the user like
the email that actually comes from the identity provider Avatar,

(51:44):
all of that stuff we stall in in the memory
of the client when as the client first rendered.

Speaker 5 (51:51):
And that's it.

Speaker 3 (51:52):
Yeah, it's been a while, but I did.

Speaker 2 (51:54):
I did some service side rendering rendering with Universal, so
I know that dates it with Firebase, and so with
Firebase psych you basically like they give you like.

Speaker 3 (52:04):
A server key or something like that. I think you
know what I mean. Kind of a long lived server
key or whatever, and then your.

Speaker 2 (52:11):
Back end is kind of communicating to Firebase, but then
the client still talks directly to Firebase after that, and
I'm not sure, I don't remember how that works. If
maybe you just pass it down as part of like
a Jason payload and you or what happens, but not anyways,
I'm kind of getting off topic, but that's interesting, and
that you know, the service side rendering solution, though I

(52:31):
don't suspect a lot of Agular developers are using it
in proad yet, but it does lean towards a more
secure environment for sure.

Speaker 3 (52:40):
However, perhaps a little bit more work because.

Speaker 2 (52:43):
Then you're kind of you're still going back to that
Express server or whatever, and you've got to write some
of those those API nd points except that cookie, valilate
that cookie, and then go off and make that request
on their behalf or whatever it is or whatever. Right,
it sounds like so much to work for the Angular
developer as well.

Speaker 8 (52:59):
Yeah, could we.

Speaker 4 (53:00):
Cover infrastructure you're also supporting the Express server, like there's
there's it's not like just free to I mean, we've
been down this path with service rendering, like like, oh,
this is great oh wait, but then we're also then
we're adding this layer that we have to pay for,
and then this other layer authenticate we got to figure

(53:21):
out and and so yeah, there are extra it's extra
work involved.

Speaker 2 (53:26):
Yeah, and then everybody just goes back to client side
rendering in twenty twenty seven.

Speaker 3 (53:30):
Okay, yes, right, there is there is one way, are right?

Speaker 5 (53:36):
There is one more twist to this though, instead of
so one other option than this is actually in that
up coming expect for browser based security is instead of
headling your back end handle your authentication, you could also
have a web server or sorry, a service worker handle

(53:56):
it and hold the tokens as well. So that is
another pattern. I know that it is also being used
not by me, I haven't tested it, I haven't played
with it, but it is being used by other any
providers for like next JS.

Speaker 12 (54:09):
So cool cool, Also real quick, while you made me
think of it, you also I want to go back
to something comment that you made earlier, just in terms
of like I think you were talking about story and
the key.

Speaker 2 (54:21):
Maybe it's a private key for the DPOP and you
mentioned index DV. Can you if you want, if you yeah,
why is that? Can you kind of shine some light
on that side. I haven't heard that before.

Speaker 5 (54:34):
It's something that is harder to be to extrapolt traite
data out of because it can't be like you can't
use like cross site scripting to like dive into it.
So it's a more secure way of holding information.

Speaker 3 (54:47):
It's also harder to yes, So yeah, yeah, I've used
it in the past.

Speaker 5 (54:53):
Club workers, So.

Speaker 2 (54:56):
Yeah, interesting, Okay, I love I love being on the
show because I get to learn fool things like this.

Speaker 3 (55:02):
So that's all the questions I have.

Speaker 2 (55:05):
Lara Chow, is there anything else that you wanted to
kind of dive into before we start wrapping up?

Speaker 3 (55:10):
Good?

Speaker 4 (55:11):
For now, I don't have any more questions specific to that,
But Alisa, do you have any I know you are
a speaker out in the conference scene. Do you have
any upcoming events or anything you'd.

Speaker 5 (55:22):
Like to pitch? I do not have any upcoming events
right now, and it's really interesting. By now, I usually
have a couple of things that I know I'm going
to yes, and so I'm kind of enjoying my my
winter and some upcoming vacations without having to worry about
writing some conference talks. Nice eventually, though, I am looking

(55:45):
I'm excited about some of the like I saw Jide
is planning again later this year, so definitely excited about that.
I know the Energie Rome is also an energy poland
those are all once I spoke at last year, and
I would love to return to them all becas there
were fanstastic. So yeah, kind of keeping my eye on those,
but otherwise right now enjoying, enjoying the time without for

(56:10):
real projects.

Speaker 7 (56:12):
Like when we joined the call, I was, like I wrote,
I had two weeks off and I wrote exactly zero
lines of code.

Speaker 4 (56:19):
I didn't even turn on my computer.

Speaker 5 (56:23):
In fact, the.

Speaker 4 (56:24):
Only reason I came in my office was to rearrange
it because I decided that it was bad.

Speaker 5 (56:31):
Yes, that's completely so. One of the questions that I
was asked before joining the podcast today was what are
my passion projects? And I thought, oh, my goodness, I haven't.
I don't have any code. Once. I did come in
my office during my time off as well, and I
set up this light behind me. That's that's all I did. Yes,
thank you, thank you.

Speaker 4 (56:52):
Yeah, that's it.

Speaker 5 (56:53):
And it was really nice.

Speaker 4 (56:55):
Yeah, I did really cool stuff, like we replaced two
toilets in our house. Really work Yeah, if you're wondering listener,
it's easier than you think. As long as you can
pick up a toilet, you can replace a toilet.

Speaker 3 (57:15):
That's it. That's the quote. If that's your next that's
your next blog title. As talk about.

Speaker 4 (57:24):
Home plumbing this year. So if anyone wants me at
the conference, just you know how to contact me.

Speaker 5 (57:32):
Some really good pictures.

Speaker 3 (57:35):
You can keep the pictures. I think we'll fasten the pictures. Alisa,
thank you so much for coming on the show.

Speaker 2 (57:42):
For those of you that want for our listeners that
are looking to kind of follow you online or maybe
have some questions or want to get in contact with you,
what's the best way to do that on LinkedIn?

Speaker 5 (57:54):
Uh, you can follow my link Jay Lisa Duncan and
I think that's probably the best way right now.

Speaker 3 (58:00):
Fantastic, and we'll get a link to that in the
show notes.

Speaker 2 (58:03):
For those that are listening ATLISTA, thank you so much
for coming on the show. It's always been a pleasure.
We've had you on the show many times over the years,
and it's always been a pleasure to kind of get
the latest and greatest kind of keep us up to
date and keeping our apps secure. And also kind of
scaring us and also kind of like overwhelming us. But
you did what you do it in such a gentle
and warm way that I really appreciated. So it's like

(58:25):
it's like going to the dentist. I feel like really
good about it.

Speaker 4 (58:28):
Like, just use an identity provider, You'll be fine. Just
literally here, here's the sticker. It says, use an identity
for provider. Just put it on your lap stop take away.

Speaker 5 (58:39):
Yeah, thank you so much for inviting me. It's always
fun to be here. And yeah, there needs to be
a support group after this. We could totally do that.

Speaker 2 (58:49):
I think Chiao would love it if you just stayed
on the call and paired with him for an hour too.

Speaker 8 (58:54):
Yeah, maybe get over his off broad issue.

Speaker 2 (58:58):
Hopefully that resolves quickly for you. Great well, Thank you
so much, Chad, appreciate your time today. Laura of course,
thank you so much for being here. And a Lisa,
thank you so much for joining us into the listener.
Don't forget to subscribe. Thanks for joining us, and we'll
see you next time.

Speaker 3 (59:14):
Bye bye bye.

Speaker 13 (59:33):
Hey, this is Pressol. I'm one of the ENNGI Champions
writers in our daily battle to crush out code. We
run into problems, and sometimes those problems aren't easily solved.
NNGI coomp broadcasts articles and tutorials from endie champions like
myself that help make other developers lives just a little
bit easier. To access these articles, visit medium dot com,
forward Slash, n gcomp.

Speaker 1 (59:54):
Thank you for listening to the Angular Plus show in
Jiecoff podcast. We'd like to thank our sponsors, the NGCOMF
organizers Joe Eames and Aaron Frost, our producer Gene Bourne,
and our podcast editor and engineer Patrick Hayes. You can
find him at spoonful ofmedia dot com.

All Episodes

S8 E14 | Auth for Modern Angular | Alisa Duncan

Episode Transcript

Popular Podcasts

New Heights with Jason & Travis Kelce

The Breakfast Club

Fudd Around And Find Out

.css-15opob5{left:0;position:absolute;top:0.8rem;} All Episodes

.css-14f5ked{margin:0;word-break:break-word;display:-webkit-box;-webkit-box-orient:vertical;box-orient:vertical;-webkit-line-clamp:2;overflow:hidden;}S8 E14 | Auth for Modern Angular | Alisa Duncan