Authentication as a Microservice

Рет қаралды 215,456

6 жыл бұрын

Authentication is a core piece of many applications. However, it has traditionally been handled in a monolithic manner. Foreign keys to the user table and join tables for roles and permissions is the most common mechanism that applications use to manage user data. Moving to micro-services means that applications now need to decouple authentication, user management and user data. To accomplish this, a portable identity model is required.
Brian Pontarelli
CEO / CHAIRMAN
Inversoft
Brian Pontarelli is founder and CEO of Inversoft, a Denver-based provider of platform technologies built to help companies manage, moderate and engage their customers. These technologies include Passport, a modern identity and user management API that provides login, registration, single sign-on and many other user management features and CleanSpeak, an intelligent profanity filtering and moderation tool. Before Brian bootstrapped Inversoft, he studied computer engineering at the University of Colorado Boulder. After graduating, he worked at a variety of companies including Orbitz, BEA, US Freightways, XOR and Texturemedia. Brian has presented at numerous conferences including JavaOne, No Fluff Just Stuff, Denver Startup Week, and others and has been featured on podcasts including Hustle & Deal Flow and Startup CTO.

Пікірлер: 145

@brianpontarelli2009 3 жыл бұрын

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.

@allmhuran 3 жыл бұрын

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?

@brianpontarelli2009 3 жыл бұрын

@@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.

@allmhuran 3 жыл бұрын

@@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.

@damilolaadeyemi8383 3 жыл бұрын

I've seen a tonne of videos on authentication and authorization in microservices.. and this is the best one hands down

@alexandernestle3577 3 жыл бұрын

This is easily one of the most informative presentations I have ever watched! Really good stuff!!

@aleksamitic6655 Жыл бұрын

Still is mate even after 5 years.

@hugomejia7826 4 жыл бұрын

Great presentation, not only theory but code! Finally I get all the excitement about JWTs!

@samanthaferguson6018 3 жыл бұрын

Only 2+ minutes into this presentation and I can tell I'd learn so much from this.

@andreyka26_se 4 жыл бұрын

It's really the only one place where a good strategy of revoking the token was explained. Great Speech

@pareeks 4 жыл бұрын

This guy knows what he is talking about. Wonderful presentation 👍

@casimirrex 3 жыл бұрын

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.

@myalilhalk7335 7 ай бұрын

The presentation was truly impressive, and I find myself wishing I could convey my admiration for it multiple times.

@tomasma4896 4 жыл бұрын

Only 66k views ? This presentation is rly good and high quality. Lot of useful information in just a 50 minutes. Thanks a lot!

@PaulSebastianM 4 жыл бұрын

Wonderful and clear presentation! Thank you very much! 🍻

@tunglethanh3486 3 жыл бұрын

It's all I need, really helpful to approach the ms architect, plenty of thanks.

@lukeconner 4 жыл бұрын

This was such a good presentation, I wish I could like it more than once.

@vincentcaudo-engelmann9057 4 жыл бұрын

Agreed, I've never seen something auth-related explained so well.

@prat-man 4 жыл бұрын

Write a script that periodically posts a random comment.

@__nitinkumar__ 2 жыл бұрын

Couldn't agree more.

@madd5 2 жыл бұрын

you can click like twice

@theilluminatimember8896 2 жыл бұрын

This really helped me understand how JWT's work! Thank you!

@AlexanderBachmann 3 жыл бұрын

Didactically perfectly structured presentation. Kudos.

@yousufbaig821 2 жыл бұрын

Superb session. Thanks a ton, loved it. Indeed, very useful.

@TruongHoang-du9if 4 жыл бұрын

Nice presentation. Thank you very much!

@howardmarles2576 4 жыл бұрын

Great presentation. Thank you !

@DucNguyen-rz3gc 4 жыл бұрын

It helps me so much. Thank you!

@lasindunuwanga5292 7 ай бұрын

Thank you. he is a good representative as well as a knowledgeable basket.

@rashidasgari3337 Жыл бұрын

This is a must watch video for anyone working with auth

@svan001 4 жыл бұрын

Really great presentation, thanks !

@patrickcoffey5933 2 жыл бұрын

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!

@devenderkumar1140 3 жыл бұрын

Really Awesome. Thank you very much. Great talk

@xbronn 3 жыл бұрын

this is really well presented and condensed

@dylanngo4454 3 жыл бұрын

Pretty information, Thank you so much 😊

@tomcat6186 2 жыл бұрын

Man, thank you for this, now I know how to design my architecture

@chordfunc3072 3 жыл бұрын

Great presentation!

@tomknudcognizant5746 2 жыл бұрын

Neat description of the progression getting to jwt's.

@AuggieGreg Жыл бұрын

Awesome content! Thanks for posting!

@oracledevs Жыл бұрын

Glad you enjoyed it!

@Viviko Жыл бұрын

This was awesome.

@sandorbakos2929 8 ай бұрын

Great Content!

@jaymuthusyt Жыл бұрын

Excellent

@andreasaa2563 2 жыл бұрын

This is awesome

@pablor123 4 жыл бұрын

the code that he is showing is in any git hosting platform like github or gitlab ??

@subramanianchenniappan4059 4 жыл бұрын

Thanks

@theawless 2 жыл бұрын

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.

@yasver3474 2 жыл бұрын

Great session! one question though, how can we destroy all refresh tokens, say in case of reset password/forgot password?

@natrajreddy5818 3 жыл бұрын

How do other services know when user logs out? The access jwt will still be valid if we verify signature and expiry.

@techindeck 4 жыл бұрын

Hello thank you so much for this wonderful presentation. One more thing, is there any repository available to view the code?

@PaulSebastianM 4 жыл бұрын

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".

@dmbarry86 3 жыл бұрын

Great presentation

@oracledevs 3 жыл бұрын

Glad you think so!

@dariobednarski288 4 жыл бұрын

Is there an open source PHP microservice for this kind of authentication?

@aibolorazbekov736 4 жыл бұрын

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?

@psenthur 4 жыл бұрын

You need to have the public key or shared secret used to sign the JWT.

@kharika5551 4 жыл бұрын

@@psenthur can you help me how to implement authentication and authorization between microservices using jwt?

@kharika5551 4 жыл бұрын

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?

@XinWongDigital 3 жыл бұрын

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.

@ErikCampobadal 2 жыл бұрын

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.

@kharika5551 4 жыл бұрын

any code link for implementing authentication microservices using jwt?

@kharika5551 4 жыл бұрын

can anyone help me how to implement authentication and authorization between microservices using jwt?

@tarankaranth8782 2 жыл бұрын

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?

@san070389 4 жыл бұрын

I could not find the repository of the example that you were referring to. Can anyone point me to that if available?

@kharika5551 4 жыл бұрын

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?

@youtugeo Жыл бұрын

Anyone has the link to his talk on api gateways he mentions on 19:09?

@osquigene 4 жыл бұрын

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"?

@thiagovilla970 4 жыл бұрын

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!

@jordancahill9205 3 жыл бұрын

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

@dariuszek 3 жыл бұрын

@Brian Pontarelli could you share link to the presentation?

@jordancahill9205 3 жыл бұрын

@@dariuszek He told me that the presentation he mentioned is not recorded! FYI

@dariuszek 3 жыл бұрын

@@jordancahill9205 Thx for letting me know

@raghuveerdendukuri1762 3 жыл бұрын

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

@rejectshade 3 жыл бұрын

Did he post the code online ?

@youtugeo 2 жыл бұрын

I can't like this enough

@ycdwtv7017 2 жыл бұрын

His expressions are like Tim Robinson from 'I think you should leave'

@shivangchheda6311 Жыл бұрын

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.

@elyu_vibes 4 жыл бұрын

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 4 жыл бұрын

you are correct

@elyu_vibes 4 жыл бұрын

@@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?

@allenrand2188 4 жыл бұрын

@@elyu_vibes I am sure you figured this out already, but yes you use the public key to verify the token.

@ErikCampobadal 2 жыл бұрын

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.

@bohdanmaksymchuk3065 Жыл бұрын

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.

@natetolbert3671 3 жыл бұрын

I thought exp was optional in jwt. Can you not define eternal tokens?

@alanhoff89 3 жыл бұрын

It isn't required, but perpetual tokens are considered bad practice

@antontraceur 4 жыл бұрын

so cool! still did not understood the "refresh token" process on practice though

@thiagovilla970 4 жыл бұрын

It's a long-lived token used to refresh the short-lived (access) token. Lemme know if I can help you...

@yasver3474 2 жыл бұрын

@@thiagovilla970 hi, so do we need to store the refresh tokens in a cache/db to then invalidate them after logout?

@hemanth6951 4 жыл бұрын

i have 100+ permmision to specific roles in diiferent database how handle authrization?

@brianpontarelli2009 3 жыл бұрын

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.

@hemanth6951 3 жыл бұрын

@@brianpontarelli2009 k👍

@KunalMukherjee3701 3 жыл бұрын

@@brianpontarelli2009 should the PBAC(s) be added into the resource server or the Authorization server

@brianpontarelli2009 3 жыл бұрын

@@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.

@josephtsegen7071 Жыл бұрын

Very Insightful presentation, is it possible to get the slides of the presentation.

@KunalMukherjee3701 3 жыл бұрын

Can you share the code and the slides in the description

@budsyremo Жыл бұрын

He mentioned that cookies can be a good way to store tokens but can't they be hacked as well ?

@JamesSmith-cm7sg 4 жыл бұрын

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?

@raymcbride5678 4 жыл бұрын

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.

@JamesSmith-cm7sg 4 жыл бұрын

@@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.

@JamesSmith-cm7sg 4 жыл бұрын

In addition, once it's cracked, the hacker can take the secret and start accessing live users session and change the roles.

@kebien6020 3 жыл бұрын

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.

@JamesSmith-cm7sg 3 жыл бұрын

@@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.

@angelg3986 3 жыл бұрын

I didn't get the difference between passing forth/back token and session id. Both are identifiers.

@justingodesky5912 2 жыл бұрын

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.

@angelg3986 2 жыл бұрын

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).

@zoomzoom9999 2 жыл бұрын

@@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.

@ruixue6955 2 жыл бұрын

4:45 5:03 database decoupling 5:33 no foreign key in the new todos db

@clasesutnfrc8699 2 жыл бұрын

06:57 User Id 1 07:15 Security | Tokens

@HakunaMatata225 2 жыл бұрын

doesn't storing the token in a cookie leave you vulnerable to CSRF attacks?!

@miketyson7274 3 жыл бұрын

I had no idea the specification decided on the pronounciation... I always said J-W-T

@mohammadsaqib1400 4 жыл бұрын

can u provide code

@liquidcode1704 2 жыл бұрын

MICROSERVICES!

@saeedgnu Жыл бұрын

Come on! Why don't you store logout time and compare it against token "iat" (issued at)?

@VIRAJBHOSLE 2 жыл бұрын

Also look at the talk "JSON Web Tokens Suck - Randall Degges"

@anatoliistepaniuk8217 4 жыл бұрын

Please add timestamps!!

@thiagovilla970 4 жыл бұрын

Just did it :D enjoy!

@danielicywyak322 Жыл бұрын

can jwts be stolen?

@samucancld Жыл бұрын

Sure they can

@zebcode 3 жыл бұрын

Great talk, well explained but I'd like to know what he didn't like about Node exactly.

@maskettaman1488 2 жыл бұрын

I'd reckon the same things that most other developers dislike about it

@natetolbert3671 3 жыл бұрын

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 2 жыл бұрын

Do you also work for free? I assume the IntelliJ developers also need bread on their tables.

@natetolbert3671 2 жыл бұрын

@@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.

@natetolbert3671 2 жыл бұрын

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...