Comment créer un jeton d'authentification à l'aide de Java

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

Par exemple

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 jeton, il serait préférable de mettre en cache un utilisateur:jeton de carte à mémoire ou dans une base de données.  

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 prendre en charge les interactions avec état, comme la mémorisation de l'authentification, et prend également en charge l'authentification par nom d'utilisateur et mot de passe.

De plus, Java EE prend en charge tout cela prêt à l'emploi. Consultez le tutoriel

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

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);
}

}

Pris et considérablement condensé à partir de https://stackoverflow.com/a/41156/584947

Il existe un moyen de créer des jetons qui ne peuvent pas être compromis mais peuvent également être utilisés pour l'authentification.

Créer un jeton qui est combiné:

Base64 (nom d'utilisateur + expiration + autres valeurs pour le client + 3des codé(usename, expiration, source ip, identificateur de navigateur, autres valeurs pour le client))

Le client peut utiliser le jeton pour authentifier la demande, par exemple l'utilisation du jeton Web JSON (RFC 7515).

Côté serveur, les clés utilisées pour 3des encodage peut être tourné 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 jeton contient le nom d'utilisateur, donc sur l'authentification de la demande, il suffit de vérifier que la partie codée 3des est valide ou non (identique à la, la source de l'IP de la demande est la même. Dans ce cas, si quelqu'un a volé le jeton, la facilité d'utilisation du jeton est plus limitée en tant qu'identifiant de session. Vous pouvez composer d'autres identifiants pour jeton, comme navigateur, etc. Plus difficile de simuler une demande, car l'attaquant doit simuler plus de choses - ce qui lui est inconnu, car il ne sait pas ce qui se trouve sur la partie codée du jeton. (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 le tout ensemble et l'attaquant doit connaître les détails de l'implémentation pour pouvoir attaquer.
• Le côté client peut utiliser des pièces du jeton pour afficher les informations du jeton alors que le jeton lui - même est sécurisé car chaque partie non cryptée est contenue dans une partie cryptée - ne peut donc pas être modifiée sans l'invalidation du jeton côté serveur-il est donc facile de détecter une attaque.
• Il n'y a pas besoin de réplication de session / sessions collantes pour le clustering. Les clés 3des sont suffisantes pour se répliquer entre les nœuds - il convient donc à une stratégie backend sans état.

Les inconvénients sont

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

• Les clients doivent mettre en œuvre le magasin de jetons - au lieu de cookie browser session store est recommandé - plus facile à volé des cookies.

• Doivent s'assurer que les clés 3des sont suffisamment sécurisées-La sécurité Java est recommandée pour éviter le comprimise.