The Auth Setting That Everyone MUST Change in .NET
Вставка
- Опубліковано 18 чер 2023
- Check out my new course From Zero to Hero: Logging in .NET and use code LOG20 at checkout for 20% off: bit.ly/loggingdotnet valid for the first 400 purchases!
Become a Patreon and get source code access: / nickchapsas
Hello, everybody, I'm Nick, and in this video, I will show you the most important JWT setting that everyone seems to be ignoring. That setting is called ClockSkew, and it has to do with how time-sensitive settings are treated.
Video explaining JWT: • What is a JWT (JSON We...
Workshops: bit.ly/nickworkshops
Don't forget to comment, like and subscribe :)
Social Media:
Follow me on GitHub: bit.ly/ChapsasGitHub
Follow me on Twitter: bit.ly/ChapsasTwitter
Connect on LinkedIn: bit.ly/ChapsasLinkedIn
Keep coding merch: keepcoding.shop
#csharp #dotnet
Check out my new course From Zero to Hero: Logging in .NET and use code LOG20 at checkout for 20% off: bit.ly/loggingdotnet valid for the first 400 purchases!
You just answered a question I had years ago and no one knew the real reason behind this, everyone said 'it depends on the server time' but did not know the actual reason behind it. Great content as always!
The client side token management libraries that I know of re-authenticate or use the refresh token to get a new JWT for the API call "some" time before the previously used JWT expires. Thus, a too low skew is critical mainly regarding the NBF in case the clocks differ and thus should never be set to 0. On the other hand the value of the skew has to be seen in relation to the JWT lifetime; with a lifetime of 8 hours the 5 minutes are less critical than with tokens whose lifetime is only 1 hour or shorter.
I believe the 5 minutes comes from an old Active Directory clock skew setting
That would make sense
Please elaborate a bit more. Why would clock skew be necessary in active directory?
I'm not sure if this setting is related to AD. However, the setting is intentionally designed this way. There's nothing novel about it, as its purpose is to avert any issues between servers and their time synchronizations.
AD needed clock skew the same reason cloud servers need it. Computers sync time occasionally, but it does drift, especially so in high-usage virtual environments. The reasoning for the 5 minutes may have come from the clock skew in AD, which I think defaults to 5 minutes, though I don't know that for sure.
Kerberos allows 5 minutes of clock skew by default so it probably came from there
Thanks Nick. Did not realise how large this value was. Just raised a Jira to fix it.
8:25 I always watch Nick at 3x speed so my impression of him is as a constantly extremely excited, over-caffeinated individual, so this bit where waiting was required was very amusing. I imagined a 3 second, six-scene jump-cut sequence of chair-spinning, rubix-cubing, screen-staring, and etc. before the video resumed.
I got the same impression at 1x 😂
@@JVimes One of the few UA-camrs, who I'd set the playback speed to be below 1.0
😅
Thanks for sharing ❤
Ha! I JUST went through this issue about a month ago. Great topic Nick!
I just went and checked what I'd been doing and I can see I've set it to zero already! I'd forgotten about this but had obviously come across it before.
Thanks! I ran across a “not before” issue related to clock skew in NGINX where NGINX was running in a docker container a few seconds ahead of the token generator. Thankfully, they have a “leeway” setting that accounts for clock skew.
As always, thank you. For me I always set this to Zero
Yeah many people choose to go with zero as the value, and it's not a bad choice, but in general allowing for 5-10 seconds might be a good idea as well.
thx for share
And added to my code, thanks for that good to very much be aware of.
Great video! please show the best way to renew the token before it expires
I like the way you swap shirts 😎
As always, thank you very much for your sharing your time and knowledge with us!
it's his business dude
@@simonaspacauskas56 I guess you're the type of person who complains about the applause given for a safely landed plane?
@@upgradeplans777 wow, applause to your comment, jerk
Nope I wasn't aware of that setting. Good to know.
Didn't know about this one, do know, and it only takes a few seconds to change and tighten up the security.
I was pretty sure it was this you were going to talk about, as it is rarely mentioned in any tutorials or guides out there.
Hey Nick, can you do a video for ConfigureAwait? You mentioned in the past the idea of making a video on this subject.
It is definately coming. It's just a pretty hard topic to find good modern example for, but I will make it work
Hi, Nick, do you have this and other code examples from your videos somewhere so I can download and check it by myself. Thank you for your videos!
nice didnt know this, i was wondering why it'd still pass and after a while stop working, figured was some weird server time thingy but its this
I guessed what's the security problem before you actually say it 😊
I don't ever remember seeing that property? 😕 How did I miss that?
Why would the default behavior be a requirement when designing that system? Especially for the NBF, that is crazy! The build should fail if this property is not overriden.
I really wanna watch Nick the Greek!
Hi! You make astonishing videos about backend technologies. I believe me and many other people too, are at a loss when we try to find ways to present backend data to users. Please if you will have time and desire, can you please make some videos how to properly add to dotnet rest api a frontend framework like react (cshtml with react as a library), next with ssr and request proxying, or maybe you know even better way than I can think of.
❤❤
Windows Server at least up to 2012(maybe now even?) only NTP sync'd once per week by default! So, you'd often get crazy drift on stock Windows VPSs. The more time stolen from the VPS the worse the drift. You had to update a reg value to lower the time. I wonder if this has something to do with these really large clock skew defaults..
During WCF days, client and servers time maximum can be differ for 5 minutes, otherwise wcf call would be rejected.There should be some agreement on this maybe...
You forgot an important part to the argument. IDP downtime.
I'm not sure where the original number came from, but it is so happens that 5 minutes is about the same yearly allowed downtime as 99.999% SLA. So if IDP has 99.999% SLA then 5 minutes skew will guarantee you that your service will never experience downtime due to IDP outage.
Additionally, while one can expect clocks to run fairly precise on servers, expecting it from a client machine is a stretch. My win10 machine is currently off by about 3 seconds with last successful sync being dated 2 days ago. Just this year I noticed that my phone and laptop had different times. Went to check - my laptop was failing to sync the clocks for aboutish 1.5 years.
Lastly, as some already suggested, 5 minutes is barely anything compared to token lifetimes that are usually >1h.
tldr: 5 minutes seems very much reasonable for most cases.
I figured out this feature out a year ago. Surprised how many people don't know about this
I don't agree it's a security issue. Yes, the token is valid a bit longer, but some accounting for clock skew is necessary. Sure, it would be rather unprofessional if your server clocks are actually 5 minutes apart, but be careful setting this too low as well.
Different situation, but recently some messages I was processing messages from an Azure Service Bus queue which were supposedly from about 30 seconds into the future, even though the server in question was synced to a reliable source. I'm not sure which side was at fault, but in the end it doesn't really matter. If it makes your entire system unusable because you set the clock skew too low, you won't be happy.
5 minutes can be a security issue because it gives potential token hijakers extra time with the token to do malicious acts.
@@nickchapsas If they can get your tokens, that is the security issue, not being able to abuse it a bit longer 😉
@@Thorarin Then just send a single long lived token 😂😂
@@nickchapsas
isn't this what pkce is for? Learning more about auth and I thought the whole point of pkce was to try to prevent what you said. Can you let me know if there's more to it?
@@nickchapsas I also think it's not really a security issue. It's like saying that increasing the token lifetime by 5 minutes is a security issue. It really depends on the context and how long you want your token to be valid. People don't even agree if an access token should be valid for 10 minutes or multiple days. For example for auth0 the default access token lifetime is 24 hours (at least that's what I found). 5 Minutes plus or minus doesn't really matter here and IF somehow the time gets out of sync between identity and app it won't be a problem.
Ahhh that's why!!!!
Do you have courses for beginners? For people that have some programming knowledge but not really any C# experience.
It's an older code, Sir, but it checks out.
Hey is this only checked if the token is invalid or added onto sliding expire?
Please do a video on ConfigureAwait()
If you are only using 1 server, can you just put this skew safely on 0s? Or is that still not adviced and if so, why so?
I don't use the like button on UA-cam but actually I Liked this ♥ ,I've been telling this clock skew thing to every engineer I know xD So I'm happy that it's going viral on the internet xDDD
Is the code available somewhere for reference?
What's the point of creating tokens that will only be valid in the future? What's the use case for this?
Does someone know how to change this setting when using AddMicrosoftIdentityWebApiAuthentication?
We’ve been using a clock skew of zero for over a year now and it’s not caused issues. All our stuff is in Azure so I’m assuming clock syncing isn’t an issue. That being said, I might consider a 5 second window if that’s recommended.
Would definitely not recommend zero - I've worked with Azure VMs that were a 1-2 seconds apart and it caused some pretty hard to diagnose issues!
Disclaimer - These were full VMs rather than managed services and this was several years ago.
@@0shii all our stuff is in app services so maybe we avoid issues. That being said I will open it up I think just in case.
Wouldn't that be a problem if the client checks the validity of JWT right before the expiration but the server receives the request right after the expiration? That should cause problems even if clocks were perfectly synchronized.
Is your system designed in such a way where this issue does not exist?
@@0shii then what you should do is use ntp in your vms
You said that 30 seconds is pushing it, I would say it depends on architecture, e.g. in microservices if you have a retry policy, and that policy can take upto say that 30 seconds than you probably wan't a value around that 30 second mark.
I would question a 30 second retry policy to begin with even with exponential retries. It depends on the product ofc, but it can potentially lead to a bad experience for the user. I would also assume that any retry policy would also have token invalidation checks and a token refresh trigger baked into it.
@@nickchapsas It’s just an example where it *may* need to be more
The moment I saw the title I knew this was skew related.
Yeah, I knew about it. Because I thought it was bug when I saw it. XD
Been there seen that xD
Some weird timey wimey wibbly wobbly stuff.
if you have your identity server on your api then this matters, but you can set it easily
JWT are a terrible idea for authentication. We should have never pushed them naively so hard when they first entered the scene. Good education on clock skew though, I've seen it trip up numerous systems.
Btw, google payment is broken. Please fix that. Lots of js issues in console logs.
ah i do love me some jwt (jott)
Im scared to see UUID everywhere, they have poor performance on SELECT queries
Hey Nick, at the PulumiUp conference I heard about a new interesting technology product named KLOTHO, that will compile directly from my app code an IaC topology and iaC-code. Could you do a video about that? That would be awesome!
I don't understand why do we need ClockSkew rather than increasing a actual lifetime for a token?
The default is 5 minutes because thats usually how slow microsofts servers are (MSFT store for example)
I guess you also saw this LinkedIn post :P
What LinkedIn post?
The crap that windows has historically calls a time service. Well, need I say more. OK, I get it, it is a combination of hardware provider and a whole lot of drivers not all under Microsoft control. So lets not fix it because nobody is going to take responsibility for it.
I always set this value to zero
👉🤨
At 1.08 : tl;dw?? Too long, don't want?
"watch" ...
if you read the documentation or search in the web that is just a ordinary thing, this guy exaggerates 90% of time, i expect something different
what about `ClockSkew = TimeSpan.Zero` ?
In general it’s good to allow for at least some time, like 5 seconds