Проверить токен доступа OAuth 2.0 с сервера ресурсов Spring RESTful

Я хочу защитить бэкэнд Spring RESTful. Один из способов (справа?) - использовать OAuth 2.0, как показано здесь:

http://www.youtube.com/watch?v=8uBcpsIEz2I

В моей архитектуре сервер ресурсов и сервер авторизации НЕ НЕ тот же объект. Я действительно предоставляю некоторые услуги JSON REST. Нет пользовательского интерфейса. Если я прочитаю OAuth2 RFC, они просто скажут:

Взаимодействие между сервером авторизации и сервером ресурсов выходит за рамки этой спецификации. Сервер авторизации может быть тем же сервером, что и сервер ресурсов или отдельный объект. Один сервер авторизации может выдавать токены доступа, принятые нескольких серверов ресурсов.

Я нашел хорошую диаграмму на cloudfoundry.com (связанную с вышеупомянутым видео с YouTube), которую я использую, чтобы проиллюстрировать мой взгляд:

"токен": это может быть/должно быть google или facebook, например.

RESTful backend: Это действительно мой код. Spring Услуги RESTful, такие как:

@Controller
@RequestMapping("/api/v1")
public class MyResourceToProtect {

    @Autowired
    private MyService service;

    @RequestMapping(value = "/resource/delete/{name}",
                    method = RequestMethod.DELETE,
                    consumes = MediaType.APPLICATION_JSON_VALUE,
                    headers = "Content-Type=application/json")
    @ResponseStatus(HttpStatus.OK)
    public void delete(@PathVariable("name") String name) {
        service.delete(name);
    }
}

(Это всего лишь пример кода)

Теперь мой вопрос: можно ли как-то проверить токены доступа, которые генерируются AuthServer (Facebook, Google)? Я знаю, что мне нужно иметь сопоставление (база данных) "токена для пользователя" где-то на моем ResourceServer. В принципе, я хотел бы создать свой RESTful API как один из PayPal:

https://developer.paypal.com/webapps/developer/docs/integration/direct/make-your-first-call/

Но как я могу обрабатывать шаги 1 и 2, если я хочу использовать Facebook или Google в качестве аут-провайдеров? Возможно ли это?

Дополнительная мысль: Вероятно, мне нужно предоставить свою собственную конечную точку /oauth2/token, а затем делегировать основной AuthProvider.

Ответ 1

Не уверен, как ответить на все вопросы с хорошим поклонником, поэтому я просто поставлю следующие моменты:

Вы пытаетесь просто использовать API, защищенный OAuth, как Facebook, в режиме OAuth? Используйте Spring Социальный.
Если вы пытаетесь создать свой СОБСТВЕННЫЙ API REST и использовать свой контекст пользователя OWN, используйте Spring Security OAuth. В этом случае вам потребуются клиенты для аутентификации с использованием OAuth против вашего API, а не Facebook или LinkedIn и т.д.
Spring Social Security (в серии 1.2.x) поддерживает "подписание" пользователя в результате соединения OAuth (например, "signin with facebook", "twitter", "..linkedin", и т.д., и ваше приложение в конечном итоге заканчивается с Spring ответственным за безопасность в сеансе, так же, как если бы вы использовали форму HTTP для подписи пользователя вручную.
Spring Безопасность OAuth не волнует, откуда у вас есть Spring Security. Это просто волнует, если у принципала есть правильные роли/области действия, необходимые клиенту Spring Security OAuth. Таким образом, нет причин, по которым вы не могли бы использовать Spring Social для безопасного подключения к Facebook, используйте Spring Social Security, чтобы это соединение создало объект проверки подлинности Spring, а затем используйте Spring Security OAuth, чтобы затем защитить любой доступ к YOUR API, который, в свою очередь, может безопасно подключаться к API Facebook за кулисами. Клиенты будут использовать токен доступа OAuth для ВАШЕГО API, а не Facebook. Это обрабатывается службой.