Служба пользовательских токенов для выдачи и проверки JWT - PullRequest
0 голосов
/ 07 декабря 2018

Нам необходимо разработать службу единого входа (SSO) для выпуска JWT для большого количества клиентов.Разработчикам этих клиентов также понадобится возможность проверить эти токены.Очевидно, что мы не можем предоставить им наш секретный ключ, который мы использовали для генерации этих токенов.Поэтому вместо этого мы решили предоставить им API-сервис двумя способами.Один для выдачи токена и второй для его проверки.

Я спрашиваю себя, идем ли мы к правильному подходу.Вот базовая схема, которая показывает, как пользователи будут работать со своими клиентами (защищенные приложения)

Fig. 1 - Basic scheme of users interactions

Пользователь регистрируется со своими учетными данными через наш сервис иполучает свой токен доступа.Затем его токен используется в заголовках запросов защищенного приложения.Клиентский модуль SSO - это AuthenticationHandler, который отправляет HTTP-запросы нашему сервису для проверки действительности токена.

Вот некоторый код из клиентского модуля SSO, который мы используем для проверки токена.Мы используем пользовательский обработчик аутентификации, который выполняет вызовы к удаленной службе единого входа:

internal class SsoAuthenticationHandler : AuthenticationHandler<SsoAuthenticationOptions>
{
    protected override async Task<AuthenticateResult> HandleAuthenticateAsync()
    {
        if (!TryRetrieveToken(Request, out var token))
        {
            return AuthenticateResult.NoResult();
        }

        if (await _ssoClient.ValidateTokenAsync(token))
        {
            return AuthenticateResult.Success(...);
        }

        return AuthenticateResult.NoResult();
    }
}

и SsoClient iself:

public class SsoClient
{
    public async Task<bool> ValidateTokenAsync(string token)
    {
        const string validateUrl = "api/auth/validatetoken";

        var address = $"https://{_ssoHost}/{validateUrl}";
        using (var httpClient = new HttpClient())
        {
            httpClient.DefaultRequestHeaders.Add("Authorization", $"Bearer {token}");
            var res = await httpClient.GetStringAsync(new Uri(address));
            reply = DeserializeSsoReply(res);
        }

        return reply.Succeeded;
    }
}

Я не смог найти лучшие практики для нашего сценарияпоэтому мне интересно, есть ли какие-либо возможные подводные камни, с которыми мы можем столкнуться при таком подходе?

1 Ответ

0 голосов
/ 07 декабря 2018

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

При получении мы подтверждаем, что аудитория верна (aka us), и этот подписавшийся является одним из настроенных подписывающих лиц.

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

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...