Question: OAuth2.0 flow

[ankurLalitAtPropertyMe]

Hi Team,

What you have achieved here is fantastic by all means and fills a huge gap in achieving a separation between apps that want a token and the intermediary that interacts with the IDP.

My question is around its adherence to Authorization code grant flow. According to the post here

and its point 3b states "After successful authentication the provider redirects the user to https://AUTH_DOMAIN/oauth2/idpresponse with either an authorization token in the “code” query parameter or a SAML assertion in a POST request".

This would mean that the broker in your implementation, after successful authentication should not get hold of any tokens from Cognito. Instead the caller should get a redirect 302 to the application where the request originated from. 
What I see in Network Trace is that there goes a POST to Cognito using AWSCognitoIdentityProviderService.RespondToAuthChallenge and the very next call is to AWSCognitoIdentityProviderService.GetUser which contains AccessToken in its request. This means that the Amplify library or custom code that is making these calls in the Broker is using a process flow that is different from the standard OAuth2.0 flow. The tokens should have been unavailable to the broker unless the request originated from the broker and the clientid was of the broker itself. The only way to obtain tokens should have been after the redirection to the originating app using the code in the query string by querying the token endpoint of the broker.

Do you see a scope of improvement in the Broker (Amplify) or its communication with Cognito such that the Standard OAuth 2.0 flow is achieved?