Most people would prefer to login via an existing service they use – for example, google, facebook, twitter etc. – rather than sign up for a new service. And often new potential users will not choose your service precisely because they don’t want to bother with the hassle of registering and keeping track of one more account, since you don’t offer an authentication option they currently use.
Of course, if you have a truly unique service – something that none of your competitors provide – then you’re likely to be okay. But most apps have competitors, and providing third-party authentication login options might mean the difference between customers choosing to make use of your service or another service.
The upshot is that you should always provide login options via federated companies like Google and Facebook. However, as an independent developer, or a developer on a small team, there are many options related to the implementation of third-party authentication.
We can divide the potential options into three broad categories (1) build from scratch (2) use an authentication library / framework, (3) use an authentication service.
(1) certainly offers the most flexibility and freedom with respect to design and implementation at every stage of the authentication flow, but it’s probably not a feasible option for a lone developer or a small team – as they say, there’s no need to re-invent the wheel.
(2) Can be a good choice. There are a number of authentication libraries (e.g., passport for Express, Devise for Rails) that are built to flexibly incorporate new login ‘strategies’. For example, you could build a strategy that makes use of the Facebook login API so that users can authenticate and sign up for your application via the OAuth protocol. If your application uses only one or two strategies, then this may be a solid choice. However, the more strategies incorporated into your application, the greater the time needed for both setup and maintenance.
After all, sometimes authentication and authorization APIs change, or become deprecated for certain services like Facebook login. This means you may very well have to go back and make changes to the strategy that dealt with that API.
(3), authentication as a service, delegates or outsources the bulk of authentication and authorization code to a third-party. Firebase Authentication is a popular option in this category. Firebase will provide secure login via password / username, popular federated providers (facebook, google, twitter etc), or by phone number / email. Firebase Authentication also handles password retrieval via email and phone text.
To make use of Firebase Authentication in a full-stack application requires implementing a javascript Firebase UI component, which handles all of the business logic associated with the user logging in. The user will receive a firebase key. This key needs to go in the headers of any requests to your backend the user’s actions generate. On the backend, the token can be decoded either by (1) using Firebase’s sdk for your language, or (in case your backend isn’t supported), (2) make use of one of the many jwt libraries to extract the relevant information.
Firebase may be the best choice for small teams and independent developers because it allows them to focus on development the meat of their application, rather than dealing with the hassle of authentication.
However, there are potential dangers associated with using full-featured services like this. If the service shuts down or changes it’s feature-set in an undesirable way, you will have no control over it, and may have to go back to the drawing board and adopt a different authentication solution.
Oldest comments (0)