Управление сеансами: Как создать токен аутентификации для службы REST? (Джерси) - PullRequest
Новая
       5

Управление сеансами: Как создать токен аутентификации для службы REST? (Джерси)

43 голосов
/ 11 февраля 2011

Я пытаюсь реализовать управление сеансами в моей службе REST.Я познакомился с этими правилами во время серфинга:

  1. Не использовать сеансы на стороне сервера - это нарушает принцип RESTful.

  2. Использование базовой аутентификации HTTP -Сейчас это невозможно, поскольку меня просят не использовать SSL / TLS (что, без сомнения, необходимо для базовой аутентификации).

  3. Использование дайджеста Http - я слышал, что это увеличивает сетевой трафик.Это звучит дорого, особенно когда мой клиент - мобильное устройство.

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

  5. У меня есть возможность генерировать токен аутентификации, который пользователь должен отправлять каждый раз, а я не признаю, что это "полностью "ОТДЫХ.

Теперь мне нужно знать, как мне генерировать эти уникальные токены аутентификации, которые достаточно безопасны на бизнес-уровне?Есть ли библиотека для Джерси?Должен ли я пойти на OAuth .. Я только что прочитал немного о них, они полезны в моем случае?Помните, что мои целевые клиенты - это мобильные устройства - могут ли они получить доступ к службе OAuth ??

1 Ответ

38 голосов
/ 11 февраля 2011

Для простоты я генерирую свой собственный токен аутентификации, используя UUID, прежде чем шифровать весь токен с помощью Jasypt : - 

String key = UUID.randomUUID().toString().toUpperCase() +
        "|" + someImportantProjectToken +
        "|" + userName +
        "|" + creationDateTime;

StandardPBEStringEncryptor jasypt = new StandardPBEStringEncryptor();

...

// this is the authentication token user will send in order to use the web service
String authenticationToken = jasypt.encrypt(key);

Ключ содержит creationDateTime, чтобы я мог использовать его для проверки времени жизни. Таким образом, если пользователь использует тот же токен аутентификации через X минут, он больше не будет работать, и я отправлю обратно запрещенный код 403.

...