Comment créer un token d'authentification en utilisant Java

sur mon Java EE6, REST service, je veux utiliser des tokens d'authentification pour me connecter à partir d'appareils mobiles, L'utilisateur enverra son nom d'utilisateur, son mot de passe et le serveur renverra un token, qui sera utilisé pour autoriser l'utilisateur sur leurs demandes ultérieures pour un temps donné.

puis-je simplement créer un token moi-même comme ceci?(Je suppose que je n'ai pas besoin de chiffrer cela, car je vais utiliser le protocole HTTPS.)

String token = UUID.randomUUID().toString().toUpperCase() 
            + "|" + "userid" + "|"
            + cal.getTimeInMillis();

ou il y a un moyen plus simple de créer mes jetons? peut-être qu'il existe dans l'une des API est

19
demandé sur Spring 2012-12-21 19:38:57

5 réponses

Le schéma que vous proposez permet effectivement à un client un accès illimité à votre service. Après une connexion initiale, L'UID et l'userid seront mis à disposition du client, qui peut être simplement combiné avec un horodatage toujours valide.

si vous avez besoin d'un service avec 'login' et un token de session, alors pourquoi ne pas simplement utiliser une HttpSession?

7
répondu ireddick 2012-12-21 20:34:08

pour créer un jeton difficile à deviner en Java, utilisez java.security.SecureRandom

E. g.

SecureRandom random = new SecureRandom();
byte bytes[] = new byte[20];
random.nextBytes(bytes);
String token = bytes.toString();

plutôt que d'inclure le nom d'utilisateur dans le token, il serait préférable de mettre en cache une carte utilisateur:token en mémoire ou dans une base de données.  

12
répondu Daniel de Zwaan 2017-04-10 00:08:06

REST est basé sur HTTP, et encourage l'utilisation du protocole sous-jacent plutôt que de réinventer la roue. HTTP utilise des cookies pour supporter les interactions stateful comme la mémorisation de l'authentification, et prend également en charge l'authentification du nom d'utilisateur et du mot de passe.

en outre, Java EE supporte tout cela hors de la boîte. Vérifier le tutoriel

http://docs.oracle.com/javaee/6/tutorial/doc/bncas.html

1
répondu artbristol 2012-12-30 14:02:40 
public class SecureTokenGenerator {
public static final String CHARACTERS = "abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789";

// 2048 bit keys should be secure until 2030 - https://web.archive.org/web/20170417095741/https://www.emc.com/emc-plus/rsa-labs/historical/twirl-and-rsa-key-size.htm
public static final int SECURE_TOKEN_LENGTH = 256;

private static final SecureRandom random = new SecureRandom();

private static final char[] symbols = CHARACTERS.toCharArray();

private static final char[] buf = new char[SECURE_TOKEN_LENGTH];

/**
 * Generate the next secure random token in the series.
 */
public static String nextToken() {
    for (int idx = 0; idx < buf.length; ++idx)
        buf[idx] = symbols[random.nextInt(symbols.length)];
    return new String(buf);
}

}

extrait et condensé de façon significative de https://stackoverflow.com/a/41156/584947

1
répondu anon58192932 2018-01-16 16:18:41

il y a un moyen de créer des tokens qui ne peuvent pas être compromis mais qui peuvent aussi être utilisés pour l'authentification.

Créer un jeton qui est combinée:

base64(nom d'utilisateur + d'expiration + d'autres valeurs pour le client + 3des codé(un nom, la date de péremption, source de l'adresse ip, le navigateur identitifier, d'autres valeurs pour le client))

le client peut utiliser le jeton pour authentifier la requête, par exemple l'utilisation du JSON Web Token (RFC 7515).

Sur le serveur côté les touches qui sont utilisées pour encoder 3des peuvent être tournées avec le temps, comme le jeton. Chaque requête contient un jeton d'authentification et de chaque réponse contient le même ou un nouveau avant l'expiration.

dans ce cas , le token contient le nom d'utilisateur.l'authentification sur demande n'a donc qu'à vérifier que la partie encodée par 3des est valide ou non (même chose que la, la source de la requête ip est la même). Dans ce cas, si quelqu'un a volé le token, l'utilisabilité du token est plus limitée en tant que session. ID. Vous pouvez composer d'autres identificateurs de jeton, comme navigateur, etc. Plus difficile de simuler une requête, parce que l'attaquant doit simuler plus de choses - ce qui est inconnu pour lui, parce qu'il ne sait pas ce qui est sur une partie codée de token. (En fait, il n'y a pas de sécurité parfaite, seulement peut rendre plus difficile à craquer)

les avantages de cette solution sont:

  • chaque pièce est standard, mais pas l'ensemble ensemble et l'attaquant doit connaître les détails de mise en œuvre pour pouvoir attaquer.
  • le côté client peut utiliser des parties du token pour afficher des informations à partir du token alors que le token lui - même est sécurisé parce que chaque partie non chiffrée est contenue dans une partie chiffrée - donc ne peut pas être modifié sans l'invalidation du token du côté serveur-donc il est facile de détecter une attaque.
  • il n'y a pas besoin de réplication de session / sessions collantes pour le clustering. Les touches 3des sont suffisantes pour se répliquer entre les noeuds - il est donc approprié pour stateless backend stratégie.

Les inconvénients sont

  • plus difficile à implémenter du côté du serveur, car pour cette solution, il est recommandé d'implémenter l'algorithme de génération / validation des tokens du côté du serveur pour ce filtre du serveur.

  • les clients doivent mettre en place le stockage de tokens - au lieu de cookie browser session store est recommandé - plus facile à voler les cookies.

  • doivent s'assurer que les 3des les clés sont suffisamment sécurisées-il est recommandé d'utiliser Java security pour éviter la compression.
0
répondu Csákány Róbert 2017-02-05 10:31:13