OAuth (Open Authorization) is a standard framework that allows login access to third-party websites and applications without exposing user account credentials and information. Currently, OAuth2 is the latest version of that standard.

OAuth2, implemented correctly, provides a medium level of security for a broad range of web application architectures, including web browsers, mobile devices, browser-based client applications (such as JavaScript), and B2B client applications.

This topic introduces core OAuth2 concepts and terms.

Actors

OAuth2 defines the following actors to perform specific operations and to interact to create a secure authorization framework:

Actor Description OpenEdge Examples
Resource owner A user who is the owner of data stored, accessed through, and protected by, a resource server. As data owners, they can authorize a client to access and perform certain operations on data stored on a resource server. End-users
Client An application that uses an access token from an authorization server to gain access to the resource owner data that is hosted by a resource server.

Each client is defined by a unique ID ( client_id ) that is registered with an authorization server, inserted into an OAuth2 access token, and validated by the resource server.

 JavaScript client applications
Resource server An abstraction that refers generally to any system or component that stores resource data and returns it to a client that is authorized to receive it. For example, the web server data service that hosts and authorizes client access to a resource owner’s data based on an access token's client_id, user-identity and granted scope. ABL business applications (Spring OAuth2 in OEABL web applications)
Authorization server A server that validates a resource owner's credentials. Maintaining a list of registered clients and resource servers, it calls on an authentication server for identity verification. If authorization is successful, it issues access tokens to a client on behalf of the resource owner. N/A (third-party products)
User-agent A web browser, or some other type of framework that hosts client applications. Browsers, mobile devices, Node js, and so on
Authentication server A server, undefined in the standard, that is used by an authorization server to authenticate the resource owner's identity. After the resource owner's identity is authenticated, the authorization server can continue its authorization process for issuing an access token. N/A (third-party products associated with the authorization server)

Flows and grant types

Aflow represents an exchange of one or more HTTP messages between the various OAuth2 actors. Each OAuth2 flow has a name defined in the standard as a grant type. The grant type is configured and implemented in a client and a authorization server, and may be included in an access token for validation by a resource server.

The grant types currently specified include:

  • Authorization (code) grant

    A flow used by confidential clients. The client interacts with the resource owner and interfaces with an authentication server through a user-agent. The resource owner authenticates to an authorization server who issues an authorization code to the client. The client then uses the authorization server to exchange its authorization code for an access token it can use to access the resource server on behalf of the resource owner

  • Resource owner password (credentials) grant

    A flow used in cases where the resource owner has a trust relationship with the client. An example of this type of relationship is a user (resource owner) with a mobile device (client). In this flow, the client and resource owner work together to authenticate to an authorization server who issues an access token to the client. The client manages the access token and uses it to access the resource owner’s data on the resource server.

  • Client credentials grant

    A flow that is used only when the client is a trusted application. For example the client may be a partner company’s business application who is also a resource owner. This is a very simple flow where the client authenticates to the authorization server using its own user-id and password and receives an access token in response. The client uses the access token to access data on a resource server

    .
  • Implicit grant

    A flow often used by a public client. In this flow, the client initiates the flow by directing a user-agent to an authorization server who interacts with and authenticates the resource owner. If the resource owner grants the client access to their data, the user-agent is sent an access token it can use on behalf of the client when the client accesses the resource server.