J'ai deux applications
Ont planifié l'authentification comme suit
MAINTENANT, SUR LE CÔTÉ SERVEUR DE L'APPLICATION CLEINT, JE DOIS VALIDER QUE LE JETON VIENT AVEC CHAQUE DEMANDE IS NON TEMPÉRÉ.
Jusqu'à présent, j'ai écrit ci-dessous du code juste pour créer un POC.
========================= Configuration 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);
}
}
Veuillez aider,
Merci,
@Paul
Veuillez me suggérer comment valider le jeton dans chaque demande car je ne connais pas la clé que l'OWIN a utilisée pour générer le jeton.
Votre configuration actuelle, si vous avez ajouté la app.UseOAuthBearerAuthentication()
au pipeline owin, authentifiera l'utilisateur à partir du jeton du porteur qui sera transmis à chaque demande pour vous. L'utilisateur actuel peut alors être trouvé via HttpContext.Current.User
.
Utilisez l'attribut Authorize
pour décider ensuite quels utilisateurs sont autorisés sur certains points de terminaison. Voici un exemple où les utilisateurs avec le rôle "utilisateur" sont autorisés à accéder
[Authorize(Roles="user")]
public class ValuesController : ApiController
{
}
Il est juste d'écrire du code pour valider le jeton sur l'application cliente ou il devrait être sur le serveur d'authentification.
NON , vous ne validez pas le jeton dans le client, si vos informations d'identification d'utilisateur sont erronées, vous n'obtiendrez pas de jeton du tout. C'est tout ce que vous devez savoir. Et aussi, pourquoi devriez-vous vouloir valider le jeton dans le client?
Je prévois de déplacer tout le code de gestion des utilisateurs comme enregistrer l'utilisateur, changer le mot de passe en serveur d'authentification afin que nous puissions le réutiliser pour différentes applications clientes - est-ce une bonne pratique de conception?
La réutilisation d'un fournisseur de jetons est courante. Pourquoi inventer la roue pour chaque application? Créez-en un, ou utilisez un tiers, et réutilisez-le dans toutes vos applications.
Utilisez JSON Web Tokens (JWT) et identités de revendications , pas des jetons aléatoires qui nécessitent de garder une trace des jetons émis.
Un JWT est comme un passeport délivré par une autorité de confiance. Le passeport est signé/tamponné et vous pouvez vérifier qu'il a été délivré par cette autorité de confiance et qu'il n'a pas été falsifié. Cela signifie que l'intégrité de la revendication de droit d'accès présente dans le jeton peut être vérifiée sans garder l'état n'importe où. La seule communication qui doit se produire entre l'application de confiance et l'autorité est un téléchargement initial (sécurisé) de la clé publique de l'autorité (utilisée pour signer les jetons).
Il est également conseillé d'utiliser un schéma de revendications standard, comme OpenID Connect ( http://openid.net/specs/openid-connect-core-1_0.html#StandardClaims )
Un bon livre sur le sujet, qui m'a beaucoup aidé à comprendre tous ces concepts, peut être trouvé ici: n guide pour l'identité basée sur les revendications et le contrôle d'accès .
Une façon de vérifier qu'un jeton n'a pas été falsifié est de le signer à l'aide d'une paire de clés asymétriques, Identity Server utilise cette approche comme indiqué ici .
Dans votre cas, si vous lancez votre propre authentification, vous devrez l'implémenter vous-même et vérifier sur chaque demande, probablement dans un middleware personnalisé, que le jeton est valide.
Si vous create
, sendback
, save
dans localStorage
et tout ce qui concerne JWT
Token comme correct, vous devez savoir de nombreuses façons sont dans .Net
que vous pouvez contrôler par demande.
Contrôle côté serveur:
Si vous utilisez Web API Core
, dans le noyau, vous pouvez créer Middleware
qui s'exécute en tant que pipline au moment de l'exécution, et vous pouvez donner le contexte et vérifier le jeton qui a demandé, pour plus d'informations: This .
Si vous utilisez Asp.net MVC
, vous pouvez utiliser ActionFilter
dans MVC (Asp.Net-Core a également plus avancé ActionFilter), que chaque demande passe par et vous pouvez vérifier chaque demande d'abondance thisng, pour plus d'informations, vérifiez: Ce .
Contrôle client côté client:
localstorage
que votre navigateur vérifie par demande de données, ils sont les Expireation
et tout comme ce problème dans token
enregistrez dans localstorage
et vous et le navigateur pouvez l'utiliser pour plus d'informations: This .Bonne chance.