OAuth and OpenID Connect for Microservices

No video

OAuth and OpenID Connect for Microservices

Рет қаралды 182,949

Күн бұрын

Jacob Ideskog - Curity - 22/10/2014
Microservices present a new way of scaling API deployments, where each component is an island, performing a small but well defined task. These systems are quicker to develop and allow for a more agile way of working. As in most designs, security is not part of the original blueprint, which can lead to expensive and hard to manage security solutions. In this talk, Jacob Ideskog will illustrate how OAuth and OpenID Connect can be leveraged to created a unified distributed framework for Microservices. He will show how this can be used to deliver Microservices’ promise of agility and scalability while also ensuring security.
The presentation was recorded at the 2014 Platform Summit in Stockholm, Nordic APIs second annual conference.
This talk inspired a transcription blog post which can be read here: nordicapis.com/...
----------
Get the latest API insights straight to your inbox, subscribe to Nordic APIs newsletter: nordicapis.com...

Пікірлер: 44

@-andymel 6 жыл бұрын

00:00 Introduction 00:48 Traditional monolith systems and their drawbacks 01:54 The microservice way 03:00 Securing a traditional system 03:54 One way for microservices would be that every service does authentication 04:41 OAuth - Delegegation of authentication 05:39 4 actors of OAuth - Resource Owner (user) - Authorization Server (AS) - Client (the app or website backend) - Resource Server (RS) 06:03 The authentication flow 08:34 OpenID Connect 09:54 The ID-Token 12:48 Two types of tokens - "by Value" inside of your network - "by Reference" outside of your firewall 16:14 Now use it to secure Microservices

@ramireddyyerreddula1841 3 жыл бұрын

Thanks Jacob for providing the relevant information on Authentication Protocols, It would be much helpful for me to understand the background process of Oauth authentication method and i will subscribe and willing to follow your tutorials regularly.

@donduke8422 8 жыл бұрын

Good presentation. Thanks for the information

@tehedx 5 жыл бұрын

Sounds like a good idea to do, is there a project that does this? Right now I've created a simple reverse proxy myself. It accepts by-reference tokens from users, converts it to by-value tokens and passes that to the (internal) proxied service. Added a simple cache to speed up the process a bit. It works ... but I'd rather trust some well known and maintained piece of software, designed by people that know security better.

@tiagotele1 8 жыл бұрын

Nice explanation!

@abudawood_phd 3 жыл бұрын

at arround 8.30 there is a mistake, the resource server could validate the access token without requesting the auth sever and for that we call jwt a stateless auth as it has same characteristics of the approach of the Passport and airport traveling scenarios. the police could verify your identity via Passport without needing to back to the Passport issuer

@JustPlayerDE 2 жыл бұрын

if you use the opaque access token method then the Resource Server have to request the validation from the auth server. but we can see why its not used that much anymore ^^

@dickwans 2 жыл бұрын

I think at 07:35 He said that verifiy the access token can be done in various ways.

@navinkaus 3 жыл бұрын

Thanks for sharing the nice video, few queries: 1. In case of micro-services environment (not really for delegation), does it makes sense to create audience for each service or a single audience as all micro-services belong to one product? 2. What if it's value token, it's signed but no encrypted, what kind of threat is there especially when it's being used from native app on desktop machine.

@NoTalentGuy 4 жыл бұрын

Very, very good job! Thank you! 🔥

@alsbahsy 7 жыл бұрын

Thanks man, love to see more!

@roman-romadin 5 жыл бұрын

Excellent report, thanks!

@AjayMahajan 9 жыл бұрын

How long the JWTs live, if they are cached, will they get stale when the resource permissions change.

@jacobideskog7574 7 жыл бұрын

True, caching tokens prevents revocations. However it's recommended to keep access token lifetimes short. Commonly < 10 minutes. So that changes ripple through the network fast enough. If there are higher restrictions around that then more measures needs to be considered.

@kinjalbhoiwala5115 5 жыл бұрын

quite informative. thanks for sharing it.

@WildTurfLawn 3 жыл бұрын

This is awesome

@mhsardar1288 7 жыл бұрын

HI Jacob it was nice video anything on API?

@jayantmishra6966 6 жыл бұрын

thanks, good thought on token translation point

@antonalekseyev9651 7 жыл бұрын

Jacob Ideskog, How can the Reverse Proxy be Stateless 17:41 if it has to translate SESSION_ID to JWT?

@tamilselvansellappan4574 7 жыл бұрын

Nice Jacob!!. I am new to microservices and API. We would like to apply the same authorization api service for other api services and Web app. In web app we are going to call the microservices. Is that possible?

@mehrdadk.6816 5 жыл бұрын

What happens if someone "Bad Guy" get access to access token?

@bibekdas3592 4 жыл бұрын

Hi Jacob, I have a doubt here.How the Auth server can validate the credentails entered by RO( the user) bcoz Auth server has no idea abt the user credentails but only the RS has right? i am in big confusion now after watching this video!!!

@jmrah 4 жыл бұрын

You've got it backwards. The Resource Server (RS) doesn't know anthing about the User's credentials. It doesn't try to authenticate the user at all. The Auth Server is the user store essentially, and can authenticate the user. What the RS does do is authorize the request based on what the Access Token wants to do.

@saveliybaranov1665 8 жыл бұрын

Is there a way to do this in a stateless way, and still be relatively secure? Perhaps using the JWT as the token, but with minimal info, like a user id only? Or with encrypted info?

@jacobideskog7574 7 жыл бұрын

Sorry for a late reply, but yes there are stateless approaches. Using a signed JWT on the Internet is not necessarily a security risk, but it is definately an inconvenience. The reason is that the Access Token is meant for the API and not the client. So when using the JWT on the outside, there is a risk that client developers decode the JWT and use the information. That in itself may not be harmful, but it means that you exposed an API that you didn't intend to. So when you change the content of the JWT, you may break tons of Apps that you didn't even know depended on it. For that reason, it's better to use an opaque token for the clients. However, it is also possible to use a JWE (an encrypted jwt), but be aware that it introduces other concerns, for instance, it is not a good idea to use a symmetric key, since then you loose non-repudiation. So I would suggest that if you really want to make it stateless, then you send a Signed JWT that includes an Encrypted JWT as the only content (plus scopes and expiration etc). So that you can have a fast decryption, but still rely on the signature for validation. There are probably more approaches that can be considered.

@nkurunzizasylvaintabazi8603 6 жыл бұрын

Saveliy Baranov fryt

@hamedhatami4831 5 жыл бұрын

In JWT by value , we have a bad experience with performance because it consumes a lot of CPUs and when you have to have microservices with more than 6000 RPS so it is time to see this pressure and bad working

@dipanjanm 5 жыл бұрын

Very well explained Authorization ;-)

@vizhuthugal 3 жыл бұрын

learn learniamping.blogspot.com

@elchamo256 5 жыл бұрын

Very Well

@thorsteinssonh 7 жыл бұрын

it's a little confusing, especially talking about "sessions" --- can't you do without sessions?

@jillsanluis4819 7 жыл бұрын

Curious, if the value based jwt is inside the network to scale passing around the identity why bother encoding them in jwt? Why can't the values be passed in as plain json? Aren't you paying tax for encoding/decoding the value for no gain?

@antonalekseyev9651 7 жыл бұрын

Plain JSON may contain special characters that are not suitable for HTTP header, JMS Header etc. Encoding JWT with Base64 makes JWT a quite simple string