First off, thank you all for such great comments! Second, sorry that I have not responded to anyone here. I saw that Oracle posted the video a few years ago and haven't checked back in on it. A few of the viewers have reached out to me with questions, but I figured answering them here would begetter. I'll try to respond to questions below, but most of them are quite old.
Question: The way you are describing the JWT's makes me think that these are OIDC ID tokens, not Oauth2 access tokens. But you described passing this token back in your API call, as an auth header. But the auth header would normally contain the access token, not the id token, and most of the advice I can find seems to suggest that ID tokens should not be sent along with requests, they should be "used by the application". Now, I don't really know what people mean by "used by the application" - I mean sure, you could do trivial things like say "hello " that you couldn't do otherwise, but that's obviously not super useful. Even your good, simple example - pulling the todo list for a user - obviously requires that we tell the API who the user is, and in a way that the API can trust (or really, verify) that the user really is that user, which seems like exactly what the ID token can do! But then.... what is the point of the access token? Are you meant to send both? And why does all the advice I can find suggest that you should not send ID tokens... and if *that* is true, how the heck should people send to the API the kind of thing you described here - ie, a "verifiably trustworthy" user id?
@@allmhuran Great questions! You are correct that the OIDC ID token is a JWT, but in many cases, so is the access token. This presentation and most of my writing assumes that the access token is also a JWT (this is also how FusionAuth generates access tokens). Therefore, you will send the access token back to the your backend and your backend can decode it as a JWT. From there, you can use it however you need. You can also call the OIDC User Info API with this access token to get additional details about the user. Let me know if you have any questions on JWTs as access tokens.
@@brianpontarelli2009 Thanks, that makes sense. I suppose the followup would be: does this mean that IDP stacks that happen to use JWT's as access tokens are typically encrypting them (probably symmetrically for performance), not merely signing them? Otherwise it seems all of the "concern" I have read about passing around ID Tokens would also apply to JWT access tokens.
This is very wonderful and useful session for us. I saw many session before, but i didn't understand JWT and security. After this session i got very clear idea.
First time I've ever seen oracle and IBM related software that didn't crash 14 times in the demo (I'm looking at you FastTrack). But seriously, excellent video and thank you very much for sharing!
The presentation is good While it is not in standard JWT, if we wanted to invalidate JWT token before it's predefined expiry time, i.e. value of "exp" registered claim, we need to use database, redis or other While some store jwt when admin chooses block, I personally store "jti" registered claim of every JWT token that I can invalidate when admin chooses to block Coming to alg as none, jwt rfc wanted libraries to support, after seeing this mandate, I never released my jwt library while I used that well in last 5 to 6 years well and in a secure way
Q: How can the Todo server verify a JWT that was derived from a refresh token? For regular JWT I can see that the Todo server will have access to public key of the User server. But for refresh token generated JWT, the public key alone will not be enough to verify the JWT.
can you help me how to implement authentication and authorization between microservices using jwt? I am not able to figure out.can you please share code?
Nice Presentation, i have few Question if anyone could answer them would be nice, How do you get your new jwt does the todo API call the user Api or does the frontend call the user API when it gets and error from todo API of expired JWT. And then how do you handle Authorization in this SOA. In the presentation I have only one Todo APIv1 lets I also have another API called Todov2 Api. HOw does authorization work if user can use Todo v1 but not v2 where would you define this part in the jwt in roles or does all the API now About this roles and take action accordingly.
There is an issue here. If you start the "todos" service in the "red" period of the invalidation graph and you have a fresh cache you'll not get notified of the previous refresh token revoke (and so you will think there is no "red" line for that specific user) and will therefore treat JWT as valid that should now. This is an edge case, but still real.
I think I'm missing something. Someone please confirm? As I understood, the User service is in-charge for generating the JWT when logging in and will be returned to the front-end app. Then it will be attached into the header for every request (for example getting the user's todo list). How can the Todo Service verify that the token passed into the header is valid? Does that mean the RSA pub file must also be available to other services (Todo)? If I use HS256 algorithm then I will be sharing the secret key to all services, is this correct?
@@BigBootyBuffie additional confirmation. When I sign a token I use the private key file and when verifying from different services use the public key, right?
Hi Brain, very good video, thanks very much. Quick question, when refresh token Is revoked it still is not an immediate logout, right? Because the access token can still live for some time until it needs to be refreshed again. How do you solve that? Thanks.
That's in the video. Services can use a websocket event (token-revoked) and cache a red-period to determine when a JWT is considered invalid. However, as I pointed in my comment, if the cache is fresh and the app is starting up, you'll have some misses.
Can anyone provide a link to Brian's other presentation that he mentioned on authenticating / authorizing in an API gateway instead of each service? He mentions this around 19:20
if the server uses private key or some secrete to encrypt ..every time jwt expires and new one created, i guess the new jwt signature filed should different, how does that happen as secret keys are hardcoded i suppose of they generate secrete key on the fly?
Hello, Thank you for the video. I have a question about validating the JWT. In order to validate the token in microservices - we need to save secret keys (JWT access key) in micoservices?
can you help me how to implement authentication and authorization between microservices using jwt? I am not able to figure out.can you please share code?
I'd recommend putting the permissions directly in the JWT. Or you could use a PBAC implementation that takes a JWT and a permission and responds with a true/false that determines if the user has that permission.
@@KunalMukherjee3701 generally, PBACs are either separate services or they are built into the authorization server. Then the resource server queries the authorization server for the permissions and grants. FusionAuth handles this via our Entity Management feature. It's a pretty slick way to handle permissions and grants. It also works for machine-to-machine tokens as well as user PBAC.
Passing just session ID for auth requires checking store (cache or database), probably a network call. JWT doesn't because you can check the public key inside the JWT against the private key your backends have access to.
Aren't we talking about WEB app, where you need to have the state somewhere ? You choose to save the state in JWT and send it back/forth with every request vs sending back/forth only the session ID. Then it boils down to whether a back-end "DB call" will return faster or passing all state data via the Internet. This back-end DB-call sometimes goes just to a RAM-disk, because session write/read handlers are flexible and the number of simultaneous user sessions is not very high (under say 20k).
@@angelg3986 I think he addresses this in the beginning. It’s much more expensive to vertically scale a database server than just horizontally scale your micro services. Most cloud providers now a days offer auto scaling on demand. With a huge monolithic database, and sufficient online users, this auto scaling would be permanent for your database server, making it expensive.
Does it really make sense to revoke access tokens using expiration? I mean if they are only supposed to live for a short period, is it worth the "effort"?
It depends on your context and application. If your access token _really_ is short-lived (~5 minutes, like it's supposed to be) then I guess... no, it's not worth the effort. If your access token lifespan is in any order of magnitude higher than a few minutes (like the one in the video) then... yes, I'd do that just to be on the safe side. Like he says, in case of a breach or leak, you need a way to flush everyone out quickly!
What if the roles can change often? Couldn't a hacker who accessed the jwt brute force it without any slow down that'll usually be in place on a login endpoint?
Well, that's why tokens are usually short-lived. But if you're super paranoid, you could create a redis JWT Blacklist, so you can cancel out JWTs on-demand.
@@raymcbride5678 Thanks for answering, but what you said doesn't solve the problem. Role changes may need to be immediate (or as close as possible). A short lived token doesn't stop a brute force exposing the data inside the token once it's cracked, and we can't trust that developers won't throw something in tokens that shouldn't be there.
So for applying role changes instantly you could "revoke" the JWTs based on their expiration or their issued_at, as shown in 35:15. The client would then be forced to use the refresh token to get a new JWT with the new roles. For the brute-force, you are dealing with RSA, at least 2048-bit is required by the JWT specification, but you will be probably dealing with 4096-bit. That is basically impossible to brute-force. It's easier to brute-force the actual user password on /login with the usual rate limiting.
@@kebien6020 As I understand it the presenter said using JWT you can call services directly. Therefore every service needs JWT auth handling (which is also a pain) and access to a shared revoking storage. If we're now checking storage to determine if a jwt is valid, the benefit is lost. We can instead just have a normal auth service, which stores the permissions and tell us if a user can access a resource at the api gateway level. As it stands you're correct that brute forcing alone won't break 4096-bit RSA, however a quick google search shows some researchers have broken it. The thing to remember is that you shouldn't just assume something won't be broken because it's the norm, at least, not on my watch.
I don't mind node. Its IntelliJ that I hate. Making us pay for our IDEs is supposed to be Microsoft's thing... Why didn't you use the node jwt package?
@@zoomzoom9999 some apps should be paid. I don't think that IDEs fall into that category. I am a firm believer in Free Software for individuals. If said software is being used commercially, then it should be paid for. This is generally the way it has been for decades now. That said, recently, (it feels like) certain companies have been trying to change this. I personally spend ~ 25% of my development time working on paid corporate finance software for my employer and the rest goes to developing free software via open-source projects. When you put up walls of any kind that hinder the creation of software by individuals (or by any source), it slows the progress of software development as a whole.
Also, my dislike for Intellij has nothing to do with their paid software. It is the mutual back-scratching with Android that I can't stand. If you need me to go into detail, I will...
First off, thank you all for such great comments!
Second, sorry that I have not responded to anyone here. I saw that Oracle posted the video a few years ago and haven't checked back in on it. A few of the viewers have reached out to me with questions, but I figured answering them here would begetter.
I'll try to respond to questions below, but most of them are quite old.
Question: The way you are describing the JWT's makes me think that these are OIDC ID tokens, not Oauth2 access tokens. But you described passing this token back in your API call, as an auth header. But the auth header would normally contain the access token, not the id token, and most of the advice I can find seems to suggest that ID tokens should not be sent along with requests, they should be "used by the application".
Now, I don't really know what people mean by "used by the application" - I mean sure, you could do trivial things like say "hello " that you couldn't do otherwise, but that's obviously not super useful. Even your good, simple example - pulling the todo list for a user - obviously requires that we tell the API who the user is, and in a way that the API can trust (or really, verify) that the user really is that user, which seems like exactly what the ID token can do! But then.... what is the point of the access token? Are you meant to send both? And why does all the advice I can find suggest that you should not send ID tokens... and if *that* is true, how the heck should people send to the API the kind of thing you described here - ie, a "verifiably trustworthy" user id?
@@allmhuran Great questions! You are correct that the OIDC ID token is a JWT, but in many cases, so is the access token. This presentation and most of my writing assumes that the access token is also a JWT (this is also how FusionAuth generates access tokens). Therefore, you will send the access token back to the your backend and your backend can decode it as a JWT. From there, you can use it however you need. You can also call the OIDC User Info API with this access token to get additional details about the user.
Let me know if you have any questions on JWTs as access tokens.
@@brianpontarelli2009 Thanks, that makes sense. I suppose the followup would be: does this mean that IDP stacks that happen to use JWT's as access tokens are typically encrypting them (probably symmetrically for performance), not merely signing them? Otherwise it seems all of the "concern" I have read about passing around ID Tokens would also apply to JWT access tokens.
This is easily one of the most informative presentations I have ever watched! Really good stuff!!
Still is mate even after 5 years.
This is a must watch video for anyone working with auth
The presentation was truly impressive, and I find myself wishing I could convey my admiration for it multiple times.
This was such a good presentation, I wish I could like it more than once.
Agreed, I've never seen something auth-related explained so well.
Write a script that periodically posts a random comment.
Couldn't agree more.
you can click like twice
This guy knows what he is talking about. Wonderful presentation 👍
It's really the only one place where a good strategy of revoking the token was explained. Great Speech
I've seen a tonne of videos on authentication and authorization in microservices.. and this is the best one hands down
Only 2+ minutes into this presentation and I can tell I'd learn so much from this.
This is very wonderful and useful session for us. I saw many session before, but i didn't understand JWT and security. After this session i got very clear idea.
Thank you. he is a good representative as well as a knowledgeable basket.
Only 66k views ? This presentation is rly good and high quality. Lot of useful information in just a 50 minutes. Thanks a lot!
Great presentation, not only theory but code! Finally I get all the excitement about JWTs!
Neat description of the progression getting to jwt's.
This really helped me understand how JWT's work! Thank you!
First time I've ever seen oracle and IBM related software that didn't crash 14 times in the demo (I'm looking at you FastTrack). But seriously, excellent video and thank you very much for sharing!
It's all I need, really helpful to approach the ms architect, plenty of thanks.
Man, thank you for this, now I know how to design my architecture
this is really well presented and condensed
His expressions are like Tim Robinson from 'I think you should leave'
Didactically perfectly structured presentation. Kudos.
Excellent
Wonderful and clear presentation! Thank you very much! 🍻
This was awesome.
Awesome content! Thanks for posting!
Glad you enjoyed it!
Really Awesome. Thank you very much. Great talk
Superb session. Thanks a ton, loved it. Indeed, very useful.
Great Content!
Pretty information, Thank you so much 😊
The presentation is good
While it is not in standard JWT, if we wanted to invalidate JWT token before it's predefined expiry time, i.e. value of "exp" registered claim, we need to use database, redis or other
While some store jwt when admin chooses block, I personally store "jti" registered claim of every JWT token that I can invalidate when admin chooses to block
Coming to alg as none, jwt rfc wanted libraries to support, after seeing this mandate, I never released my jwt library while I used that well in last 5 to 6 years well and in a secure way
This is awesome
Anyone has the link to his talk on api gateways he mentions on 19:09?
Great presentation
Glad you think so!
Very Insightful presentation, is it possible to get the slides of the presentation.
the code that he is showing is in any git hosting platform like github or gitlab ??
Great presentation!
Nice presentation. Thank you very much!
It helps me so much. Thank you!
Really great presentation, thanks !
Q: How can the Todo server verify a JWT that was derived from a refresh token?
For regular JWT I can see that the Todo server will have access to public key of the User server.
But for refresh token generated JWT, the public key alone will not be enough to verify the JWT.
How do other services know when user logs out? The access jwt will still be valid if we verify signature and expiry.
Hello thank you so much for this wonderful presentation. One more thing, is there any repository available to view the code?
I'd search Google for his company name which he mentioned at the beginning and is also mentioned in the video details, and the words "todo app jwt".
Great presentation. Thank you !
Great session! one question though, how can we destroy all refresh tokens, say in case of reset password/forgot password?
I could not find the repository of the example that you were referring to. Can anyone point me to that if available?
can you help me how to implement authentication and authorization between microservices using jwt?
I am not able to figure out.can you please share code?
Nice Presentation, i have few Question if anyone could answer them would be nice,
How do you get your new jwt does the todo API call the user Api or does the frontend call the user API when it gets and error from todo API of expired JWT.
And then how do you handle Authorization in this SOA. In the presentation I have only one Todo APIv1 lets I also have another API called Todov2 Api. HOw does authorization work if user can use Todo v1 but not v2 where would you define this part in the jwt in roles or does all the API now About this roles and take action accordingly.
There is an issue here.
If you start the "todos" service in the "red" period of the invalidation graph and you have a fresh cache you'll not get notified of the previous refresh token revoke (and so you will think there is no "red" line for that specific user) and will therefore treat JWT as valid that should now. This is an edge case, but still real.
The thing that he showed for token revoke is cool, but as far as I understand it won't work if your system requires a multi session functionality.
I think I'm missing something. Someone please confirm? As I understood, the User service is in-charge for generating the JWT when logging in and will be returned to the front-end app. Then it will be attached into the header for every request (for example getting the user's todo list). How can the Todo Service verify that the token passed into the header is valid? Does that mean the RSA pub file must also be available to other services (Todo)? If I use HS256 algorithm then I will be sharing the secret key to all services, is this correct?
you are correct
@@BigBootyBuffie additional confirmation. When I sign a token I use the private key file and when verifying from different services use the public key, right?
@@elyu_vibes I am sure you figured this out already, but yes you use the public key to verify the token.
06:57 User Id 1
07:15 Security | Tokens
Hi Brain, very good video, thanks very much. Quick question, when refresh token Is revoked it still is not an immediate logout, right? Because the access token can still live for some time until it needs to be refreshed again. How do you solve that? Thanks.
That's in the video. Services can use a websocket event (token-revoked) and cache a red-period to determine when a JWT is considered invalid. However, as I pointed in my comment, if the cache is fresh and the app is starting up, you'll have some misses.
Can anyone provide a link to Brian's other presentation that he mentioned on authenticating / authorizing in an API gateway instead of each service? He mentions this around 19:20
@Brian Pontarelli could you share link to the presentation?
@@dariuszek He told me that the presentation he mentioned is not recorded! FYI
@@jordancahill9205 Thx for letting me know
if the server uses private key or some secrete to encrypt ..every time jwt expires and new one created, i guess the new jwt signature filed should different, how does that happen as secret keys are hardcoded i suppose of they generate secrete key on the fly?
Hello,
Thank you for the video. I have a question about validating the JWT. In order to validate the token in microservices - we need to save secret keys (JWT access key) in micoservices?
You need to have the public key or shared secret used to sign the JWT.
@@psenthur can you help me how to implement authentication and authorization between microservices using jwt?
can you help me how to implement authentication and authorization between microservices using jwt?
I am not able to figure out.can you please share code?
4:45
5:03 database decoupling
5:33 no foreign key in the new todos db
so cool! still did not understood the "refresh token" process on practice though
It's a long-lived token used to refresh the short-lived (access) token. Lemme know if I can help you...
@@thiagovilla970 hi, so do we need to store the refresh tokens in a cache/db to then invalidate them after logout?
any code link for implementing authentication microservices using jwt?
Can you share the code and the slides in the description
I can't like this enough
Did he post the code online ?
Is there an open source PHP microservice for this kind of authentication?
Thanks
can anyone help me how to implement authentication and authorization between microservices using jwt?
He mentioned that cookies can be a good way to store tokens but can't they be hacked as well ?
i have 100+ permmision to specific roles in diiferent database how handle authrization?
I'd recommend putting the permissions directly in the JWT. Or you could use a PBAC implementation that takes a JWT and a permission and responds with a true/false that determines if the user has that permission.
@@brianpontarelli2009 k👍
@@brianpontarelli2009 should the PBAC(s) be added into the resource server or the Authorization server
@@KunalMukherjee3701 generally, PBACs are either separate services or they are built into the authorization server. Then the resource server queries the authorization server for the permissions and grants. FusionAuth handles this via our Entity Management feature. It's a pretty slick way to handle permissions and grants. It also works for machine-to-machine tokens as well as user PBAC.
I had no idea the specification decided on the pronounciation... I always said J-W-T
I didn't get the difference between passing forth/back token and session id. Both are identifiers.
Passing just session ID for auth requires checking store (cache or database), probably a network call. JWT doesn't because you can check the public key inside the JWT against the private key your backends have access to.
Aren't we talking about WEB app, where you need to have the state somewhere ? You choose to save the state in JWT and send it back/forth with every request vs sending back/forth only the session ID. Then it boils down to whether a back-end "DB call" will return faster or passing all state data via the Internet. This back-end DB-call sometimes goes just to a RAM-disk, because session write/read handlers are flexible and the number of simultaneous user sessions is not very high (under say 20k).
@@angelg3986 I think he addresses this in the beginning.
It’s much more expensive to vertically scale a database server than just horizontally scale your micro services.
Most cloud providers now a days offer auto scaling on demand. With a huge monolithic database, and sufficient online users, this auto scaling would be permanent for your database server, making it expensive.
Great talk, well explained but I'd like to know what he didn't like about Node exactly.
I'd reckon the same things that most other developers dislike about it
doesn't storing the token in a cookie leave you vulnerable to CSRF attacks?!
Does it really make sense to revoke access tokens using expiration? I mean if they are only supposed to live for a short period, is it worth the "effort"?
It depends on your context and application. If your access token _really_ is short-lived (~5 minutes, like it's supposed to be) then I guess... no, it's not worth the effort. If your access token lifespan is in any order of magnitude higher than a few minutes (like the one in the video) then... yes, I'd do that just to be on the safe side. Like he says, in case of a breach or leak, you need a way to flush everyone out quickly!
Also look at the talk "JSON Web Tokens Suck - Randall Degges"
What if the roles can change often?
Couldn't a hacker who accessed the jwt brute force it without any slow down that'll usually be in place on a login endpoint?
Well, that's why tokens are usually short-lived. But if you're super paranoid, you could create a redis JWT Blacklist, so you can cancel out JWTs on-demand.
@@raymcbride5678
Thanks for answering, but what you said doesn't solve the problem.
Role changes may need to be immediate (or as close as possible). A short lived token doesn't stop a brute force exposing the data inside the token once it's cracked, and we can't trust that developers won't throw something in tokens that shouldn't be there.
In addition, once it's cracked, the hacker can take the secret and start accessing live users session and change the roles.
So for applying role changes instantly you could "revoke" the JWTs based on their expiration or their issued_at, as shown in 35:15. The client would then be forced to use the refresh token to get a new JWT with the new roles.
For the brute-force, you are dealing with RSA, at least 2048-bit is required by the JWT specification, but you will be probably dealing with 4096-bit. That is basically impossible to brute-force. It's easier to brute-force the actual user password on /login with the usual rate limiting.
@@kebien6020
As I understand it the presenter said using JWT you can call services directly. Therefore every service needs JWT auth handling (which is also a pain) and access to a shared revoking storage. If we're now checking storage to determine if a jwt is valid, the benefit is lost.
We can instead just have a normal auth service, which stores the permissions and tell us if a user can access a resource at the api gateway level.
As it stands you're correct that brute forcing alone won't break 4096-bit RSA, however a quick google search shows some researchers have broken it. The thing to remember is that you shouldn't just assume something won't be broken because it's the norm, at least, not on my watch.
I thought exp was optional in jwt. Can you not define eternal tokens?
It isn't required, but perpetual tokens are considered bad practice
Come on! Why don't you store logout time and compare it against token "iat" (issued at)?
can u provide code
I don't mind node. Its IntelliJ that I hate. Making us pay for our IDEs is supposed to be Microsoft's thing...
Why didn't you use the node jwt package?
Do you also work for free? I assume the IntelliJ developers also need bread on their tables.
@@zoomzoom9999 some apps should be paid. I don't think that IDEs fall into that category. I am a firm believer in Free Software for individuals. If said software is being used commercially, then it should be paid for. This is generally the way it has been for decades now. That said, recently, (it feels like) certain companies have been trying to change this.
I personally spend ~ 25% of my development time working on paid corporate finance software for my employer and the rest goes to developing free software via open-source projects.
When you put up walls of any kind that hinder the creation of software by individuals (or by any source), it slows the progress of software development as a whole.
Also, my dislike for Intellij has nothing to do with their paid software. It is the mutual back-scratching with Android that I can't stand. If you need me to go into detail, I will...
can jwts be stolen?
Sure they can
42...
MICROSERVICES!
Please add timestamps!!
Just did it :D enjoy!
If I'd see node, i'd pack-up my bag and leave.
Good presentation but I cringed a little everytime I heard JOT
Hai later chat
localStorage in node, really mate ?
Browser local storage
Why for God sake you go away from mic?!
I feel like this guy doesn't really know what he's talking about.
could you tell us the reason, please?
Apparently you don't
Only 2+ minutes into this presentation and I can tell I'd learn so much from this.