it-swarm.com.ru

Как создать токен аутентификации с помощью Java

На моей службе Java EE6, REST, я хочу использовать токены аутентификации для входа с мобильных устройств. Пользователь отправит свое имя пользователя, пароль, а сервер отправит обратно токен, который будет использоваться для авторизации пользователя в дальнейшем. запросы на данное время.

Могу ли я просто создать токен сам, как это? (Я думаю, мне не нужно шифровать это, так как я буду использовать HTTPS.)

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

Или есть более стандартный способ создания моих токенов? может быть, он существует в одном из API 

20
Spring

Эффективная схема, которую вы предлагаете, предоставляет клиенту неограниченный доступ к вашим услугам. После первоначального входа в систему клиенту будут доступны UID и «идентификатор пользователя», которые могут быть просто объединены с всегда действительной отметкой времени.

Если вам нужен сервис с логином и токеном сеанса, то почему бы просто не использовать HttpSession?

9
ireddick

Для создания трудно угадываемого токена в Java используйте Java.security.SecureRandom

Например.

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

Вместо того, чтобы включать имя пользователя в токен, было бы лучше кэшировать карту пользователя: карту токена в памяти или в базе данных .

14
Daniel de Zwaan
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);
}

}

Взято и значительно сжато из https://stackoverflow.com/a/41156/584947

1
anon58192932

REST основан на HTTP и рекомендует использовать базовый протокол, а не изобретать велосипед. HTTP использует куки для поддержки взаимодействий с состоянием, таких как запоминание аутентификации, а также поддерживает аутентификацию по имени пользователя и паролю.

Кроме того, Java EE поддерживает все это из коробки. Проверьте учебник

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

0
artbristol

Существует способ создания токенов, который не может быть скомпрометирован, но может также использоваться для аутентификации. 

Создайте токен, который будет объединен:

base64 (имя пользователя + срок действия + другие значения для клиента + закодированные 3des (имя пользователя, срок действия, исходный IP-адрес, идентификатор браузера, другие значения для клиента))

Клиент может использовать токен для аутентификации запроса, например, использование веб-токена JSON (RFC 7515).

На стороне сервера ключи, которые используются для кодирования 3des, могут вращаться со временем, как токен. Каждый запрос содержит токен для аутентификации, и каждый ответ содержит один и тот же токен или новый до истечения срока действия.

В этом случае токен содержит имя пользователя, поэтому при проверке подлинности по запросу необходимо только проверить, является ли кодированная часть 3des действительной или нет (так же, как и источник запроса ip такой же. В этом случае, если кто-то украл токен, удобство использования токена более ограничено идентификатором сеанса. Вы можете составить другие идентификаторы для токена, например, браузер и т. д. Сложнее подделать запрос, потому что злоумышленник должен подделать больше вещей - что ему неизвестно, потому что он не знает, что находится в закодированной части токен. (На самом деле нет идеальной безопасности, только может усложнить взлом)

Плюсы этого решения:

  • Каждая часть является стандартной, но не все вместе, и злоумышленник должен знать детали реализации, чтобы иметь возможность атаковать. 
  • Клиентская сторона может использовать части токена для отображения информации из токена, в то время как сам токен защищен, потому что каждая незашифрованная часть содержится в зашифрованной части - поэтому не может быть изменена без аннулирования токена на стороне сервера - поэтому его легко обнаружить атака.
  • Для кластеризации нет необходимости репликации сессий/липких сессий. Ключей 3des достаточно для репликации между узлами, поэтому он подходит для серверной стратегии без сохранения состояния.

Минусы

  • Сложнее реализовать на стороне сервера, поскольку для этого решения необходимо реализовать алгоритм генерации/проверки токенов на стороне сервера. Для этого рекомендуется использовать фильтр сервера.

  • Клиенты должны реализовать хранилище токенов - вместо того, чтобы рекомендовать хранилище сессий браузера cookie - проще украсть куки.

  • Необходимо убедиться, что ключи 3des достаточно защищены - рекомендуется использовать безопасность Java, чтобы избежать компромисса.
0
Csákány Róbert