Skip to main content

​
OAuth 2.0 Endpoints

An OAuth 2.0 authorization server must implement two endpoints in order to issue an access token: an authorization endpoint and a token endpoint. These are called OAuth 2.0 endpoints. RFC 6749, the specification of OAuth 2.0, describes how the two endpoints should behave. An OpenID Connect OpenID Provider extends the same two OAuth 2.0 endpoints in order to issue an ID Token. OpenID Connect Core 1.0 describes additional requirements for the two endpoints. There are other endpoints which are defined by the specifications, but they are optional. The minimum implementation of OAuth 2.0 and OpenID Connect generally comprises the authorization endpoint and the token endpoint. If, however, you choose not to support some of the grant types defined in RFC 6749, you may only need to implement one of the two endpoints. For example, the OAuth 2.0 Implicit Grant requires only the authorization endpoint. The primary purpose of Authlete is to provide Web APIs which enable developers to implement OAuth 2.0 endpoints very easily. In fact, it is possible to use Authlete’s default OAuth 2.0 endpoint implementations and write no code at all.

​
Client Application Management

The specifications define the role of third-party client applications that access protected resource endpoints (see below) on behalf of end users. Typically, a service allows third-party developers to register their client applications. Authlete provides Web APIs to manage (create / read / update / delete) client applications. You may directly call the Web APIs or build tools that call the Web APIs, but the simplest way is to use Authlete’s Developer Console. Developers of client applications for your service can also manage their client applications using the Developer Console.

​
Protected Resource Endpoints

A Web service provides Web APIs through which its client applications access end-users’ data. In the OAuth 2.0 context, these APIs are called protected resource endpoints. A client application accesses a protected resource endpoint with an access token which has been issued from either the authorization endpoint or the token endpoint. The protected resource endpoint implementation must verify that the access token has the correct privileges to access the protected resource before acting on the request. Authlete provides an introspection API to retrieve information about an access token. Implementations of protected resource endpoints use this API to determine the end user and permissions associated with the token and allow or deny the request accordingly.