Join Keith Casey for an in-depth discussion in this video Common security considerations, part of Web Security: OAuth and OpenID Connect.
- [Instructor] Let's dive into the security considerations around resource owner password flow, and honestly there's a big one. Now just like all the other OAuth flows, the same rules apply. Since this flow uses the client_secret we need to make sure that it's protected in a private or backend component. Next, we need to make sure that all of our communications are secure with something like TLS. Next, we need to make sure that the access token is protected, both when we use it and when it's stored. And of course, we have to validate the access token.
I can't say that enough. But the actual security issue here is much bigger and it's unique to this flow. In all the other OAuth flows the application sent the user to the authorization server or the identity provider to authenticate and authorize the application. Instead, this one captures the users credentials in the application itself and sends them to the server behind the scenes to get the access token. That means the application developer has your credentials. Leads to a couple questions.
Do we really want to train our users to put their credential just anywhere? That's a problem. Next, this comes down to one fundamentally important question. Do we trust the application and all the developers involved? If this application is built by your bank and only accesses information from your bank, that might be safe. Of course, a poorly trained developer might log or save that information somewhere or maybe a malicious developer logs and saves that information somewhere. Realistically the result is the same, your account is compromised.
Now using the requested scopes seems like it would protect us, but realistically it doesn't. If a malicious developer can get your username and password they'll just use that. After all, as far as the bank is concerned, it is you. Even worse, since they have your username and password instead of an access token, you can't just revoke access. The only way to remove or block their access is to change your password. All that said, I have seen a number of organizations implement resource owner password flow for their apps as a transitional or temporary approach on the way to something bigger and better.
More than anything, it's used to get systems and developers to start speaking and thinking in OAuth as quickly as possible. And then later they convert it to something like authorization code flow or implicit flow. If you have the choice, don't use this grant type. Now throughout this entire course so far, we've been looking at OAuth from the client's point of view. Now let's dig into it from the server's point of view.
- How does OAuth 2.0 work, and what problems does it solve?
- What is OpenID Connect, and how is it different from OAuth?
- OAuth tokens and their usage
- Authorization in microservices
- Common security considerations
- Authorization for mobile apps and SPA
- Authorization in legacy applications
- Server-side implementations