OAuth defines four roles:
- Resource owner (the user)
- Resource server (the API)
- Authorization server (can be the same server as the API)
- Client (the third-party app)
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 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 access request. The authorization server is also responsible for granting access token after the user authorizes the application. As such, the authorization server will typically have two primary URLs, one for the authorization request and one for applications to use to grant access tokens. These are usually something such as:
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 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 accessed by a web browser.
Public clients cannot maintain the confidentiality of a
An access token is the string used when making authenticated requests to the API. The token represents that the user has authorized a third-party application to access that user’s account. The token has a corresponding duration of access, scope, and potentially other information. Tokens can be either self-contained (the server can retrieve all necessary information out of the token string), or could be a key in a database. Tokens are opaque to the client using them and only have meaning to the authorization and/or the API server.
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.
An authorization code is an intermediate token used in the server-side app flow, described in more detail in OAuth 2.0 Clients. An authorization code is returned to the client after the authorization step, and then the client exchanges it for an access token.