Protect communication between Local Flow Manager and Cloud Based Flow Manager

From wiki.gpii
Jump to: navigation, search


This wiki page collects thoughts and ideas gathered at GPII security meeting held at College Park face to face hackathon on Dec 8, 2016.

The meeting notes can be found at this GPII pad, the section for Dec 8, 2016


The workflow currently implemented for the GPII use case of the communication in between Local Flow Manager and Cloud Based Flow Manager does not have the authorization process in place to verify:

  1. The request is sent by an installation of the local flow manager;
  2. This local flow manager has been authorized by the settings owner to access his/her settings.

This means, all http setting requests in the format of :userToken/untrusted-settings/:deviceInfo received at the cloud based flow manager will be processed and the user settings will be returned, regardless of who/where those requests are sent from.

Collected Ideas towards Solution

OAuth Specifications Involved

The local flow manager is installed as a native application on a device used by a preference owner. These two OAuth specifications are applicable for this use case:

In-discussion authorization work flow

The use of GPII does not require users to login with their user names and passwords, instead, once a user token is provided via swiping a GPII card on a device etc, this user has authorized the local flow manger installed on that device to access his/her GPII preferences. Therefore, the workflow recommended in the best practice for using OAuth 2.0 for native apps is amended to accommodate this use case. The amended workflow also considers the extra protection suggested by the specification of using proof key for code exchange by OAuth public clients:

Authorization workflow in btw LFM and CBFM.png

Security Considerations

There are a few security considerations derived from the above workflow to ensure secured communications in between the local flow manager and the cloud based flow manager:

  • Protect GPII user tokens
  • Protect client identifier
  • Other security considerations

Protect GPII user tokens

In the face to face meeting, we discussed about splitting the structure of GPII user tokens into two parts. Using a simple example for easier explanation below, a user token could look like "1234abcd".

Part 1: This part is enough to identify who the user is but it is not associated with any sensitive user information such as user's preferences. This part gets sent to the cloud in the http URI. Assuming "1234" given in the user token example represents this part, the untrusted settings request URI received at the cloud flow manager would look like: 1234/untrusted-settings/:deviceInfo

So it's safe to continue to log the http URI for debugging or auditing purposes.

Part 2: The other part is associated with user's preferences and should never appear in plain text in query strings or logs. This part will be sent along with the untrusted settings request in the http header "authorization" field. Assuming "abcd" given in the user token example represents this part, the http header could look like: Authorization: Basic base64("abcd")

"abcd" is encoded when being embedded into the "Authorization" header and needs to be decoded by the cloud based flow manager.

Protect client identifiers

Each installation of Local Flow Manager as an OAuth2 client is identified using the combination of three elements: a client id, a client secret and a pre-registered redirect URI. A pre-registered redirect URI must be provided at registering an installation of the local flow manager as an OAuth client to compensate the weakness of having the client secret being saved on the insecured user's device, which results in the fact that the client secret cannot be assumed as confidential and can be relied on to verify the client. The format of the redirect URI is, the loopback URI suggested in the specification of OAuth 2.0 for Native Apps.

Other security considerations

  • Local flow managers should open the loopback port only when starting the authorization request, and close it once the response is returned.
  • The authorization server should provide an end point for revoking client secrets.
  • Each installation of a local flow manager has its own client id/secret, so that the revocation of one client secret only affects one installation.
  • Have an alerting system to automatically detect and report on possible attacks or compromising of client secrets or access tokens.


Some OAuth 2.0 implementations for native applications:

Conclusions on the proposed solution

The meeting on Jan 4, 2017 points out these issues (See Meeting Notes):

  • The use of OAuth 2.0 for Native Apps ensures native apps don't have access to users' credentials, which is why the browser redirection is required. However, GPII local flow managers are aware of users' credentials, user tokens in this case.
  • The use of redirect_url is to redirect the authorization code response from the browser back to the native app, which is not applicable to the GPII local flow manager as the user credential is sent directly from the local flow manager to the GPII cloud without going thru the user sign-in stage.

Conclusions are:

To Be Continued