Overcoming Firebase SSO Challenges

Despite these advantages, Firebase doesn’t provide complete functionality of identity provider and Single Sign On (SSO) integration. Clients seeking to take leverage all cloud advantages can face challenges with integration.

According to official documentation, Firebase allows users to leverage OAuth 2.0 and OIDC, but it is only possibility to connect different authentication providers to Firebase Authentication to use firebase services like Cloud Firestore, Cloud Storage, etc.

Case Study

A client wanted to build a custom SSO solution and had already chosen Firebase, based on Google’s promise to rollout SSO support in the future. The client did not want migration to any other SSO provider like Auth0 or Identity Server, or to deal with user-password migration and potential related issues. They preferred instead to use a temporary, custom solution that would store user’s passwords in Firebase Authentication.

The client had several customer portals based on WordPress Customer Relationship Management (CRM) and an existing list of users in Firebase Authentication. Each time users visited a new portal, credentials were required, and again when users followed a link from one portal to another. It was not always obvious for users that the same credentials should be used for different portals.

By default, Firebase keeps authentication context for one domain but doesn’t provide seamless SSO integration between different domains. To provide this functionality, SoftServe determined that a new Firebase service should be implemented.

The following snapshot of Firebase default functionality helps to understand why a new solution was required:

Resource Server: Hosts the protected resource or data.

Client or User: The client requests access to the resources/data stored in Resource Server.

Authorization Server: Authorizes the client to access the resources.

Step 1: User tries to access service through client web application.

Step 2: User provides own credentials.

Step 3: Authorization server generates access token and returns user, session cookie, firebase, and google tokens.

Step 4: Frontend application requests protected data from resource server with token.

Users were required to go through this authentication process for each new domain. To identify the scope of work and understand areas that required customization, desired functionality needed to be clarified.

Scope of work

This was based on most important client use cases:

1. Users should have some kind of portal where they can manage their resources (via REST) according to their roles.
2. User can authenticate and authorize to the portal by leveraging their local accounts or social identities.
3. Without re-authentication users can access other recourses (in this particular case WordPress sites).
4. This SSO solution should support service accounts so that websites or portal can authorize and access resources on their own behalf.

After reviewing use cases, SoftServe used OIDC for authentication and authorization requirements. This was built on top of OAuth 2.0 and supports several authorization flows:

1. Implicit grant flow
2. Authorization code grant flow
3. On-behalf-of flow
4. Client credentials grant flow

To introduce OpenID support for WordPress, the OpenID Connector plugin was used. This plugin allows user authentication against OpenID Connect OAuth2 API with authorization code grant flow. With this grant type, user's credentials on the resource server are never shared with application.

To prepare the solution, several components in the previous diagram were addressed:

Login application: simple React application providing user interface for authorization. Unauthorized user from WordPress user interface will be redirected to this standalone application to provide own credentials. Login application was hosted on firebase hosting as a separate project.

Apigee platform: was chosen as orchestrator for HTTP endpoints and authorization service. It has built in support for OAuth 2.0 and detailed documentation. This enables the possibility of building custom endpoints needed for OAuth 2.0 support, including:

• oath/authorize to redirect unauthorized users to login application
• oath/token for users to post authorization code obtained after successful login and gain the access token
• oath/verifyToken the resource server uses to validate the user’s token

Authorization code and token can be generated directly by Apigee services so there is no need for any custom development. Everything can be accomplished with Apigee API proxies.

The following diagram illustrates our final solution:

1. User accesses service through client web application
2. Frontend redirects unauthorized user to Apigee “oaut/authorize” endpoint and Apigee as HTTP orchestrator redirect user to Login application
3. User enters own credentials
4. Receives user Id and roles
5. User data is sent to Apigee
6. Based on this data Apigee generates authorization code and returns it to frontend
7. Frontend gets authorization token “oauth/token” and provides authorization code to Apigee
8. Apigee generates authorization token
9. Resource server verifies user’s token “oath/verifyToken”
10. -15. When authorized users attempt to access second frontend, user interaction is not required because login application has active user session and token is given to access other resource server.

This solution is flexible enough to be extended and provide an SSO solution for any custom application—even if a custom application doesn’t have its own mechanism to validate token on resource server side, like library or plugin.

To handle this, firebase functions combined with Admin SDK could be configured to validate user’s roles and permissions. Apigee may expose HTTP endpoint to trigger this function and verify token, doing simple REST call.

As a result, login application based on React JS was deployed on Firebase hosting. Authorization and orchestration HTTP endpoints rely on Apigee platform for current solution.

Summary

Our team delivered a cloud-ready solution, meeting the client’s requirements and expectations. As a result, client got SSO solution and seamless integration with their partners without user migration to third party identity provider. All was completed in three weeks. The client was impressed how quickly and efficiently such a complex problem was solved.

Google promises to introduce official SSO support for Firebase soon. Until then, our solution provides our client with needed functionality, with minimal efforts for development, while delivering all cloud benefits and maximum control without third party products.