AWS Усиление аутентификации с помощью пула пользователей Cognito, не возвращающего nonce или at_ha sh претензию в id_token JWT - PullRequest
Новая
       23

AWS Усиление аутентификации с помощью пула пользователей Cognito, не возвращающего nonce или at_ha sh претензию в id_token JWT

0 голосов
/ 19 февраля 2020

Я пытаюсь использовать Amplify Auth для реализации неявного потока OpenID Connect для предоставления единого входа нескольким клиентам React.

Мне удалось заставить это работать с Cognito Hosted UI, но для этого требуется, чтобы другие пользователи приложений нажимали кнопку для подтверждения входа в систему для аутентификации. Я бы предпочел, чтобы оно было бесшовным ie, когда пользователь вошел в систему на одном сайте и перешел на другой, он автоматически аутентифицируется, если у него есть сеанс с поставщиком аутентификации.

Чтобы попытаться добиться этого, я создал отдельное приложение Amplify, которое использует компонент React Authenticator.

Я могу пройти аутентификацию и перенаправить обратно к клиенту. Однако id_token не содержит претензий at_hash или nonce. Предположительно, at_hash отсутствует, поскольку приложение провайдера аутентификации не отправляет responseType из token id_token, когда оно аутентифицируется с помощью Cognito. nonce отсутствует, потому что я не нашел способа передать его.

  1. Есть ли способ заставить Amplify Authenticator SignIn запросить id_token с at_hash претензия?

  2. Можно ли передать nonce значение в id_token претензии?

Примечание Я пытаюсь придерживаться: https://openid.net/specs/openid-connect-core-1_0.html#ImplicitFlowSteps Специально для этой части: 3.2.2.10. Идентификационный токен 

import React from 'react';
import { Authenticator, ConfirmSignIn, SignIn } from 'aws-amplify-react';
import Amplify, { Auth } from 'aws-amplify';
import awsconfig from './aws-exports';

Amplify.configure(awsconfig);

const getSearchParams = () =>
    window.location.search.substr(1);

const getValueFromSearchParam = (key) =>
    new URLSearchParams(getSearchParams()).get(key);

const getRedirectUri = () => {
    const redirect_uri = getValueFromSearchParam('redirect_uri');
    return redirect_uri ? decodeURI(redirect_uri) : null;
};

const Login = () => {
    const handleAuthStateChange = (state) => {
        if(state === 'signedIn') {
            const redirect_uri = getRedirectUri();
            const state = getValueFromSearchParam('state');
            if(redirect_uri === null) {
                throw new Error('No redirect_uri provided');
            }
            Auth.currentSession().then(currentSession => {
                const id_token = currentSession.idToken.jwtToken;
                const access_token = currentSession.accessToken.jwtToken;
                const redirect = `${redirect_uri}#access_token=${access_token}&id_token=${id_token}&state=${state}`;
                window.location.replace(redirect);
            }).catch(err => console.error(err));
        }
    };

    return (
        <Authenticator
            hideDefault={true}
            onStateChange={handleAuthStateChange}
        >
            <SignIn  />
            <ConfirmSignIn/>
        </Authenticator>
    );
};

1 Ответ

1 голос
/ 19 февраля 2020

Вот несколько вопросов, которые могут представлять интерес:

  • Cognito не хватает поддержки на основе стандартов, как вы заметили
  • Если вы используете response_type = token id_token, вы будете ограничены для фиксированных 60-минутных пользовательских сессий
  • Усиление может быть не самой стандартной библиотекой с точки зрения параметров nonce и т. д. c
  • В настоящее время для SPA рекомендуется использовать код авторизации (PKCE) - вы может оказаться, что это проще для реализации проверок после входа в систему, которые вы ищете

К сожалению, вам может понадобиться сделать некоторые компромиссы при работе с Cognito - и сделать «наименее плохой выбор». Если это поможет, вот кое-что, с чем можно сравнить:

...