aws / aws-sdk-php

Official repository of the AWS SDK for PHP (@awsforphp)
http://aws.amazon.com/sdkforphp
Apache License 2.0
5.99k stars 1.2k forks source link

Unable to establish Cognito client connection #2944

Closed quinnjr closed 2 weeks ago

quinnjr commented 2 weeks ago

Describe the bug

As of roughly 2:00PM on 6/17/2024, we've been unable to establish client connections to Cognito to verify access tokens that are produced by the service.

Error output: Could not resolve an authentication scheme: The service does not supportsmithy.api#noAuthauthentication.

Expected Behavior

Connect to Cognito and verify access token

Current Behavior

No connection to Cognito can be established

Reproduction Steps

Example code:

try { // Verify access token with Cognito

    // Create Cognito client
    $client = new CognitoIdentityProviderClient([
        'region' => $config['aws']['region'],
        'version' => $config['aws']['version'],
        'credentials' => $config['aws']['credentials']
    ]);

    $cognito_user = $client->getUser(['AccessToken' => $data->accessToken]);

} catch (Exception $e) {
    $response['message'] = 'Invalid access token';
    //Update tracking api call request
    update_api_request($api_id, $response);

    http_response_code(401); // Unauthorized

    $logger->addRecord(Logger::ERROR, $e->getMessage());

    echo json_encode($response, true);
    exit;
}

$config['aws']['credentials'] is a correct associative array with valid access credentials.

Possible Solution

No response

Additional Information/Context

No response

SDK version used

3.314.3

Environment details (Version of PHP (php -v)? OS name and version, etc.)

PHP 8.2.15, Ubuntu 22.04

quinnjr commented 2 weeks ago

Confirming downgrading to 3.314.2 corrected the issue.

durimjusaj commented 2 weeks ago

Same issue, Confirming downgrading to 3.314.2 corrected the issue.

stobrien89 commented 2 weeks ago

Hi all,

Sorry to hear about the issues. Looking into this now.

stobrien89 commented 2 weeks ago

This was caused by a discrepancy in the noAuth value in our specification vs what was actually modeled. We recently released a feature which allows services to model multiple auth types for the service as a whole, as well as certain operations— the getUser operation uses the auth type that the discrepancy lies with. This should be fixed in today's release.

github-actions[bot] commented 2 weeks ago

This issue is now closed. Comments on closed issues are hard for our team to see. If you need more assistance, please open a new issue that references this one.