Как всъщност се създава маркерът OWIN OAuth 2?

Имаме работещ OWIN OAuth 2.0 (благодарение на тази фантастична публикация), но се нуждаеше от малко повече вникване в действителния процес на преобразуване на ClaimsIdentity в действителния низ access_token в HTTP отговора.

Създаваме ClaimsIdentity по този метод в нашия доставчик на OAuth оторизация:

public class SimpleAuthorizationServerProvider : OAuthAuthorizationServerProvider
{
    // <snip>
    public override async Task GrantResourceOwnerCredentials(OAuthGrantResourceOwnerCredentialsContext context)
    {
        // validation, user checking code here

        var identity = new ClaimsIdentity(context.Options.AuthenticationType);
        identity.AddClaim(new Claim("sub", context.UserName));
        identity.AddClaim(new Claim("role", "user")); 
        context.Validated(identity);
    }
}

И когато направим HTTP POST заявката като grant_type=password&username=user007&password=jamesbond (спокойно, паролата тук е ок), получаваме тялото на HTTP POST отговор

{"access_token":"9K8VtOBseU0-XZfdGe2_urn2HESY3jLkpgvowOQFPXsHeWNOrTlTVzfPu35ZEvr4AqSj_b0laesBegtVWuR8R-aItnNXw4vXiuCg0cTNMUKP_yfi89VhD446o2X6ffL8upwZVILpomweSweIVlDmwUDzIwf1ZqubrQ8vuiQDFu-_7vpjPwJ5yVvomQ75agsJWMZk-H_bVWSObds82aM8LCRJwb2bUJchr6_L1GP8xdXqRQz24uDhHvco-XByyMSMzZm-Qo0VVBbocbgP64OJulbihVG_W9e8G69UfbX99pIYiLyE4jixiUtjOKSiMYBISW3_fg","token_type":"bearer","expires_in":1799,"as:client_id":"","userName":"user007",".issued":"Fri, 31 Oct 2014 16:02:05 GMT",".expires":"Fri, 31 Oct 2014 16:32:05 GMT"}

Въпрос: Каква е логиката, която създава действителния низ access_token?

Някои специфични опасения в рамките на въпроса

  1. Каква е вътрешната структура на този низ access_token?
  2. Криптиран ли е, подписан или и двете? Какъв е ключът, който се използва (да приемем IIS/Azure Cloud Service)?
  3. Как можем да отменим изпълнението, което генерира действителния изпратен низ и след това проверява същия токен/низ при последващи достъпи?

Благодаря


person DeepSpace101    schedule 31.10.2014    source източник


Отговори (1)


Радвам се, че публикацията ми беше полезна, моля, намерете отговорите по-долу:

1 – Този „магически“ низ е шифрован или подписан низ (лоша MSDN документация, говори за шифроване или знак без яснота), която съдържа десериализираната версия на всички искове и свойства на билети за влезлия потребител. Ако е в режим IIS, криптирането/подписването се извършва чрез стойностите на ключовете „decryptionKey“ и „validationKey“ в възела machineKey (документация). Ако работи като самостоятелно OWIN приложение, криптирането използва наследения DPAPI, за да го защити и това всъщност използва остарелия 3DES алгоритъм (документация). Реализацията по подразбиране за него е в изходния код тук.

2 - Отговорено в точка 1.

3 - Проверете моя нова публикация, където показвам как да издавам подписани Json уеб токени вместо токен за достъп по подразбиране.

Надяваме се, че това отговаря на въпроса ви.

person Taiseer Joudeh    schedule 31.10.2014
comment
За 3-та точка на персонализиран токен, ако някой имплементира персонализиран CustomTokenFormat : ISecureDataFormat<AuthenticationTicket> и го предостави на свойството AccessTokenFormat на OAuthAuthorizationServerOptions, как може да наложи неговото валидиране по време на достъп? Това става ли автоматично чрез предоставяне на един и същ OAuthAuthorizationServerOptions обект (и следователно един и същ AccessTokenFormat) както на UseOAuthAuthorizationServer(..), така и на UseOAuthBearerAuthentication(..)? - person DeepSpace101; 02.11.2014
comment
Прав си, това става автоматично. Времето за изтичане на токена за достъп се задава с използване на свойството AccessTokenExpireTimeSpan в OAuthAuthorizationServerOptions, тогава това ще бъде част от свойствата на данните AuthenticationTicket, където можете да прочетете свойството ExpiresUtc в персонализирания клас за AccessTokenFormat, можете да го проверите тук: връзка - person Taiseer Joudeh; 02.11.2014
comment
@Taiseer Как работи дешифриращият ключ/ключът за валидиране с балансьор на натоварването пред множество екземпляри на сървър? - person Victor Mukherjee; 17.11.2017
comment
@VictorMukherjee - Намерихте ли някога отговора на този въпрос. Точно това се опитвам да разбера... използваме множество екземпляри на сървър, хоствани на windows azure, ако балансиращият натоварване изпраща заявки до различни машини, ще бъде ли валиден маркерът за достъп само на сървъра, на който е създаден? - person Matt Austin; 29.06.2020