У меня два приложения
Запланировали аутентификацию следующим образом
ТЕПЕРЬ НА СЕРВЕРНОЙ СТОРОНЕ ПРИЛОЖЕНИЯ CLEINT МНЕ НУЖНО ПРОВЕРЯТЬ, ЧТО ТОКЕН ПРИХОДИТ С КАЖДЫМ ЗАПРОСОМ, НЕ УКАЗАННЫЙ.
До сих пор я написал код ниже, чтобы просто создать POC.
========================= Конфигурация OWIN ========
[assembly: OwinStartup(typeof(WebApi.App_Start.Startup))]
namespace WebApi.App_Start
{
public class Startup
{
public void Configuration(IAppBuilder app)
{
HttpConfiguration config = new HttpConfiguration();
ConfigureOAuth(app);
WebApiConfig.Register(config);
app.UseCors(Microsoft.Owin.Cors.CorsOptions.AllowAll);
app.UseWebApi(config);
}
public void ConfigureOAuth(IAppBuilder app)
{
OAuthAuthorizationServerOptions OAuthServerOptions = new OAuthAuthorizationServerOptions()
{
AllowInsecureHttp = false,
TokenEndpointPath = new PathString("/token"),
AccessTokenExpireTimeSpan = TimeSpan.FromDays(1),
Provider = new SimpleAuthorizationServerProvider(),
};
// Token Generation
app.UseOAuthAuthorizationServer(OAuthServerOptions);
app.UseOAuthBearerAuthentication(new
OAuthBearerAuthenticationOptions());
}
}
}
==============================oAuth Provided========================
public class SimpleAuthorizationServerProvider: OAuthAuthorizationServerProvider
{
public override async Task ValidateClientAuthentication(OAuthValidateClientAuthenticationContext context)
{
context.Validated();
}
public override async Task GrantResourceOwnerCredentials(OAuthGrantResourceOwnerCredentialsContext context)
{
context.OwinContext.Response.Headers.Add("Access-Control-Allow-Origin", new[] { "*" });
using (AuthRepository _repo = new AuthRepository())
{
IdentityUser user = _repo.FindUser(context.UserName, context.Password);
if (user == null)
{
context.SetError("invalid_grant", "The user name or password is incorrect.");
return;
}
}
var identity = new ClaimsIdentity(context.Options.AuthenticationType);
identity.AddClaim(new Claim("sub", context.UserName));
identity.AddClaim(new Claim("role", "user"));
context.Validated(identity);
}
}
Пожалуйста помоги,
Спасибо,
@Павел





Please suggest me how to validate token in each request as i don't know the key the OWIN has used to generate the token.
Ваша текущая настройка, если вы добавили app.UseOAuthBearerAuthentication() в конвейер owin, будет аутентифицировать пользователя с помощью токена-носителя, который передается при каждом запросе для вас.
Текущего пользователя можно будет найти через HttpContext.Current.User.
Затем используйте атрибут Authorize, чтобы решить, какие пользователи авторизованы на определенных конечных точках.
Вот пример, когда пользователям с ролью «пользователь» разрешен доступ
[Authorize(Roles = "user")]
public class ValuesController : ApiController
{
}
Is is right to write code to validate token on client app or it should be on authication server.
НЕТ, вы не проверяете токен в клиенте, если ваши учетные данные неверны, вы вообще не получите токен. Это все, что вам нужно знать. А также, почему вы должны проверять токен на клиенте?
I am planning to shift all user management code like register user, change password to authentication server so than we can re-use it for different client app- is it right design practice?
Повторное использование поставщика токенов - обычное дело. Зачем изобретать колесо для каждого приложения? Создайте один отличный продукт или используйте сторонний продукт и повторно используйте его в своих приложениях.
Спасибо за ответ @Marcus.
Да добавлено app.UseOAuthBearerAuthentication (). Я видел, пытаюсь ли я получить доступ к любым ограниченным ресурсам с того же сервера авторизации (localhost: 58386) с недопустимым токеном, сервер внутренне проверяет токен и не разрешает доступ к этому методу. Но мое клиентское приложение находится в другом домене (localhost: 57543). Я хочу использовать один и тот же сервер авторизации (localhost: 58386) для аутентификации и авторизации всех [Авторизованных] методов, определенных в моем клиентском приложении (localhost: 57543)
Мне не удалось найти конфигурации, которые требуются в клиентском приложении, чтобы указать клиентскому приложению использовать сервер авторизации (приложение веб-API) для аутентификации и авторизации. Пожалуйста помоги.
@paulsim Вам необходимо разрешить клиентскому приложению декодировать и читать токен, сгенерированный из API авторизации. Оба приложения должны использовать один и тот же ключ компьютера. Вот отличный блог, который описывает этот шаг за шагом bitoftech.net/2014/09/24/…. Np, Если этот ответ был какой-либо помощи, пожалуйста, проголосуйте / примите.
Один из способов убедиться, что токен не был подделан, - это подписать его с помощью пары асимметричных ключей. Identity Server использует этот подход, как показано здесь.
В вашем случае, если вы запускаете собственную аутентификацию, вам нужно будет реализовать это самостоятельно и проверять каждый запрос, вероятно, в настраиваемом промежуточном программном обеспечении, что токен действителен.
Используйте Веб-токены JSON (JWT) и претендует на личность, а не случайные токены, требующие отслеживания выпущенных токенов.
JWT похож на паспорт, выданный доверенным органом. Паспорт подписан / проштампован, и вы можете убедиться, что он был выдан этим доверенным органом и не был подделан. Это означает, что целостность утверждения о праве доступа, представленного в токене, может быть проверена без сохранения состояния где-либо. Единственная коммуникация, которая должна произойти между доверяющим приложением и центром, - это начальная (безопасная) загрузка открытого ключа органа (используется для подписи токенов).
Также рекомендуется использовать стандартную схему утверждений, например OpenID Connect (http://openid.net/specs/openid-connect-core-1_0.html#StandardClaims).
Хорошую книгу по этой теме, которая очень помогла мне разобраться во всех этих концепциях, можно найти здесь: Руководство по идентификации и контролю доступа на основе утверждений.
Если вы используете create, sendback, save в localStorage и все, что касается токена JWT, как правильные, вы должны знать, что в .Net есть много способов, которыми вы можете управлять по запросу.
Управление на стороне сервера:
Если вы используете Web API Core, в ядре вы можете создать Middleware, который работает как конвейер во время выполнения, и вы можете указать контекст и проверить запрошенный токен для дополнительной проверки информации: Этот.
Если вы используете Asp.net MVC, вы можете использовать ActionFilter в MVC (Asp.Net-Core также имеет более продвинутый ActionFilter), который проходит каждый запрос, и вы можете проверить каждый запрос thisng abount, для получения дополнительной информации проверьте: Этот.
ClientSide Conftolling:
localstorage, чтобы ваш браузер проверял их по запросу, эти данные, их преимущество - это Expireation и все подобные проблемы в token, сохраните в localstorage, и вы и браузер можете использовать это для получения дополнительной информации проверьте: Этот.Удачи.
Что касается №2, вы также можете использовать промежуточное ПО с использованием OWIN.
Не используйте локальное хранилище для токенов аутентификации, это небезопасно. Лучше использовать куки. owasp.org/index.php/HTML5_Security_Cheat_Sheet#Local_Storage