Service API Patterns, Protocols, Coupling Types, Metrics > Service API Proxy and Gateway Patterns > Brokered Authentication

 

Brokered Authentication

How can service consumer credentials be efficiently verified when the consumer is not trusted or if the consumer requires access to multiple services?

Requiring individual services to authenticate individual service consumers can be impractical or even impossible when the services and consumers do not already trust each other or when the service consumers need to access multiple services as part of the same runtime activity.

With the application of the Brokered Authentication pattern, an authentication broker is added as an architectural extension capable of validating consumer credentials without the need for consumers to have direct relationships with the services they need to access. Both consumers and services trust the authentication broker, allowing it to become a centralized authentication and credential issuing mechanism within the overall solution architecture. This platform can simplify the development of individual services and can further reduce the governance burden associated with identity management.

This pattern is generally applied by the deployment of an authentication broker product or platform. The internal architectures of these products can vary in how they carry out the broker functions.

 

 

 

 

 

 

 

 

 

The service consumer submits a request with credentials to the authentication broker (1), which the broker authenticates against a central identity store (2). The broker then responds with a token (3) that the service consumer can use to access Services A, B and C (4), none of which require their own identity store. Note that in this figure, the login credentials are represented by a large lock symbol and the token is represented by a small lock symbol.