web-dev-qa-db-fra.com

Demander un nouveau jeton d'accès à l'aide du jeton d'actualisation dans l'attribution du nom d'utilisateur et du mot de passe dans Spring Security OAuth2

Nous utilisons l'attribution de nom d'utilisateur et de mot de passe pour obtenir un jeton d'accès de notre serveur d'authentification. Nous voulons actualiser le jeton d'accès avant son expiration à l'aide du jeton d'actualisation fourni jusqu'à ce que l'utilisateur se déconnecte ou ferme l'application cliente.

Cependant, je ne trouve aucun exemple de la façon d'émettre cette demande de jeton d'actualisation.

Pour obtenir le jeton, nous appelons quelque chose comme:

curl -v --data "grant_type=password&username=user&password=pass&client_id=my_client" http://localhost:8080/oauth/token

Donc, pour me rafraîchir, je m'attends à ce que l'appel ressemble à ceci:

curl -v --data "grant_type=refresh_token&access_token=THE_ACCESS_TOKEN&refresh_token=THE_REFRESH_TOKEN" http://localhost:8080/oauth/token

ou peut-être

curl -v -H "Authorization: Bearer THE_ACCESS_TOKEN" --data "grant_type=refresh_token&refresh_token=THE_REFRESH_TOKEN" http://localhost:8080/oauth/token

Mais ça me donnera juste un 401 ..

Oh oui, je dois peut-être ajouter le clientId? Je ne peux pas utiliser le secret client, car il n'y en a pas (voir la demande ci-dessus pour obtenir le token). L'authentification se fait en utilisant le nom d'utilisateur et le mot de passe après tout.

Je pense que nous avons la bonne configuration du serveur, donc je ne la posterai pas ici. Si l'une de mes demandes d'exemple doit fonctionner et que vous avez besoin de voir les parties importantes de la configuration, je les ajouterai.

Merci!

springspring-securityoauth-2.0access-tokenspring-security-oauth2
21
Pete

Donc, comme je l'ai dit, nous n'utilisons pas de secret client, car nous ne pouvons pas le laisser traîner dans l'application client Javascript. Et ce n'est pas nécessaire de toute façon, lors de l'utilisation de la subvention nom d'utilisateur-mot de passe. (Voir la façon dont nous demandons le jeton d'accès). En effet, j'étais proche de la solution et j'ai finalement compris:

curl -v --data "grant_type=refresh_token&client_id=THE_CLIENT_ID&refresh_token=THE_REFRESH_TOKEN" http://localhost:8080/oauth/token

donc pas besoin de jeton d'accès ou de secret client.

Dans l'ensemble, il se sent assez en sécurité.

  • Nous ne stockons aucun secret du côté de l'application client.
  • Les utilisateurs ont toujours besoin d'un mot de passe pour se connecter et ne peuvent voir que leurs ressources.
  • Nous limitons la validité du jeton d'actualisation à une heure réaliste comme une journée de travail ou quelque chose de sorte que même s'il est compromis, la fenêtre pour un attaquant est limitée tout en permettant à l'utilisateur de rester connecté au serveur de ressources pendant une longue session.
35
Pete

Pour le mot de passe grant_type, un clientId et clientSecret sont requis. Vous étiez proche de votre troisième tentative, mais vous transmettez le clientId et le clientSecret encodés en Base64 au lieu du jeton d'accès dans l'en-tête d'autorisation. Il s'agit de la demande de jeton d'actualisation appropriée:

curl -H "Authorization: Bearer [base64encode(clientId:clientSecret)]" "https://yourdomain.com/oauth/token?grant_type=refresh_token&refresh_token=[yourRefreshToken]"

Pour une bonne référence, consultez ceci: http://techblog.hybris.com/2012/06/11/oauth2-resource-owner-password-flow/

9
MattSenter