Terminology Reference

20

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 third-party app)

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 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:

  • https://authorization-server.com/authorize
  • https://authorization-server.com/token

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 accessed by a web browser.

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.

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.