Firebase Authentication with a custom Dart Server

 



This post describes my experiments using Firebase Authentication with a Dart Server application (for example, a shelf based web app). The scenario is that you have a client application (a Flutter Web app, for example) that you want to authenticate using Firebase, but the backend is your own custom web application instead of hosted Firebase services.

Firebase Authentication is essentially free, and offers social login with all the usual suspects  in addition to username/password and phone number authentication. Why roll your own IAM when you can get it for free?

There are examples of this hybrid scenario for other languages where there is a Firebase admin SDK, but I couldn't find detailed notes on how to do this using Dart on the backend.

Before we get to the solution (which turns out to be fairly simple), a quick detour into some of the workings of Firebase AuthN.

Once Firebase successfully authenticates your client, it issues it an JWT Identity Token (idtoken).

To play around with this, I started off by forking the example Flutter Fire Authentication Sample application. I modified the application slightly to dump the idtoken for inspection. Once you authenticate with firebase, cut and paste the idtoken into https://jwt.io. You will see something like:


You will see "invalid signature" on this jwt. We can resolve that by fetching the JWK for the Firebase Authentication provider. This wasn't totally obvious, but the JWK can be fetched from:

https://www.googleapis.com/service_accounts/v1/jwk/securetoken@system.gserviceaccount.com

Grab the Json object with the Key Id (kid) that matches the kid found in the idtoken header. Paste that into the jwt.io "Verify Signature" box, and you will find the signature is now verified. In other words, the idtoken was issued and signed by Firebase.

How do we do this with our Dart server application? Thanks to the nifty openid_client  package, this turns out to be surprisingly easy. This package features built in support for the Firebase Authentication provider. Here is an example with comments:

To recap the general idea:

  • Your client application is configured to use Firebase authentication.
  • Once the Firebase authenticates the user, your client sends the issued idtoken to your Dart server (note: You need to be aware of CORS concerns here).
  • Your server uses the openid_client package to validate the token passed by the client. If the token checks out, you can assume the user has a valid session with firebase. The claims can be used in your application to identify the user. For example, the firebase user_id uniquely identifies the user, and can be used as a primary key in your database.

Comments

Post a Comment

Popular posts from this blog

Introducing ds-operator, the ForgeRock Directory Services Operator for Kubernetes

Image
ForgeRock Directory Services 7.0 was a big achievement for the Grenoble Directory team.  It is the only "Kubernetes native" directory where you can add a new replica using kubectl: kubectl scale sts/ds-idrepo --replicas=3 The 7.0 deployment is assembled using standard Kubernetes primitives such as StatefulSets , Persistent Volume Claims, and Services.  This is all built and orchestrated using Skaffold and Kustomize .  An emerging pattern in the Kubernetes world is the use of Custom Resources and Operators .  Broadly speaking, a custom resource is the declaration of the desired system state, and the operator's job is to observe the current state and bring the system into alignment with the declared state: source: https://blog.container-solutions.com/kubernetes-operators-explained The Kubernetes API server (the thing that responds to your kubectl commands) can be extended to handle new custom types.  A custom resource definition (CRD) describes to the API se...
Read more

OAM R2 REST APIs for Policy Management

Image
Oracle Access Manager 11g R2 provides several new REST APIs. This continues a trend to expose key functionality via Web Services. The OAM Mobile and Social service provides APIs for Authentication, Authorization  and User Profile services.  I will cover those APIs in a future article (have a look here for examples) - but today I want to focus on the  policy management APIs. The Policy Administration API  enables to you to interact with OAM to create a variety of Policy objects such as Application Domains, Resources, AuthN Schemes, and AuthN/AuthZ policies. The policy model is shown below: For example, if you want to retrieve all of the resources in an Application Domain you can perform a GET against the /resource URI: curl -u USER:PASSWORD http://<SERVER>:<PORT>/oam/services/rest/11.1.2.0.0/ssa/policyadmin/resource?appdomain="IAM Suite" Note: The port above is where the OAM Admin Server is deployed (often 7001). It ...
Read more

Automating OpenDJ backups on Kubernetes

Image
Kubernetes   StatefulSets  are designed to run "pet" like services such as databases.   ForgeRock's OpenDJ LDAP server is an excellent fit for StatefulSets as it requires stable network identity and persistent storage. The ForgeOps project contains a Kubernetes Helm chart to deploy DJ to a Kubernetes cluster. Using a StatefulSet, the cluster will auto-provision persistent storage for our pod. We configure OpenDJ to place its backend database on this storage volume. This gives us persistence that survives container restarts, or even restarts of the cluster. As long as we don't delete the underlying persistent volume, our data is safe. Persistent storage is quite reliable, but we typically want additional offline backups. The high level approach to accomplish this is as follows: Configure the OpenDJ container to support scheduled backups to a volume. Configure a Kubernetes volume to store the backups. Create a sidecar container that archives the backups...
Read more