Page Comparison

Meeting 18/1/16 to take forward task point 1 for prefs editor integration

...

HOWEVER, we nonetheless expect these endpoints (in the particular variant of OAuth 2 which we are planning to deploy here, the AUTHORIZATION CODE workflow) to be hosted on DISTINCT ORIGINS (in terms of HTTP’s Same Origin Policy) in order to prevent leakage of credentials into the preferences consumer’s origin. (Recheck and refine this point in next meeting)

...

   b) The EDGE PROXY SERVER which receives requests issued by the end user targetted at the authorization server - in particular all those listed on the GPII OAuth 2 Guide -

  /authorize - QUESTION - why does the demo not visibly use this endpoint?

...

1. User is on the site belonging to the preferences consumer. Embedded on it is a prefs editor which they have interacted with. They select an action which requires interaction with the prefs server (in the wireframes, Import or Export) Step 0

2. We enter Step 1 of the OAuth flow - the user’s browser is redirected to GET <authorization-server>/authorize - Step 1a - they see a LOGIN UI (implemented by the GPII authorization server)

   1. This endpoint is NOT exposed at the same origin as the preferences consumer to avoid leakage of these credentials

   2. In the current authorization server endpoint this is exposed at the URL /login

   3. The authorization server’s endpoint /login will need to be exposed by the overall cluster’s proxy configuration at a distinct origin

3. The login UI redirects the user back to the consumer’s space, now including an AUTHORIZATION CODE in the URL - Step 2. This can be read from the consumer’s origin by client or server-side code.

4. Step 3 - this is then separately provided to the /access_token endpoint to exchange for an access token which can be used in further requests for preferences

   1. The /access_token endpoint *is* proxied by the edge server.

   2. Part of this POST body is the client secret. It appears that providing this is the key responsibility of the multi-personality server. It will be maintained securely in its configuration and fished out when it receives a matching request from the edge server.

5. The access token can be used in preferences endpoints.

   1. Question - is identication purely by access token sufficient for all of these endpoints? it appears that the authorization server can always decode the preferences consumer’s id by fishing this out of its tables indexed by the token - does this mean that the edge server’s actions for all these endpoints can just be a no-op proxying?

   2. Question - i) do we still need two different grant types (authorization code, and client credentials) - ii) does the presence of these different grant types have any implications at all for the implementation of the edge and proxy servers?

Anchor
flowDiagram flowDiagram

Flow of information diagram (25-Feb-2021)