Использование Google OAuth для защиты веб-сервисов в ядре aspnet

Я теряюсь в промежуточном программном обеспечении OAuth и OpenIDConnect и ядра aspnet. Любая помощь в этом будет оценена по достоинству.

У меня есть несколько пользовательских интерфейсов (веб-приложений, нативных приложений), которые используют один и тот же набор веб-служб, и я хотел бы, чтобы только пользователи, прошедшие проверку подлинности, могли получить доступ к веб-службам. Моя организация использует учетные записи Google, поэтому я хочу использовать проверку подлинности Google только для домена организации.

Веб-сайт надлежащим образом требует аутентификации в соответствии с этот образец. Теперь мне нужно, чтобы веб-сайт (AngularJS 4) вызывал мои серверные веб-службы с токеном аутентификации, который я могу проверить с помощью Google.

Серверные службы написаны на ядре aspnet. Я пытался использовать следующие подходы: ПО промежуточного слоя Google и Google OpenIDConnect, но они по-прежнему 1) предполагают наличие пользовательского интерфейса, который может предложить неавторизованному пользователю войти в систему, и 2) кажутся основанными на файлах cookie, и я не будут иметь файлы cookie для вызовов веб-службы.

Я не хочу предлагать пользователю войти в систему, поскольку «пользователь» в данном случае является программным клиентом. Либо они аутентифицированы, либо еще нет. Мне просто нужно получить токен аутентификации, подтвердить его и продолжить.

Похоже, это то же самое вопрос, на который тоже пока нет ответа.

Любые предложения приветствуются. Кроме того, предложения или советы по использованию нативных приложений делают то же самое!


person Celeste    schedule 14.07.2017    source источник


Ответы (2)


Получил это работает. Как уже упоминалось, я заблудился, и OpenIDConnect, хотя и упоминается в нескольких областях как решение, был отвлекающим маневром для веб-сервисов. Вот что у меня работает сейчас, с максимально полными шагами, которые я могу предоставить (требуется некоторая очистка):

  1. Добавьте аутентификацию в пользовательский интерфейс, следуя этим инструкциям.
  2. Получите токен JWT как показано в первом сегменте здесь
  3. При каждом вызове веб-службы включайте токен JWT в заголовки:

    Имя: Аутентификация

    Значение: носитель {значение токена}

  4. Установите пакет JwtBearer NuGet.

  5. В методе ConfigureServices Startup в веб-службе после того, как вы AddMvc():

        services.AddAuthorization(options =>
    {   // this policy needed only if you want to restrict to accounts within your domain. otherwise, don't use options. or use whatever options work for you.
            options.AddPolicy("hd",
                policy => policy.RequireAssertion(context =>
                    context.User.HasClaim(c =>
                        c.Type == "hd" &&
                        ("https://accounts.google.com".Equals(c.Issuer) ||
                         "accounts.google.com".Equals(c.Issuer, StringComparison.CurrentCultureIgnoreCase)) &&
                        c.Value == "yourdomain.com"
                    )));
    });
    
  6. В методе Configure перед использованием UseMvc():

            JwtBearerOptions jwtOptions = new JwtBearerOptions();
            jwtOptions.Audience = "{the OAuth 2.0 client ID credential from google api developer console}";
            jwtOptions.Authority = "https://accounts.google.com";
            jwtOptions.TokenValidationParameters = new TokenValidationParameters();
            jwtOptions.TokenValidationParameters.ValidIssuers = new List<string>()
            {
                "https://accounts.google.com",
                "accounts.google.com"
            };
    
            app.UseJwtBearerAuthentication(jwtOptions);
    

Возможно, есть более подходящий способ сделать это... если есть, мне интересно его попробовать. На данный момент это работает.

person Celeste    schedule 21.07.2017

Я постараюсь помочь.

Сначала вам нужно взглянуть на OpenID Connect (который построен на основе OAuth 2.0), помня, что OAuth 2.0 НЕ является протоколом аутентификации.

1) предполагается наличие пользовательского интерфейса Пользовательский интерфейс не требуется для входа в систему, если вы используете службы Google. Вам нужно только проверить наличие и подтвердить токен доступа, токен идентификации (и, возможно, токен обновления). Если токена нет, предположите, что пользователь НЕ прошел аутентификацию, и перенаправьте его на сервер аутентификации с запросом авторизации.

Если есть действительный токен доступа и токен обновления, вы можете предположить, что пользователь прошел проверку подлинности.

Вы также можете проверить токен доступа на наличие правильных «Областей», чтобы определить, авторизованы ли они для вашего конкретного приложения.

Если вы используете Google для сервера авторизации, вы можете проверить параметр hd внутри Identity Token есть желаемый домен.

Кстати: файлы cookie не задействованы.

Надеюсь, это поможет.

person jwilleke    schedule 14.07.2017
comment
спасибо, я понимаю концепции и поток (я думаю). Проблема, с которой я сталкиваюсь, заключается в том, что все промежуточное программное обеспечение, которое я нашел до сих пор, предполагает, что вы будете использовать пользовательский интерфейс для входа в систему. Я не нашел никаких примеров или документации о том, как иметь клиента, который уже вошел в систему отправить правильные токены для проверки на стороне сервера с вызовом веб-службы. я хотел бы использовать атрибут [Authorize] на контроллерах и иметь правильное промежуточное программное обеспечение для проверки соответствующего токена с помощью Google. мне нужно написать собственное промежуточное ПО для этого, или оно уже существует? - person Celeste; 14.07.2017
comment
Кажется, я не понимаю. В OAuth и OIDC есть 4 игрока. Владелец ресурса (пользователь) и клиент OAuth (приложение), поставщик OIDC (Google в вашем примере) и сервер ресурсов (который содержит защищенный ресурс). Когда вы говорите, что клиент, который уже вошел в систему, о чем вы говорите? Как правило, ожидается, что клиент OAuth выполнит проверку возвращенных токенов, чтобы убедиться, что они не были подделаны и что они действительно были возвращены надлежащим поставщиком OIDC, а не каким-то посредником. Есть много библиотек, которые СЛЕДУЕТ использовать для этого. - person jwilleke; 15.07.2017
comment
Спасибо, что были терпеливы со мной. Позвольте мне посмотреть, могу ли я уточнить: у меня есть 2 клиента OAuth: веб-интерфейс и веб-службы. они не выполняются как часть одного и того же процесса; они работают на разных серверах. веб-интерфейс может пройти весь процесс OAuth, используя библиотеку javascript Google. После этого пользователь должен иметь возможность использовать веб-интерфейс, который, в свою очередь, вызывает различные веб-службы. Таким образом, пользовательский интерфейс получил некий токен, который следует включить в вызовы веб-службы, и веб-служба должна проверить этот токен. - person Celeste; 17.07.2017