Federated Identity Provider

When building SaaS or mobile applications, the developer wants to provide end users with the ability to log in using identity providers of their own choice. This is motivated by the fact that those users use on daily basis multiple applications provided and hosted by different organizations while at the same time they become more and more carefool about who and how they share their data with. From a business perspective, it is essential to enable the use of diverse sources of credentials. Otherwise, a potential customer may abandon our application. External identity policy makes it very easy to manage users and their access to services and simplifies many processes.  

Additionally, using popular identity providers is just convenient. The User doesn’t have to fill another boring registration form, confirm an email address and finally remember a password. This is a serious problem when the number of applications we use is constantly growing. Forcing users to provide dedicated credentials can lead to a very bad security practice which is a shared password. Leaking such password from one application means compromising all the others where this password was used. This problem can be eliminated by using password manager, but it isn’t popular. The key is to make our system flexible for this as well.  

The Federated Identity Pattern pioneered by Paul Madsen in 2005 comes to our rescue. It assumes an authentication mechanism separated from application resources and services delegated to multiple trusted identity providers, at the same time minimizing administration costs and facilitating their support. 

Authentication must be separated from authorization. The first is isolated in a dedicated service called an Identity Provider (Idp), and the second is delegated to endpoint resource servers. Any authentication method/service can serve as idp. It can be an active directory, large business providers (eg. Google, Facebook, Github), on-premises federation services, other security token services (STS), custom implementations, etc. Selected providers are federated by our system. A dedicated Federated Identity Provider unifies their support for applications and resource servers.  

The federated authentication process can be done in two ways depending on the requirement of how flexible the login process is to be.  

1. User authenticates with an identity provider that he trusts.
2. The IdP returns the provider token by response or a callback redirection. 
3. The provider token is sent to FIdP.
4. The FIdP cannot trust that the input is generated by the declared provider. The token is validating in the trusted IdP and the Idp is asking for basic information if the provider doesn’t deliver them with the response.
5. The IdP returns validation result and basic data. If the validation is negative the flow is aborted. 
6. FIdP generates own access token and sent it back to client app. 
7. The client asks resource server about resources. 
8. If the user has access to the resource, the server sent back the data 

This way is characterized by very high flexibility. It is both a disadvantage and an advantage. The client application itself must implement the UI responsible for provider-side authentication. This is an additional effort, but may be necessary for the UI/UX. For SPA apps this approach is not essential, but certainly mobile and desktop app designers should consider this solution. Its major drawback is the requirement to re-validate tokens coming into the API. Unfortunately, the token cannot be trusted. Just because a token is signed does not mean that the author of the signature is a trusted identity provider. This implies additional implementation overhead.  

1. The client application redirects the user to a login page issued by FIdP
2. User authenticates with one of the trusted identity providers.
3. The IdP returns the provider token by response or a callback redirection.
4. FIdP generates own access token and redirects the user back to the client application with the token.
5. The client asks resource server about resources.
6. If the user has access to the resource, the server sent back the data

This method is characterized by simplicity and ease of use. The client application must redirect the user to the FIdP page and handle the callback. It is easiest to use this for web-based clients because most of the modern browsers support this approach by default. In other scenarios it requires some additional implementation effort but still is quite easy to achieve.

The result of allowing multiple trusted identity providers is that developer needs to unify the authorization data that is placed in our own token. Otherwise, each resource server that will serve our token will have to worry about the authorization data of each trusted identity provider separately. This would be very inconvenient. For this reason, Federated IdP becomes the source of roles and claims within our system. 

Any federated IdP can become part of another federated IdP by being recognized as a trusted identity provider. This allows us to nest these solutions and use ready-made federated solutions, so that the responsibility for handling trusted providers can be delegated to another service or company. In this case, all that is left on the application side is the implementation of the unification of authorization data and how to request it. 

Federated Identity Pattern is used to support multiple identity providers in a single system. It is a very convenient pattern for both user and developers. It solves the problem of supporting multiple identity providers in a single system. It responds very well to the requirements of modern applications and user habits.