Asp.net core 2 AuthenticationProperties, хранящие токены jwt - PullRequest
0 голосов
/ 28 сентября 2018

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

.AddOpenIdConnect("Test", options => {  
                options.SaveTokens = true;
}

Из того, что я прочитал, они сохраняютсяв коллекции AuthenticationProperties, возвращенной вместе с ClaimsPrincipal.Вы можете получить их через HttpContext.GetTokenAsync.

Пример ниже:

var accessToken = await HttpContext.GetTokenAsync("access_token");

Я пытаюсь понять, как эти значения хранятся и извлекаются.Я знаю, что пункт утверждений - это набор идентификаторов / утверждений, связанных с пользователем.Но как именно устанавливаются свойства аутентификации?Как я могу получить доступ к коллекции свойств аутентификации индивидуально?Есть ли класс / интерфейс, который я могу использовать, чтобы получить прямой доступ к свойствам класса?Я ничего не видел о свойствах аутентификации в классе ClaimsPrincial.

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

1 Ответ

0 голосов
/ 22 ноября 2018

Я тоже немного в этом разбираюсь.Промежуточное программное обеспечение OpenID Connect обычно сохраняет данные в подписанный файл cookie с помощью второй схемы проверки подлинности, заданной параметром SignInScheme.Расширяя ваш предыдущий пример с помощью явно сконфигурированного примера:

.AddOpenIdConnect("Test", options => {  
    options.SignInScheme = "MyCookieScheme";
    options.SaveTokens = true;
}

В этом примере подразумевается, что схема проверки подлинности cookie также была настроена с помощью вызова, подобного этому:

.AddCookie("MyCookieScheme")

Изкомментарии к документации по SignInScheme:

Получает или задает схему аутентификации, соответствующую промежуточному программному обеспечению, отвечающему за сохранение личности пользователя после успешной аутентификации.Это значение обычно соответствует промежуточному программному обеспечению cookie, зарегистрированному в классе Startup.Если не указано, Microsoft.AspNetCore.Authentication.AuthenticationOptions.DefaultSignInScheme используется в качестве запасного значения.

(обратите внимание, что это свойство на самом деле происходит из класса RemoteAuthenticationOptions, который расширяется OpenIdConnectOptions)

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

Что касается того, чтона самом деле хранится в файле cookie, и как он помещается туда промежуточным программным обеспечением OpenID Connect, вам, вероятно, придется много покопаться во всем коде, чтобы точно это решить - специфика всего этого промежуточного программного обеспечения низкого уровня неКажется, еще много задокументировано.Все, что я точно знаю, это то, что промежуточное программное обеспечение DataProtection участвует в шифровании содержимого файла cookie.

Вы можете посмотреть, как расшифровать сам файл cookie, чтобы увидеть, что там есть - см. Ответы здесь: Как вручнуюрасшифровать файл cookie проверки подлинности ядра ASP.NET?

(о, и для записи, все эти примеры основаны на ASP.NET Core v2.0)

...