Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Spring Cloud OAuth2: Resource server with multiple Authorization server

We are developing an application in a microservice architecture, which implements signle sign-on using Spring Cloud OAuth2 on multiple OAuth2 providers like Google and Facebook. We are also developing our own authorization server, and will be integrated on next release.

Now, on our microservices, which are resource servers, I would like to know how to handle multiple token-info-uri or user-info-uri to multiple authorization servers (e.g. for Facebook or Google).

like image 330
Warren Nocos Avatar asked Nov 16 '16 08:11

Warren Nocos


People also ask

Can authorization server and resource server be the same?

The server that hosts the protected resources. It can use access tokens to accept and respond to protected resource requests. The resource server might be the same server as the authorization server. A grant that represents the resource owner authorization to access its protected resources.

What is resource server in OAuth2?

In the context of OAuth 2.0, a resource server is an application that protects resources via OAuth tokens. These tokens are issued by an authorization server, typically to a client application. The job of the resource server is to validate the token before serving a resource to the client.

How does resource server validates a given JWT token does it need to go to auth server each time a token comes?

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.

What is spring boot starter OAuth2 resource server?

Updated on 17 June, 2022 in Spring Security. Resource Server in OAuth2 is used to protect access to resources, APIs. It will validate the access token passed by the Client Application, with the Authorization Server to decide if the Client Application has access to the resources and APIs it wants.


1 Answers

This type of situation is generally solved by having a middle-man; a single entity that your resource servers trust and that can be used to normalize any possible differences that surface from the fact that users may authenticate with distinct providers. This is sometimes referred to as a federation provider.

Auth0 is a good example on this kind of implementation. Disclosure: I'm an Auth0 engineer.

Auth0 sits between your app and the identity provider that authenticates your users. Through this level of abstraction, Auth0 keeps your app isolated from any changes to and idiosyncrasies of each provider's implementation.

(emphasis is mine)

It's not that your resource servers can't technically trust more than one authorization server, it's just that moving that logic out of the individual resource servers into a central location will make it more manageable and decoupled.

Also have in mind that authentication and authorization are different things although we are used to seeing them together. If you're going to implement your own authorization server, you should make that the central point that can:

  • handle multiple types of authentication providers
  • provide a normalized view of the user profile to downstream resource servers
  • provide the access tokens that can be used by your client application to make authorized requests to your microservices
like image 145
João Angelo Avatar answered Sep 22 '22 08:09

João Angelo