-
Notifications
You must be signed in to change notification settings - Fork 3
API specification
This Solution exposes a public web service for generating and retrieving access tokens.
This service acts as a “buffer” layer between the external world and hidden authentication services. This service does not persist any data and acts as a facilitator between the user and the different sub-services that persist data.
This service is responsible for the runtime encryption/decryption of access tokens and the sending and receiving of this data to the relevant data storage services. Requests made to these subsystems are authenticated using an internal API Key stored as a setting value. This is done to firstly place some layer of security on the service between the public API and the sub-services. Secondly, in cases where you want to split up the sub-services onto their own servers, this allows a simple way of applying security.
When a token retrieval request is received, a request is made to the ‘user admin API’ to validate the API Key. The user admin service responds with the encryption key associated with the service provider and API Key. This key data is passed through to the operation of the request to be used to encrypt and decrypt the access tokens.
Generic standalone service to manage and validate user related API keys. This service is responsible for the generation of API Keys and encryption keys used for encrypting/decrypting the access tokens.
This service is responsible for the initial storage of the state and encryption key and subsequent storage and retrieval of access tokens. The idea here is that this is purely a database layer that stores and sends data without business logic.
Generic standalone service to generate the redirection URL and handle the exchange of the authorization code for the access tokens. This service manages the authorization server related tasks and credentials.