Roles
OAuth defines four roles:
- Resource owner (the user)
- Resource server (the API)
- Authorization server (can be the same server as the API)
- Client (the application)
The User
The OAuth 2.0 spec refers to the user as the “resource owner.” The resource owner is the person who is giving access to some portion of their account. The resources in this case can be data (photos, documents, contacts), services (posting a blog entry, transferring funds), or any other resource requiring access restrictions. Any system that wants to act on behalf of the user must first get permission from them.
The API
The spec refers to what you typically think of as the main API as the “resource server.” The resource server is the server that contains the user’s information that is being accessed by the third-party application. The resource server must be able to accept and validate access tokens and grant the request if the user has allowed it. The resource server does not necessarily need to know about applications.
The Authorization Server
The authorization server is what the user interacts with when an application is requesting access to their account. This is the server that displays the OAuth prompt, and where the user approves or denies the application’s request. The authorization server is also responsible for granting access tokens after the user authorizes the application.
The Client
The client is the app that is attempting to act on the user’s behalf or access the user’s resources. Before the client can access the user’s account, it needs to obtain permission. The client will obtain permission by either directing the user to the authorization server, or by asserting permission directly with the authorization server without interaction by the user.
Confidential Clients
Confidential clients are clients which have the ability to maintain the confidentiality of the client_secret. Typically these clients are only applications that run on a server under the control of the developer, where the source code is not accessible to users. These types of applications are commonly referred to as “web apps,” since they are most often running on a web server.
Public Clients
Public clients cannot maintain the confidentiality of a client_secret, so the secret is not used for these apps. Both mobile apps and Javascript apps are considered public clients. Since anyone running a Javascript app can easily view the source code of the application, a secret would be visible there trivially. With mobile applications, the binary can be decompiled to extract strings. Any time the application is running on a device under the user’s control, it should be considered a public client.
Access Token
An access token is the string used when making authenticated requests to the API. The string itself has no meaning to the application using it, but represents that the user has authorized a third-party application to access their account. The token has a corresponding duration of access, scope, and potentially other information the server needs.
Refresh Token
A refresh token is a string that is used to get a new access token when an access token expires. Not all APIs use refresh tokens.
Authorization Code
An authorization code is an intermediate token used in the server-side app flow, described in more detail in Server-Side Apps. An authorization code is returned to the client after the authorization step, and then the client exchanges it for an access token.