OAuth and OpenID Connect for Microservices
Vložit
- čas přidán 23. 10. 2014
- 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/how-to-control-...
----------
Get the latest API insights straight to your inbox, subscribe to Nordic APIs newsletter: nordicapis.com/newsletter/ - Věda a technologie
Good presentation. Thanks for the information
Nice explanation!
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.
Thanks man, love to see more!
Excellent report, thanks!
Very, very good job! Thank you! 🔥
quite informative. thanks for sharing it.
Very well explained Authorization ;-)
learn learniamping.blogspot.com
thanks, good thought on token translation point
How long the JWTs live, if they are cached, will they get stale when the resource permissions change.
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.
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
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.
HI Jacob it was nice video anything on API?
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.
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?
Jacob Ideskog, How can the Reverse Proxy be Stateless 17:41 if it has to translate SESSION_ID to JWT?
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?
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.
Saveliy Baranov fryt
This is awesome
What happens if someone "Bad Guy" get access to access token?
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
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 ^^
I think at 07:35 He said that verifiy the access token can be done in various ways.
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
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!!!
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.
it's a little confusing, especially talking about "sessions" --- can't you do without sessions?
I delegate means I authorize. Delegation can be revoked and so does the authorization.
Very Well
Good how
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?
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
at czcams.com/video/BdKmZ7mPNns/video.html I believe Jacob meant to say "what the ""client app"" then does" not "resource server"
Yes, you note that too.
no infor about openid connect
ok
Why don’t you just show us the recorded screen? Only we see is people face. We want to see PPD not the face.
7 minutes into the video and I saw so many flaws
Great for you. Now what are the 'flaws' or did you just want to post a meaningless comment?
alejandro torres of a good friend is a type to ykjjjjjgfffffffffttgggghhhhjjjjjjjjkkikkkkkkkkkkkikklloooqoqlkjewpiqyyy