Amplify-js: How to disable calls to `AWSCognitoIdentityProviderService.GetUser` when `aws.cognito.signin.user.admin` is disabled?

[danludwig]

* Which Category is your question related to? *
Auth

* What AWS Services are you utilizing? *
Cognito User Pool

* Provide additional details e.g. code snippets *

I searched the issues before posting this, but am still looking for an answer. It seems that the amplify javascript sdk will always make 2 calls to POST https://cognito-idp.{region}.amazonaws.com using the X-Amz-Target: AWSCognitoIdentityProviderService.GetUser header after a successful user login, and we would like to disable these. They succeed when the aws.cognito.signin.user.admin oauth scope is allowed, but when disallowed, they return a 400 Bad Response.

We have the oauth scope in question disabled and want to keep it disabled. I found a similar question in #1262, but the answer only says it is "expected behavior" with no explanation as to why. Our app functions perfectly fine when the scope is disabled and the requests error out. Can we disable the calls? If so how, and if not, why?

I also read #1906, #2251, and #1813, and updated our aws-amplify dependency to 1.1.22, but still seeing the same behavior.

[jordanranz]

https://github.com/aws-amplify/amplify-js/issues/1262 does give a reason why: "to get the user attributes for the current authenticated user". Are you asking more why it is getting the user attributes?

[danludwig]

@jordanranz the only user attributes we ever need are already embedded into the id jwt that we get after authentication, so we can just read them from there. Our user pool has a SAML idp, so we just map the saml claims to user attributes, and we have the user admin scope turned off to deny users the ability to mutate them.

Like I said: both of the API calls fail, so we never get those user attributes anyway from those calls. We are happy to just read them as immutable values from the id token, and want to disable the additional call to load them from the user pool

[jordanranz]

@danludwig, just to clarify, are you using the Auth.signIn method?

[danludwig]

@jordanranz no we are not.

first we try to detect whether there is a current authenticated user using Auth.currentAuthenticatedUser().

When that call throws an error, we manually construct a URL to the cognito hosted UI using our custom domain, then window.open that URL in _self. The URL looks something like this:

https://{my-custom-domain}.auth.{region}.amazoncognito.com/oauth2/authorize?idp_identifier=foo&response_type=code&etc..

This will then redirect to a SAML Idp and, upon successful login there, redirect back to our app client's CallbackURL. On that CallbackURL route, we invoke Auth.configure so that the amplify library will exchange our code for the JWT's. We then listen for the auth onHubCapsule cognitoHostedUI event to complete the login after the tokens have been obtained from the user pool.

It is the Auth.configure invocation that leads to the other 2 failing network calls out to retrieve user attributes.

[jordanranz]

Ok, thanks @danludwig, I'll mark this as a bug for right now. There should probably be a way to avoid making the call to Cognito for this use case. We'll deep dive into this and follow up after.

We appreciate the feedback.

[danludwig]

@jordanranz certainly, and thank you for giving it attention.

[jordanranz]

No problem, expect a response by end of day tomorrow.

[elorzafe]

@danludwig we reproduce this issue and with @powerful23 we are working on pr to fix this. Thanks!

[danludwig]

@elorzafe that's great news, thanks! Will look for the PR when you link it up to the issue.

[danludwig]

@powerful23 Thanks for the quick turnaround on this.

I was looking at the code in your PR, and noticed this:

if (scope.split(' ').includes(USER_ADMIN_SCOPE)) {

Correct me if I'm wrong, but doesn't Auth.config() allow you to pass an empty array for scopes to automatically include all scopes that are allowed in the app client? Would this if block do the wrong thing for an app client that has the user admin scope enabled, but only specifies an empty array for the scopes when configuring auth?

You know more about it than me, but just reading over what is in there now, that jumped out at me, so thought I would ask the question. HAGW!

[powerful23]

@danludwig the scope in the config object is only used when using Cognito's OAuth feature(Also as know as Cognito Hosted UI) to allow the developers to specify the scopes of the token: https://docs.aws.amazon.com/cognito/latest/developerguide/authorization-endpoint.html

This will not impact this change because we are always reading the scope by decoding the current access token which will ensure whether we have the permission to make this call.

[nihp]

I am disabled the user in cognito, when the user is in the app. But it not return any error. Still the user can able to access the app.

How can I know the user is disabled?
How long the user can access the app after disabled?
Any calls to check this?

I am using aws-amplify-react-native.