So erstellen Sie ein Authentifizierungstoken mit Java

Um ein schwer zu erratendes Token in Java zu erstellen, verwenden Sie Java.security.SecureRandom

Z.B.

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

Anstatt den Benutzernamen in das Token aufzunehmen, ist es besser, einen Benutzer zwischenzuspeichern: Token-Map im Arbeitsspeicher oder in einer Datenbank .

Für Java 8 und höher wäre die schnellste und einfachste Lösung:

private static final SecureRandom secureRandom = new SecureRandom(); //threadsafe
private static final Base64.Encoder base64Encoder = Base64.getUrlEncoder(); //threadsafe

public static String generateNewToken() {
    byte[] randomBytes = new byte[24];
    secureRandom.nextBytes(randomBytes);
    return base64Encoder.encodeToString(randomBytes);
}

Ausgabebeispiel:

wrYl_zl_8dLXaZul7GcfpqmDqr7jEnli
7or_zct_ETxJnOa4ddaEzftNXbuvNSB-
CkZss7TdsTVHRHfqBMq_HqQUxBGCTgWj
8loHzi27gJTO1xTqTd9SkJGYP8rYlNQn

Der obige Code generiert eine zufällige Zeichenfolge in Base64-Codierung mit 32 Zeichen. Bei der Base64-Codierung codiert jedes Zeichen 6 Bits der Daten. Für 24 Bytes aus dem obigen Beispiel erhalten Sie also die 32 Zeichen. Sie können die Länge der Ausgabezeichenfolge ändern, indem Sie die Anzahl der zufälligen Bytes ändern. Diese Lösung ist sicherer als UUID (das nur 16 zufällige Bytes verwendet) und generiert eine Zeichenfolge, die sicher in HTTP-URLs verwendet werden kann.

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

}

Genommen und deutlich verdichtet von https://stackoverflow.com/a/41156/584947

REST basiert auf HTTP und empfiehlt, das zugrunde liegende Protokoll zu verwenden, anstatt das Rad neu zu erfinden. HTTP verwendet Cookies, um zustandsbehaftete Interaktionen wie die Erinnerung an die Authentifizierung zu unterstützen, und unterstützt auch die Authentifizierung mit Benutzernamen und Kennwort.

Darüber hinaus unterstützt Java EE all dies aus der Box. Überprüfen Sie das Tutorial

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

Es gibt eine Möglichkeit, Token zu erstellen, die nicht gefährdet ist, aber auch zur Authentifizierung verwendet werden kann. 

Erstellen Sie ein Token, das kombiniert wird:

base64 (Benutzername + Ablaufdatum + andere Werte für Client + 3Des-kodiert (Benutzername, Ablaufdatum, Quell-IP, Browser-ID, andere Werte für Client))

Der Client kann das Token verwenden, um die Anforderung zu authentifizieren, beispielsweise die Verwendung des JSON-Web Token (RFC 7515).

Serverseitig können die Schlüssel, die für die 3Des-Codierung verwendet werden, mit der Zeit als Token gedreht werden. Jede Anforderung enthält ein Token zur Authentifizierung, und jede Antwort enthält das gleiche oder ein neues Token vor Ablauf.

In diesem Fall enthält das Token einen Benutzernamen, sodass bei der Anforderungsauthentifizierung nur geprüft werden muss, ob der 3Des-codierte Teil gültig ist oder nicht (die Quelle der Anforderungs-IP ist identisch mit der Quelle der Anforderungs-IP. Wenn in diesem Fall jemand das Token gestohlen hat, ist die Verwendbarkeit des Token größer.) Als Sitzungs-ID beschränkt. Sie können andere Bezeichner zu Token zusammenstellen, wie Browser usw. Schwieriger zu fälschender Anforderung, weil der Angreifer weitere Dinge fälschen muss - was für ihn unbekannt ist, weil er nicht weiß, was sich auf einem verschlüsselten Teil von befindet Token. (Tatsächlich gibt es keine vollkommene Sicherheit, die nur schwieriger zu knacken ist)

Die Vorteile dieser Lösung sind:

• Jedes Stück ist Standard, aber nicht das Ganze zusammen, und der Angreifer muss die Implementierungsdetails kennen, um angreifen zu können. 
• Die Clientseite kann Teile des Tokens für die Anzeige von Informationen aus dem Token verwenden, während das Token selbst gesichert ist, da jeder unverschlüsselte Teil in einem verschlüsselten Teil enthalten ist. Er kann daher nicht geändert werden, ohne dass das Token auf der Serverseite ungültig ist Attacke.
• Für das Clustering sind keine Sitzungsreplikations-/Sticky-Sitzungen erforderlich. Die 3des-Schlüssel sind ausreichend, um zwischen Knoten zu replizieren. Daher eignet sie sich für die statuslose Backend-Strategie.

Die Nachteile sind

• Auf der Serverseite schwieriger zu implementieren, da für diese Lösung der Algorithmus zur Generierung/Validierung von Token auf der Serverseite implementiert werden muss. Für diesen Server wird ein Filter empfohlen.

• Die Kunden müssen den Token-Store implementieren - anstelle des Cookies wird der Browser-Session-Store empfohlen - es ist einfacher, Cookies zu stehlen.

• Stellen Sie sicher, dass die 3des-Schlüssel ausreichend gesichert sind. Es wird Java-Sicherheit empfohlen, um den Kompromiss zu vermeiden.