What You Need to Implement

OAuth 2.0 Endpoints

To implement OAuth 2.0 is to implement two endpoints in order to issue an access token. One is the authorization endpoint, and the other is the token endpoint. These are called OAuth 2.0 endpoints. RFC 6749, the specification of OAuth 2.0, describes how the two endpoints should behave.

To implement OpenID Connect is to extend the 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 consists of the authorization endpoint and the token endpoint. If, however, you choose not to support some of the grant types defined in RFC 6749, either the authorization endpoint or the token endpoint may be enough. For example, the Implicit Grant requires only the authorization endpoint.

The primary purpose of Authlete is to provide Web APIs which enable developers to implement the OAuth 2.0 endpoints very easily. Furthermore, if you use the default implementations of the OAuth 2.0 endpoints provided by Authlete, you don’t have to do programming at all.

Client Application Management

A natural consequence of the specifications is that a Web service must manage third-party client applications. In a typical case, a service treats its end-users as developers and allows them to register client applications.

Authlete provides Web APIs to manage (create / delete / get / update) client applications. You may directly call the Web APIs or build tools using the Web APIs, but the simplest way is to use Developer Console Authlete provides. Developers of client applications for your service can manage their client applications using Developer Console.

Protected Resource Endpoints

A Web service is supposed to provide Web APIs through which client applications can access end-user’s data. Such 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 implementation of the protected resource endpoint must check whether the access token has enough privileges to access the protected resource before returning the resource to the client application.

Authlete provides a Web API to get information about an access token. Implementation of protected resource endpoints are supposed to use the API.

A Web API to get information about an access token is called introspection API. Very recently (Oct. 2015), RFC 7662 was released as a specification of introspection API. Authlete’s introspection API is different from RFC 7662 but we think developers will feel it is much more useful. Please see “Technical Note” in “Amazon API Gateway + AWS Lambda + OAuth, Summary” as to why.