Имаме работещ 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
?
Някои специфични опасения в рамките на въпроса
- Каква е вътрешната структура на този низ
access_token
? - Криптиран ли е, подписан или и двете? Какъв е ключът, който се използва (да приемем IIS/Azure Cloud Service)?
- Как можем да отменим изпълнението, което генерира действителния изпратен низ и след това проверява същия токен/низ при последващи достъпи?
Благодаря