Authorization Service Design

The authorization service provides an OAuth2 implementation built using the Fosite library. To accomplish this, it provides an HTTP interface that maps to internal Fosite calls and a data store adapter to allow authorization and identity data to be persisted to the Cassandra database.

Entry

The authorization service is started using the command line interface's host command. This results in the creation of a new App and DataStore and passes them to the HTTPController's constructor.

HTTP Controller

The HTTP controller is responsible handling incoming HTTP calls and delegating them to the Fosite library.

Token

The token endpoint accepts HTTP calls at the /oauth2/token endpoint. This implements the following OAuth2 grants:

• Resource Owner Password Credentials Grant
• Client Credentials Grant
• Refresh Grant

Support for the Authorization Code Grant and Implicit Grant will be added in future releases to offer better support for web applications. This will allow the built-in login endpoint to be used followed by a redirect to the provided client URI.

The underlying implementation of these grants is handled by the Fosite library. This design decision was made to save development time and avoid introducing bugs when implementing the OAuth2 protocol.

Revoke

The revoke endpoint accepts HTTP calls at /oauth2/revoke. Incoming calls are delegated to the Fosite library which instructs the DataStoreAdapter to remove the access token and associated refresh token from the database.

Register

There are two registration endpoints: Register and SubmitRegistration. Register is designed to handle get requests and display a HTML interface for registering new accounts. This design allows for the easy creation of new accounts. However, the purpose of the design was to provide a default login page for use with the Authorization Code Grant. In the future, this will allow the login page to redirect to a URI provided by the developer using the Authorization Service Command Line Interface.