I want to secure my Spring RESTful backend. One way (the right?) is to use OAuth 2.0 like shown here:
http://www.youtube.com/watch?v=8uBcpsIEz2I
Within my architecture the resource server and authorization server ARE NOT the same entity. I really just provide some JSON REST services. No UI. If I read the OAuth2 RFC they just say:
The interaction between the authorization server and resource server is beyond the scope of this specification. The authorization server may be the same server as the resource server or a separate entity. A single authorization server may issue access tokens accepted by multiple resource servers.
I found a good diagram on cloudfoundry.com (related to the above youtube video) which I'm using to illustrate my view:
"token" provider: This could/should be google or facebook for example.
RESTful backend: This is actually my code. Spring RESTful services like:
@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);
}
}
(This is just some sample code)
Now my question: Is it somehow possible to validate the access tokens which are generated by the AuthServer (Facebook, Google)? I know that I need to have a "token to user" mapping (database) somewhere on my ResourceServer. Basically I'd like to design my RESTful API like to one from PayPal:
https://developer.paypal.com/webapps/developer/docs/integration/direct/make-your-first-call/
But how can I handle the steps 1 & 2 if I want to use Facebook or Google as auth providers? Is this even possible?
Additional thought: Probably I need to provide my own /oauth2/token
endpoint and then delegate to the underlying AuthProvider.
A resource server validates such a token by making a call to the authorisation server's introspection endpoint. The token encodes the entire authorisation in itself and is cryptographically protected against tampering. JSON Web Token (JWT) has become the defacto standard for self-contained tokens.
In OAuth 2.0, the following three parties are involved: The user, who possesses data that is accessed through the API and wants to allow the application to access it. The application, which is to access the data through the API on the user's behalf. The API, which controls and enables access to the user's data.
Not sure how to answer all the questions with a nice bow, so I'll just put the following points out there:
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With