The diagram shows the OAuth architecture, and the relationships between the Resource Owner (you, the user), the Resource Provider (which authenticates users and authorizes the third-party applications), and the Third-Party Application (such as a money management app, an online shopping cart, a mobile phone ticket repository, online storage, and more). If you have ever used the feature, “Log in with Facebook,” or “Sign in with Google,” on web sites that are not administered by Facebook or Google, then you have used OAuth. Facebook or Google is the “resource provider,” verifying that you, the “resource owner,” have successfully authenticated; after successful authentication, the “resource provider,” can provide access to the “third party,” based on what the “resource owner” (you) have authorized the resource provider to provide. This fragment is based on the Cisco Learning Library, interactive online course materials: Introducing Cloud Consumer Security (SECICC) v1.0
OAuth is an open authorization protocol, which allows access to application environments without the explicit sharing of login credentials. You can think of OAuth as a “go-between” authenticator, similar to RADIUS or TACACS, except that usernames and passwords are never exchanged in an OAuth framework.
Implementing OAuth
It’s important to keep in mind that OAuth is a protocol, not an application service itself. Using OAuth requires an application. This is very similar to SSH.
Simply building OAuth into an application does not guarantee integration or support. In the OAuth framework, the Third-Party Application needs to “register” with the Resource Provider in order to exchange Authorization Grants and Tokens.
Comments