amplify-js: auth w/ Google Federation - Access Token does not have required scopes

Describe the bug Upgraded from "@aws-amplify/auth": "3.2.7" to "@aws-amplify/auth": "3.2.8" and a federated login with Google stopped working with a 400 error from Cognito.

I initially upgraded to 3.2.8, and then downgraded back to 3.2.7, and downgrading has resolved the error. None of the dependency versions for "@aws-amplify/auth" were changed during the downgrade, so I believe the bug is specifically within the auth package.

Likely related to:

To Reproduce Using "@aws-amplify/auth": "3.2.8", login with a federated user and retrieve the session.

Expected behavior It doesn’t 400 and passes the scopes correctly.

Code Snippet

Screenshots CognitoError

What is Configured?

Smartphone (please complete the following information):

  • Device: Mac
  • OS: OSX 10.15.4
  • Browser: Chrome
  • Version: 81.0.4044.138

Additional context

About this issue

  • Original URL
  • State: closed
  • Created 4 years ago
  • Reactions: 5
  • Comments: 22 (6 by maintainers)

Most upvoted comments

How can Amazon, AWS and Cognito have a javascript client with 642 open issues, and a major issue like this that affects Cognito opened 8 months ago that hasn’t had any activity in over a month?

Last update from me:

I have been testing Allowed OAuth Scopes and I fixed my problem: For some reason, the hosted UI for both email and password and SSO, as well as the Auth.federatedSignIn({provider: 'Google'}) call require the aws.cognito.signin.user.admin scope to be enabled to fetch and update user attributed. However, a call to Auth.signIn(email, password) does not. I don’t fully understand why though, as the documentation doesn’t seem to mention this.

This is not a bug with amplify per-se, it’s an issue with Cognito & federated/SSO auth - if you look at the network tab when you call await Auth.currentUserinfo(), you can generate a curl command to replicate this outside of the js library

curl 'https://cognito-idp.us-east-1.amazonaws.com/'  --data-raw '{"AccessToken":"<token>"}' ```  

which results in a 400 response with a response:  

```{"__type":"NotAuthorizedException","message":"Access Token does not have required scopes"}

I have the exact same problem, where users from external identity providers (federated) cannot update their attributes. Any updates on this?

@menendezjaume hmm, I did have the aws.cognito.signin.user.admin in my scopes but I didn’t have to enter that manually, I believe it was generated by the CLI when I went through the auth setup and went down the OAuth route 🤔

I will reach out to the team with this issue and update the docs to reflect this. Thank you for pointing that out!

Small nit:

I have re-tried the whole thing and I’ve got two users (one using google SSO and one using email and password); and here are the results of some tests I’ve just made:

  • Authenticating with email and password using Auth.signIn(email, password) returns a token that works perfectly and is capable of retrieving all user attributes.
  • Authenticating with email and password using the hosted UI returns a token that gives me a 400 when attempting to retrieve the user attributes.
  • Authenticating with Auth.federatedSignIn({provider: ‘Google’}) or the hosted UI using and using Google SSO returns a token that gives me a 400 when attempting to retrieve the user attributes.

That being said, closing this out as we have a working solution in the necessary step of making sure the aws.cognito.signin.user.admin scope is included, in addition to not having heard back from the original poster.

If you try the above and it still does not work for you, please open a separate issue with your particular auth configuration so we can better find the cause of the issue in your case. Thank you!

Good evening, everyone 👋 Wanted to give an update on this issue before the weekend.

We have have been trying to reproduce this issue this on @aws-amplify/auth@3.2.8 and 3.2.7 as mentioned in the original comment.

We have to yet to reproduce this issue with a Google OAuth flow but we will continue to look into it. Below are the current results of the attempts to reproduce.

In the meantime, here is the code and amplify config used during testing. I highly encourage anyone to use this code, check out this Google OAuth test project from github: https://github.com/chrisbonifacio/amplify-issues/tree/main/5921-oauth-google, or start up a fresh project and take the same steps to reproduce the issue and share as many details as you can about how you got there or share the code.

Some follow up questions:

  • what other packages are you using alongside @aws-amplify@3.2.8?
  • does this occur in both a dev and prod environment for you?

package.json

{
  "name": "5921-oauth-google",
  "version": "0.1.0",
  "private": true,
  "dependencies": {
    "@aws-amplify/auth": "3.2.8",
    "@testing-library/jest-dom": "^5.11.4",
    "@testing-library/react": "^11.1.0",
    "@testing-library/user-event": "^12.1.10",
    "react": "^17.0.2",
    "react-dom": "^17.0.2",
    "react-scripts": "4.0.3",
    "web-vitals": "^1.0.1"
  },
  "scripts": {
    "start": "react-scripts start",
    "build": "react-scripts build",
    "test": "react-scripts test",
    "eject": "react-scripts eject"
  },
  "eslintConfig": {
    "extends": [
      "react-app",
      "react-app/jest"
    ]
  },
  "browserslist": {
    "production": [
      ">0.2%",
      "not dead",
      "not op_mini all"
    ],
    "development": [
      "last 1 chrome version",
      "last 1 firefox version",
      "last 1 safari version"
    ]
  }
}

aws-exports.js

const awsmobile = {
    "aws_project_region": "XXXXX",
    "aws_cognito_identity_pool_id": "XXXXX",
    "aws_cognito_region": "XXXXX",
    "aws_user_pools_id": "XXXXX",
    "aws_user_pools_web_client_id": "XXXXX",
    "oauth": {
        "domain": "XXXXX.amazoncognito.com",
        "scope": [
            "phone",
            "email",
            "openid",
            "profile",
            "aws.cognito.signin.user.admin"
        ],
        "redirectSignIn": "http://localhost:3000/",
        "redirectSignOut": "http://localhost:3000/",
        "responseType": "code"
    },
    "federationTarget": "COGNITO_USER_POOLS"
};


export default awsmobile;

App.js

import React from "react";
import Amplify, { Auth } from "@aws-amplify/auth";
import awsconfig from "./aws-exports";
Amplify.configure(awsconfig);

const App = () => {
  const initialState = { session: null, user: null, userInfo: null };
  const [state, setState] = React.useState(initialState);

  const handleSignIn = async () => {
    await Auth.federatedSignIn({ provider: "Google" });
  };

  const getUser = async () => {
    const user = await Auth.currentAuthenticatedUser();
    const userInfo = await Auth.currentUserInfo();
    const session = await Auth.currentSession();
    console.log({ session, user, userInfo });
    setState({ session, user, userInfo });
  };

  React.useEffect(() => {
    getUser();
  }, []);

  const { user } = state;

  return (
    <div className="App">
      <button onClick={handleSignIn}>Open Google</button>
      <button onClick={getUser}>Get Current Session</button>
      <button onClick={() => Auth.federatedSignIn()}>Open Hosted UI</button>
      <button onClick={() => Auth.signOut()}>
        Sign Out {user?.getUsername()}
      </button>
    </div>
  );
};

export default App;


Results:

Screen Shot 2021-04-30 at 6 10 51 PM

Console logging Auth.currentSession, Auth.currentAuthenticatedUser, and Auth.currentUserInfo

Screen Shot 2021-04-30 at 6 12 40 PM

@mtraynham Can you check removing phone from authorized scopes, also check the settings for the App client like this Screen Shot 2020-05-29 at 9 31 40 AM