API security specification

As explained in the LiquidFeedback API specification, the current authentication interface is preliminary and only provided for testing purposes. On this page the necessary TODOs will be discussed, to create a new authorization scheme.

It is currently planned to use  OAuth 2.0 for this purpose.

Fields of activity

• Client registration (system-wide and per user)
  • Concept for registration
  • Extend database scheme in lfcore, see  liquid_feedback_core source repository
• Change API specification and lfapi implementation to comply with the  Bearer Token specification
• Provide Authorization Endpoint(s) and Token Endpoint(s) in API specification and lfapi implementation

Important things to keep in mind for implementation

The authorization server MUST include the HTTP "Cache-Control" response header field (RFC2616) with a value of "no-store" in any response containing tokens, credentials, or other sensitive information, as well as the "Pragma" response header field (RFC2616) with a value of "no-cache".

Parameters sent without a value MUST be treated as if they were omitted from the request. The authorization server MUST ignore unrecognized request parameters. Request and response parameters MUST NOT be included more than once.

Client registration

Two forms of client registration are supported. System-wide client registration and per-member client registration. Registered clients are stored in the api_client table of the LiquidFeedback Core. For system-wide clients, the field member_id is set to NULL, while for member-registered clients, the field member_id is set to the id of the member, who registered this client for him/herself.

Unregistered clients use a client_id identical to their Redirection Endpoint, when directing the member to the Authorization Endpoint. The member is then asked automatically if he/she wants to register this client.

Supported authorization grant types

Authorization Code Grant

[TODO]

Access Tokens can be refreshed using the Token Endpoint.

Implicit Grant

[TODO]

Access Tokens can not be refreshed. If an access token has expired, the end-user must be redirected to the LiquidFeedback Security Center, to confirm access for the API consumer again.

Resource Owner Password Credentials Grant

Not supported for security reasons.

Client Credentials Grant

Supports read access only.

[TODO]

As there will be no Refresh Token issued, Access Tokens acquired by this grant type can not be refreshed using a Refresh Token. However at any time an API consumer can use its client credentials again, to receive a new Access Token.