2017-05-09 1 views
0

J'utilise IdentityServer pour contrôler l'accès à une API. J'ai une API d'authentification distincte qui émet les jetons et valide les demandes d'accès pour sécuriser les API.Identity Server Refresh Token Propriétaire de la ressource Mot de passe Credential Flow

Je donne aux utilisateurs la possibilité de générer un jeton d'accès via une application Web sécurisée. J'utilise le flux d'informations d'identification du mot de passe du propriétaire de la ressource.

Y a-t-il un moyen de délivrer un jeton d'actualisation sans que l'utilisateur doive se connecter et le demander? Ou est-il possible de définir l'expiration du jeton d'accès initial?

code

C'est le code que je utilise pour générer des jetons.

DiscoveryResponse disco = await DiscoveryClient.GetAsync("http://localhost:27144"); 
    TokenClient tokenClient = new TokenClient(disco.TokenEndpoint, "My Client", "MySecret"); 
    TokenResponse tokenResponse = await tokenClient.RequestResourceOwnerPasswordAsync("testUser", "testPassword"); 
+0

Pouvez-vous s'il vous plaît fournir plus d'informations? Si vous définissez 'AllowOfflineAccess = True', IdentityServer renvoie automatiquement un' refresh_token'. Vous pouvez également définir 'AccessTokenLifetime' ... – moritzg

+0

@moritzg J'ai défini l'indicateur allowOfflineAccess sur true et défini la valeur absoluteRefreshTokenLifetime sur 31540000, ce qui devrait être une année. Toutefois, l'objet de réponse de jeton renvoie 3600 pour la propriété expiresIn. Je peux voir qu'un refresh_token est retourné aussi. Est-ce que je le passe dans l'en-tête d'autorisation? –

+0

De quel jeton voulez-vous dire par "objet de réponse token"? – moritzg

Répondre

1

Oui, cela peut être accompli avec des jetons d'actualisation.

  • Set AllowOfflineAccess = true sur la configuration client
  • Inclure offline_access dans le cadre de la demande de jeton initiale

La réponse symbolique comprendra désormais un RefreshToken en plus du AccessToken. Retournez le AccessToken au client et maintenez le sur le RefreshToken.

Lorsqu'un nouveau AccessToken est requis, demandez-en un en utilisant la méthode RequestRefreshTokenAsync sur TokenClient. Le nom est confus - vous demandez en fait un nouveau AccessToken FROM RefreshToken.

TokenResponse refreshTokenResponse = await tokenClient.RequestRefreshTokenAsync("RefreshTokenGoesHere"); 

Il existe deux façons de gérer l'expiration de RefreshToken. Ceci est contrôlé par la propriété RefreshTokenExpiration:

  • expiration Sliding
  • expiration absolue

Si l'expiration de glissement est réglé, la durée de vie de jeton de rafraîchissement renouvellera après chaque rafraîchissement.

Il existe également une propriété RefreshTokenUsage, qui détermine si un jeton peut être réutilisé ou à usage unique. S'il est défini sur une seule utilisation avec une expiration glissante, vous obtiendrez simplement un nouveau RefreshToken à conserver pour chaque requête. Pour la temporisation d'expiration, il existe SlidingRefreshTokenLifetime et AbsoluteRefreshTokenLifetime. Les deux peuvent être utilisés simulatenousely. Par exemple, si les jetons d'actualisation glissants étaient activés, l'expiration du glissement pourrait être de 30 jours alors que l'expiration absolue pourrait être de 1 an. Cela permettrait à l'utilisateur 30 jours d'inactivité avant de devoir se connecter à nouveau, mais si l'utilisateur reste actif, 1 an d'utilisation sans connexion.

Il est important de noter que dans tous les cas, l'élément RefreshToken ne doit jamais être renvoyé à l'utilisateur. Seul le jeton d'accès doit l'être. Vous aurez besoin d'un mécanisme de stockage de données pour conserver les jetons d'actualisation et leurs dates d'expiration.

+0

#Kevin Gysberg comment pouvons-nous passer offline_access avec apiname dans la portée –