Shop Alto Essentials to add pharmacy products to any delivery!

Your partner in navigating the ins and outs of prescriptions — at no extra cost.

Alto Pharmacy Technician

Alto Pharmacist

It’s official: Alto Pharmacy is a great place to work! We’re honored to join the community of Great Place to Work-Certified™ companies based on team member feedback and a rigorous assessment of our company’s culture and benefits.

Join us in delivering our industry-leading pharmacy care to millions of people across the country. As a member of the team, you’ll play an integral role in improving our customers’ quality of life and redefining what’s possible in pharmacy. 

Be Part of a Great Place to Work — Join Our Team

Hear first-hand from members of the Alto technology teams.

Read the latest Alto blog posts covering healthcare, family health, managing diseases, and other Alto highlights.

Blog | Alto Pharmacy

We’re excited to share that Alicia Boler Davis will be Alto’s next CEO. She will start on September 1, 2022. This is a big moment for Alto, so we wanted to share how we got here.

Introducing Alto’s New CEO - Alicia Boler Davis

We’re excited to share that Alicia Boler Davis will be Alto’s next CEO. She will start on September 1, 2022.

This is a big moment for Alto, so we wanted to share how we got here.

Alto has come a long way since we started out in 2015 by acquiring AG Pharmacy in San Francisco. Those first few months revealed just how much opportunity there was to build a better pharmacy experience for patients by rebuilding the entire end-to-end technology stack, combining it with a more efficient operational process, and backing it all with a talented and caring team. And with that insight we started forging ahead with bright eyes and relentless optimism toward our ultimate mission: fulfill medicine’s true purpose - to improve quality of life - for everyone who needs it.

Like any transformational startup, the journey has not been without its challenges. We’ve been consistently humbled by the complexity of the pharmacy industry and the challenges inherent in transforming how it works. Yet we’ve also been consistently amazed by how much opportunity there really is to make a meaningful difference in the lives of patients, and how receptive people are to a better solution. And through persistence and grit, combined with an increasingly talented and diverse team, we have overcome all the challenges that we have faced so far. We have served over 300,000 patients, with a 90 Net Promoter Score, are unit profitable, and are expected to pass $1 billion in annualized revenue in the next few months. We’re making faster progress than at any point in the company’s history. 

So if things are going so well, why are we hiring a new CEO? The opportunity ahead of us is huge, and along with that the challenges are getting more complex. Despite how far we’ve come, we are still only 0.2% of the total pharmacy industry market share. Capturing this massive opportunity will require leveling up our already world-class team with an even greater level of bold, rigorous, caring, experienced leadership.

As we got to know Alicia over the past few months, we realized that we had found the perfect partner to lead us through the next phase of Alto’s growth. Alicia was most recently the SVP of Global Customer Fulfillment at Amazon, and before that the EVP of Global Manufacturing at General Motors. Alicia grew up in Detroit, and got her first job as an engineering intern at GM. Over the next 25 years she worked her way up to running a plant, then running multiple plants, then running all of quality and customer experience, and finally running all of global manufacturing. She was the first Black woman to accomplish each of these things at GM. In 2019 she joined Amazon, and was quickly promoted to the prestigious S-team, which is the exclusive inner circle of the most senior leaders at Amazon. When she was barely a year into the job, the Covid-19 pandemic hit, and over the next two years she oversaw Amazon nearly doubling its fulfillment network capacity to keep up with surging demand, while managing a team of over 800,000 people. Alicia built a reputation for successfully navigating the toughest challenges while driving unparalleled growth by bringing out the best in her teams.

From the day we started, we have always tried to build a team that is balanced between the rigor and operational excellence needed to execute in this complex industry, along with the heart and care that we saw was missing from the industry. These are not mutually exclusive attributes, but they are extremely rare to find in the same person. In Alicia, more than any other leader we’ve ever met at her level, we’ve found someone who can bring that balance that we seek. She is one of the world’s top executives in operations, and is a rigorous, disciplined operator. And at the same time, she leads with real heart and care for the people that she serves and that she works with.

With Alicia coming on board as CEO, Matt and I will continue to be involved full-time, both in supporting Alicia and with our own portfolios of projects to lead. We’re more committed than ever to Alto, and more excited than ever about the real opportunity we have in front of us. And we are so early in this journey that it is clear there is no shortage of work to do and problems to solve. Matt and I have never been attached to any particular role or title, and have each worn many different hats over the years. We are humble about what we are good at and what we are not, and just want to do what is best for our team in order to achieve our mission. In the short term we will focus on ramping Alicia up, and after that we will work more on what we do best: building our long term strategy, leveraging our entrepreneurial spirit to spin up new business lines, defining and evolving our culture, and sharing the Alto vision.

We are just getting started, and there is still so much opportunity to fix this broken industry, and truly help people live happier and healthier lives. We can’t wait to see what we will do together in this next phase of the Alto journey.

We are honored to announce that for the second year in a row, Alto Pharmacy has been recognized by Forbes as one of America’s Best Startup Employers. This award celebrates our commitment to employer reputation, employee satisfaction and growth.

Alto Pharmacy Announced as One of Forbes Best Startup Employers for the Second Consecutive Year!

When Alto’s founders set out to transform the pharmacy experience, they outlined a vision whereby our work could improve the quality of life for everyone who needs medicine. Through this foundation grounded in helping people, we have built a company culture centered in care, inclusion, and impact. 

We are honored to announce that for the second year in a row, Alto Pharmacy has been recognized by Forbes as one of America’s Best Startup Employers. This award celebrates our commitment to employer reputation, employee satisfaction and growth. 

This recognition follows Alto Pharmacy's recent admission as a Great Place to Work-Certified™ company – awarded based on employee feedback and a rigorous assessment of Alto’s culture and benefits. Given the impact we strive to make on the communities we serve, we are humbled to share this most recent recognition alongside other accolades over the past year, including: 

The Healthcare Technology Report: Top 100 Healthcare Technology Companies of 2021 

The Healthcare Technology Report: Top 25 Consumer HealthTech Executives of 2021

The Healthcare Technology Report: Top 25 Women Leaders in Consumer HealthTech of 2021

These recognitions and achievements are only made possible through the hard work and dedication of the entire Alto team. If you are passionate about shaping the future of pharmacy, join us as we deliver our industry-leading pharmacy care to millions of people across the country.

For the full employers list and an overview of the selection methodology, head to the Forbes site.

Each type of user has a different product or set of products we’ve built for them. From within each product, we collect, transmit, process, and store a tremendous amount of sensitive information. However, our biggest area of security, privacy, and compliance risk is our internal pharmacy management tool called Wunderbar that is used by our operations (ops) users every day to process prescriptions. Securing access to Wunderbar is mission-critical to protect our data and our business, and, of course, we need our super-secure implementation to be super-smooth to avoid slowing down our hard-working ops users.

Developing Robust Authentication Using Rails, Omniauth, and Okta

Alto Pharmacy aims to deliver a better pharmacy experience for everyone who needs medication. To achieve that, we need to enable three different types of users:

Individual customers who need prescriptions

Healthcare providers: the nurses, doctors, physicians assistants, and other medical professionals who prescribe medications

Operations users: the Altoids who intake prescriptions, bill insurance, fill prescriptions, and more

We wanted to be able to change our Wunderbar session lifetimes without hampering either our security efforts or the usability of our product. Moreover, we wanted session lifetimes of other apps to be able to change appropriately with business risk. Before starting this project, we’d implemented a Google OAuth 2.0 authorization flow that allowed ops users to log into Wunderbar via Google and take advantage of transparent session refresh for a limited amount of time.

However, while Google Workspaces was (and is) great for our email, documents, and calendars, it isn’t as configurable or extensible as a proper SSO solution. One painful side effect of this limitation was that, in order to ensure our refresh sessions were limited to twelve hours in Wunderbar, any user of the Alto Gmail drive also had to log back in every twelve hours just to see email — even though there’s not nearly the same level of sensitive data in email.

Plus, our IT team had already picked the tool of the future: Okta. And the goal was to enable SSO, or Single Sign On: if we still used Google for SSO, it wouldn’t really be SSO!

It was clear we needed to move to Okta for authenticating in Wunderbar, too.

Okta is a big company with many different authentication mechanisms. For us, the big question was really: do we want to authenticate via SAML or Open ID Connect (OIDC)? There are a lot of great resources around comparing these two standards and what they’re good at; here’s a good chart comparing and contrasting parts of these two authentication flows:

From this Medium post, which is a great primer on the differences

For us, the most attractive thing about SAML is that it can be used to provision user accounts from your upstream IDP; for example, Okta could be configured to push username, email, group, role, etc., information to our platforms with which we could automatically provision user accounts.

In the end, we decided the OIDC implementation would provide for a very similar user experience to that which our operations users were already accustomed to, with the same capability to perform transparent token refresh.

This transition was pretty easy because we were moving from Google OAuth 2.0 flow to Okta’s OIDC flow. OAuth 2.0 and OIDC are very similar; just know that OAuth 2.0 is technically an authorization framework (once you have a user, what can they access) vs an authentication framework (actually identifying and validating the user). However, there were some odd things about our previous implementation, and I only had one person to blame for those choices: myself. It’s great to get the opportunity to re-implement our authentication system — in a fast moving startup, you rarely get the chance to revisit problems so soon!

The biggest issue at hand with our previous Google flow was the way in which I’d chosen to re-authenticate users whose Wunderbar sessions had expired. In this case, OAuth provides a handy mechanism: a refresh token. Here’s how access tokens and refresh tokens are exchanged from the client and the authentication server in OAuth 2.0 flows:

At the time, we had session lifetimes of 60 minutes when accessing Wunderbar. These cookies also lasted 60 minutes. We faced a problem: if somebody walked away from their laptop for 61 minutes after authenticating, when they came back, how could we make it so they didn’t have to go back through the Google OAuth 2.0-initiated login flow from the beginning?

My solution at the time persisted a secure cookie with the refresh token value client-side with a longer expiration length. Then, if the user didn’t have a valid access token, we’d simply present the refresh token back to the server and get a new access token all over again. This worked well, but exposing secrets to the client always presents a risk of compromise. Refresh tokens are longer-lived, so they're of even higher value to protect!

Okta’s documentation made it very easy to stand up a simple authentication server and set up a local development server. Okta has a great blog post guide with tools we were already using (Rails and Omniauth, specifically) to get up and running. Beyond that, our biggest challenge was ensuring that we had a smooth rollout.

There was an issue in how we’d test and use this flow in our staging environments, however. At the time we were working on this (early 2020), there were two issues:

Our sandbox environment URLs were non-deterministic and could be varied depending upon how an engineer user named their cluster.

Okta apps did not support wildcard redirects in their oauth redirect URLs. This controls where, upon hitting Okta’s servers, they should redirect your payload to handle the meat of authentication.

For a time, our clever infrastructure engineering team managed around these issues with the use of an intermediary keycloak server. However, Okta now supports wildcard redirects that we’re successfully using today:

The biggest functional change to our authentication flow was in our refresh flow. The biggest challenge in landing this change was in how we deployed it to end users in production.

We didn’t want to expose the refresh token because it presented too much risk. What do we do instead? Something a little bit risky, but that we preferred after threat modeling our scenarios. Security engineering is often about making tradeoffs given a number of constraints. Today, our session lifetimes are down to fifteen minutes, and our refresh lifetime for an active session (e.g. somebody making at least one request within this window) is 60 minutes. If somebody comes back after their access token expires, that’s fine; we’ve persisted the encrypted refresh token to the database, and we can use attributes from the expired but still cryptographically valid token in order to look that refresh token up.

This was crucial for Okta especially because Okta refresh tokens are valid for 100 days by default!

Disruptive change is hard. We didn’t want to disrupt the workday of our hard-working ops users who are caring for our many customers and provider partners. The biggest intent here was to keep a safety blanket fallback to the old authentication flow until we were quite confident in its functionality. This broke down into a multi-phase approach:

1. Dark-launch the new Okta flow hidden behind a URL and with a small allow-list of users (mostly just the Security team) assigned to the new application in Okta.

2. Ask for volunteers! These volunteers would go about their normal work day in a variety of functional areas (customer care, pharmacy, fulfillment, engineering) using Okta instead of Google.

3. Change the default login flow to use Okta, but keep Google working just fine as a secondary action hidden behind a URL.

This allowed us to always ensure that we didn’t disrupt peoples’ days too much!

We achieved our goals and now, nearly two years later, we’re successfully using Okta’s OIDC flow within our core pharmacy management app. What did we learn in the process?

Not every API is necessarily fully implemented in every client. At the time of implementation, Okta’s Ruby client wasn’t fully supported. In order to support our refresh flow, we needed to upstream a small change into the client library, which required a little investigation.

Exposing secrets involves risk! In our case there wasn’t a glaring need to expose refresh tokens client-side at all.

Slow rollouts are great, especially with disruptive changes! A big thank-you to our team members who were willing to be part of the experiment group last year when this rolled out.

Interested in learning more about engineering at Alto? Follow us on LinkedIn and check out our open positions.

Last year, we set out to tackle this technical debt by splitting the User model into separate concerns and refactoring the entire system into this new paradigm.

Tackling Technical Debt and Improving Security: How Alto Untangled an Overloaded User Model

At Alto, we have three types of users: customers, healthcare providers (nurses, doctors, etc), and operations users who run the pharmacy. For each type of user, we maintain a separate application (though they share a monolithic backend for now): our customer app; our Alto Connect app for providers; and our internal pharmacy management tool called Wunderbar, which powers the pharmacy experience from prescription intake to fulfillment.

Early on, we made the pragmatic choice to represent both customers and operations users with a single User model, distinguishing them with a “roles” attribute. This required repetitive checks that, over time, slowed down our engineering teams, presented substantial privacy risk, and posed difficult scaling challenges as we evolved our monolith into different microservices. 

The challenges of relying on a single User model for different types of users

The notion of a User is core to our concept of identity from which authentication and authorization proceeds. From a security perspective, it’s difficult to build an extensible and clean authentication and authorization system when you’re overloading one model for two very different populations of users. From a privacy perspective, this muddied customer records (which are subject to more restrictions because they’re healthcare records) with workforce records, hamstringing many analytics efforts.

Authentication: Alto employees who were also Alto customers were required to use their work emails for their customer accounts. Not only was this restriction frustrating for Alto employees, but it also posed a security risk: employees should only be able to access Wunderbar via corporate SSO, not their personal account passwords. 

Authorization: Engineering new authorization capabilities required intricate knowledge of the idiosyncrasies of our user structure. This both slowed down development and created tremendous risk that any mistake could easily escalate user permissions.

Privacy: Because they existed in the same table, both customer records and Alto operations user records were classified as Protected Health Information, or PHI, which severely limited what we were able to do with them.

Attribution: Our robust audit logs were significantly less useful when a user ID in the transaction log might refer to either an ops user or a customer.

State management: Some updates pertaining to admin identity lived on the customer model, some lived on the employee model, and others lived in other various models.

Architecture: Tight coupling would have prevented us from decoupling our monolithic system into smaller services.

Our backend is primarily a monorepo Rails application that shares a tremendous amount of functionality between our customer, provider, and ops user-specific domains. Generally we use JWTs to secure customer and ops user sessions. These JWTs are issued only once valid credentials have been present.

Ops users are required to log in via Okta SSO, enforcing both valid username/password as well as a two-factor authentication (2FA) prompt. We use Devise and Omniauth to wire up the OIDC flow with our upstream identity provider, and we use CanCan to expand a set of roles per-user into a set of capabilities that restrict what resources they can access/modify.

Ops users primarily work in our internal pharmacy management app. However, the state of these users was shared between several different tables: Users, which otherwise refer to customers, and Employees, which share some ops user-specific state tied to Users.

Large change sets of code being deployed at once are harder to code review, harder to unwind if something goes wrong, and are more likely to be more disruptive. For this project, we knew that such a large architectural change had to be broken up into many more-digestible pieces if we were to be successful. The plan:

1. Create a new dedicated model for our ops users

# == Schema Information
#
# Table name: wunderbar_users
#
#  id                        :bigint(8)        not null, primary key
#  user_id                   :bigint(8)        indexed
#  email                     :string           not null, indexed
#  first_name                :string           not null
#  last_name                 :string           not null
#  token_last_invalidated_at :datetime
#  roles_mask                :integer          default(0), not null
#  title                     :string           not null
#  team                      :string           not null, indexed
#  is_active                 :boolean          default(TRUE), not null
#  slack_user_id             :string
#  pod                       :string

This was the easy part: create the database structure for a properly isolated admin user type, which we called a WunderbarUser.

We now had our admin user state split between Employees and Users, with a new table that engineers and analysts wanted to use that was not yet populated, and we had to make progress while allowing new hires and new customers alike to onboard to our platform.

2. Synchronize state between the old tables and new table

Next, we created a WunderbarUser for any User who was, or ever had been, a Wunderbar user. This required some historical digging —we had a lot of people who were onboarded, and even some offboarded, before we even had the intermediate Employee record!

Two major choices at this stage really helped the project succeed. First, we ensured that the WunderbarUser records all had IDs matching the corresponding User records. This is because a lot of our legacy audit records (that we’re required to preserve and keep useful as a Covered Entity under HIPAA) referenced an `admin_user_id` column populated with the ID of the User. If we just created all new entries for WunderbarUsers, these old logs would require at least one level of indirection (e.g. querying back to User) to make useful.

     # Create with the same ID as the user that we're creating this from.
     wunderbar_user_attributes = {
       id: user.id,
       user_id: user.id,
       email: user.email,
       roles_mask: user.roles_mask,
       date_of_birth: user.date_of_birth,
       token_last_invalidated_at: user.token_last_invalidated_at,
       first_name: user.first_name,
       last_name: user.last_name,
       preferred_first_name: user.preferred_first_name,
       is_active: false,
     }

Second, we created a new WunderbarUser any time we created a new Employee record (e.g. when we onboarded a new employee) and synchronized any changes between Users, Employees, and WunderbarUsers tables. As a side note: we knew we’d have to protect this syncing logic to ensure that we only copied each change once — otherwise, our callbacks would fire forever!

3. Migrate functionality slowly to use the new ops user model

We migrated logic to reference WunderbarUsers where previously we’d referenced Users and/or Employees. Authentication, authorization, audit logs, and pharmacist licenses were all updated here — albeit painstakingly!

We then migrated all of the foreign keys our various Postgres database tables held to either the Users or Employees tables to instead reference the WunderbarUsers. This ended up being around a hundred foreign keys, but a constraint-only migration that fortunately didn’t involve any data changes.

In short: our goal was to do this change slowly and steadily enough that nobody would notice until, one day, we could announce to the team, “Hey, we did a big security-pertinent project, and now you can change your customer email to be anything.”

Authentication: While we use the same JWT format for each, our customer and operations user authentication systems are now totally separated.

Authorization: With separate user types, we have separate capabilities and domain-specific authorization checks for each area, enforced in code.

Experience: Onboarding as a new Altoid (somebody who works here; come join us!) is totally separate from the customer experience, and you no longer need to link your accounts together.

Privacy: Our ops users who choose to be customers enjoy the full privacy afforded to our customers without tying their account to their work identity in any way.

Attribution: Legacy audit logs are still index-able and query-able with the same IDs, just in a slightly different table.

State management: Customer state lives on the User table, and ops user state lives on the new WunderbarUsers table. Our callbacks on each have been dramatically pared down, and our intermediary Employee table is entirely gone, along with a number of other now-ancillary tables.

Architecture: We have a clear path to federate RBAC checks without shipping our entire customer database between services.

Bonus: Performance and code readability generally improved by removing complex joins and join tables and isolating concerns between the customer and ops user domains.

Another Bonus: Significant refactorings and increased test coverage along the way while we cleaned up some very old, very stale code.

Large architectural changes of legacy systems with heavy use are rarely 100% smooth. Here are a few learnings to keep in mind the next time you tackle a hefty piece of technical debt. 

1. Always validate your assumptions (e.g. the data your constraints are against) when foreign keys are concerned. Multiple times we assumed, “Hey, we’ve migrated a bunch of really big tables that are really old (insurance claims, prescriptions, and more), so there’s no way we could have another admin user that we haven’t created a commensurate WunderbarUser for, right?” Wrong! Your data can always have inconsistencies, but a simple SQL query (e.g. validate that all values of the column you’re migrating the foreign key to have a matching WunderbarUser) can save a lot of time and headaches.

2. When migrating foreign key constraints on tables with active reads in Postgres, ensure you break it into two steps. Migrate your foreign key with `{ validate: false }`

 def up
   remove_foreign_key :inventory_orders, to_table: :users, column: :created_by_id
   add_foreign_key :inventory_orders, :wunderbar_users, column: :created_by_id, validate: false
 
   validate_constraint
 end

Validate the named constraint of your foreign key separately

 def validate_constraint
   validate_constraint_statement = 'ALTER TABLE "inventory_orders" VALIDATE CONSTRAINT "fk_rails_abcd1234";'
   ActiveRecord::Base.connection.execute(validate_constraint_statement)
 end

3. When working with legacy tables, be mindful of legacy systems. Our Billing service used a very outdated golang ORM that panicked if a column specified by the `struct` in source no longer existed; this caused a late-night outage that made auto billing requests back up the next day.

4. Scoping projects is hard! This was a larger project than our team had ever scoped and delivered before. Once all the dust settled, this project took several months longer than our initial scoping estimates.This project was worth doing, but better estimates allow us to prioritize better. If we’d had a great scope of this immense project upfront, would we have chosen to do it first? Also, this was a tremendously difficult project to separate into material stages; all the benefit was really backloaded.

In the end, this was a very satisfying and important project to complete. We wouldn’t have been able to accomplish it without a lot of help from our colleagues on the Platform team, the Security team, and across many other functions atAlto. Very large projects that involve a lot of moving pieces and impact other teams are always scary — but we can’t let that fear prevent us from making the changes we know we need to do in order to be successful long-term.

The Engineering Team is hiring! Learn more about open positions here.

In our previous post, we discussed how we designed our biometric authentication system with both privacy and a better user experience in mind. In this post, we'll show you exactly how we did it.

Considerations and Approaches for Implementing Biometric Login: Part 2

In Part 1, we discussed how we designed our biometric authentication system with both privacy and a better user experience in mind. In this post, we'll show you exactly how we did it.

To build a new authentication mechanism, we opted to use the react-native-biometrics library. This library interfaces with the device's biometrics, generates a keypair, and stores the private key within the device's keystore. When logging in with biometrics, the library creates a signature using the stored private key, and the signature is then sent to the server for validation. (Note: this library is now unmaintained. At the time of writing, this implementation can instead be accomplished with the following maintained libraries: expo-local-authentication to access device biometrics, keypair to generate a keypair, react-native-keychain to access the device keystore.)

Check if biometrics are supported and configured by the user for this device.

const { available } = await ReactNativeBiometrics.isSensorAvailable();

If yes, prompt the user for a biometric scan.

const { success } = await ReactNativeBiometrics.simplePrompt({ promptMessage: 'Confirm ID' });

If the scan succeeds, generate a keypair. The react-native-biometrics library's createKeys method will automatically save the private key to the device's keystore, and return the public key counterpart. Send the public key to your server.

const { publicKey } = ReactNativeBiometrics.createKeys('Confirm biometrics');

// Save the public key to your database
post('/save_biometric_key', { key: publicKey, device_id: 'xyz' })

When the user tries to login with biometrics, scan their biometrics. This time, if the scan succeeds, create a signature using the stored private key. The react-native-biometrics library's createSignature method handles all of this.

// Prompts for scan
// On scan success, accesses private key and uses it to generate a signature, which is then returned
const signatureResponse = ReactNativeBiometrics.createSignature({
  promptMessage: 'Face or fingerprint ID for Alto Pharmacy',
  payload: BIOMETRIC_SIGNATURE_PAYLOAD,
});

Send the signature to the server to validate against the public key. If validation succeeds, the user has successfully authenticated with biometrics and can proceed into the app.

// Call your server API to validate the signature against the public key that you've stored in the database
const validationSuccess = await post(
  `/validate_biometric_signature`,
  {
    signature: signatureResponse.signature,
    payload: BIOMETRIC_SIGNATURE_PAYLOAD,
		device_id: 'xyz',
  },
);

if (validationSuccess) {
  // Login Success
} else {
  // Login failure
}

import ReactNativeBiometrics from 'react-native-biometrics';

const setUpBiometricLogin = async () => {
  // Check if biometrics are supported and configured on this device
  const { available } = await ReactNativeBiometrics.isSensorAvailable();

  if (available) {
    // Prompt user to scan biometrics
    const { success } = await ReactNativeBiometrics.simplePrompt({ promptMessage: 'Confirm ID' });
      
    if (success) {
      // If scan is successful, generate a keypair, then save the public key to the server
      const { publicKey } = await ReactNativeBiometrics.createKeys('Confirm biometrics');

      post('/save_biometric_key', { key: publicKey, device_id: 'xyz' })
    }
  }
}

const loginWithBiometrics = async () => {
  // Scan user's biometrics. On scan success, generate a signature
  const signatureResponse = await ReactNativeBiometrics.createSignature({
    promptMessage: 'Face or fingerprint ID for Alto Pharmacy',
    payload: BIOMETRIC_SIGNATURE_PAYLOAD,
  });

  // Validate the signature against the public key saved on the server
  const validationSuccess = await post(
    `/validate_biometric_signature`, 
    {
      signature: signatureResponse.signature,
      payload: BIOMETRIC_SIGNATURE_PAYLOAD,
      device_id: 'xyz',
    },
  );

  if (validationSuccess) {
    // Login Success
  } else {
    // Login failure
  }
}

1. build a way to store a public key associated with a device

2. write a method to validate a signature against a public key

3. expose endpoints to save a public key, and validate a signature

Once biometric authentication is built, there are additional decisions to make. The right decisions for your app will depend on your goals; the approach we took here at Alto may not align with what is best for your app.

How should biometric sessions interact with our existing email and password sessions?

We opted to treat email and password sessions as longer-lived primary sessions, with biometrics as a shorter-lived secondary session on top of that primary session. This means that a user must first login with email and password in order to use biometrics on subsequent app opens. If the user logs out for any reason, they will need to log in again with email and password before they can use biometrics again.

How often should we prompt the user for biometrics vs. email and password?

We opted to prompt the user for biometrics far more frequently than email and password, but made this configurable in case we want to adjust.

We use tokens and cookies for session management.

There are plenty of edge cases to consider as you're developing biometric capabilities for your app, including: what should happen when the biometric scan fails, or when the signature validation fails? What should happen if a user disables biometric permissions from their device? What should happen when two users share a device? What should happen if 'risky' activity is flagged for this account? How can we disable biometric login if needed?

Face and fingerprint ID login has clear benefits for both the end-user and the application itself, but it comes with a host of implementation decisions. If you're considering building biometric login for your app, I hope this article gives you clarity on what biometrics is, the different ways you can integrate it into your app, and the tradeoffs and edge cases to consider.

At Alto, the Patients Engineering team worked closely with our Security Engineering and Product teams to align on our goals and build the best solution for our needs. Our Security team offered deep expertise on the authentication strategies to adopt and avoid, and our Product team kept us tethered to building the best experience for our users.

Working as a team is one of the best parts about developing at Alto. If you want to meet the awesome team I'm talking about, come join us - we're hiring!

Face and fingerprint ID login is a convenient, seamless way to gain app access on a mobile device. Instead of typing in a lengthy, hard-to-remember username and password, many apps allow you login with just a quick scan of your face or fingerprint (also known as biometrics).

Considerations and Approaches for Implementing Biometric Login: Part 1

It's a desirable feature for both our end user and the Patients Team here at Alto — we want to make it as easy as possible for users to log in while also performing more frequent authentication checks. Improve the user experience and the security of our app? Sounds like a win-win.

As an engineer, implementing biometric login might seem easy, as mobile devices already capture, manage, and encrypt biometric data and expose APIs for app developers like myself to initiate a biometric scan. All I need to do is call that API and wait to hear if the scan is successful or not. What isn't as simple, though, is figuring out what to actually do with a successful biometric scan response. What does a successful scan mean, and how does that relate to the username and password credentials that users currently use to access our app?

This post walks through the decision points we encountered while implementing biometric login and how our healthcare privacy concerns influenced the final implementation approach.

Prior to implementing biometric login, the only way for users to access the Alto app was with email (username) and password. A valid email and password generates a session, which expires at some frequency. Once the session expires, the user must re-enter their email and password to regain access to the app.

From the beginning, we knew that biometrics would need to be built with our existing email and password session management in mind. This is made clear in the Apple developer docs: "Use biometrics as a supplement to something you’re already doing. Don’t depend on biometrics as your only authentication option."

Make it easier for users to login. Nobody likes typing in an email and password — especially on a mobile app. Our goal was to reduce the number of times a user must enter their email and password.

Enhance the security of our app using more frequent authentication checks. As a healthcare app that displays Personal Health Information (PHI), conducting more frequent authorization checks decreases the likelihood of PHI becoming exposed to an unauthorized third party.

Have the ability to revoke biometric access from a particular user. Similarly, we want to be extra careful to ensure that if a device is lost or stolen, we have a fallback plan to invalidate a user's session and protect the user’s PHI. For email and password initiated sessions, this happens when a user changes their password, as any change in login credentials will invalidate all active sessions for that user. We needed a similar contingency plan for biometric login.

There are several ways to use a mobile device's biometrics to authenticate a user, with varying degrees of security.

No server-side authentication. Simply integrate with the device's biometrics as an extra layer of authentication. If the biometric scan is successful, let the user proceed into the app.

Provides an extra check and gives your app a sense of modern polish

No server-side validation means that nothing is being validated against your system, so this is not a good substitute for account authentication. Therefore, even if you add this check, the user should still be prompted to re-enter their email and password at the same frequency as before.

Given this, this approach wouldn't help us reach our goal of reducing the number of times a user must enter their email and password.

This approach is a good fit if your application already has an existing login and session management system, and you want extra authentication checks throughout the user's session without modifying any other part of the system.

Tie biometrics to our existing email and password authentication. Use the user's biometrics to unlock an encrypted version of their email and password credentials. When a user sets up biometric login, store the user's login credentials within the device's keystore — the keystore will automatically encrypt the credentials. After a successful biometric scan, retrieve those credentials from the keystore and send them to your existing login API.

Still easy to implement, no backend changes needed

Biometric scan can be used in place of entering an email and password

Changing email and password credentials will revoke biometric access: if a user changes their credentials, their biometrics will access stale credentials and fail to login. (This is somewhat of a con as well — it provides a poor user experience, but it's an edge case that should happen infrequently.)

There is still only one way for a user to authenticate server-side, but now two ways to pass server-side authentication — essentially weakening your app's existing account security.

This approach effectively hands out internal login credentials to third party storage. While not a huge risk considering a device's secure storage is encrypted and trusted by most users, it’s not necessarily a best practice either.

This approach is a good fit if your application doesn't contain sensitive data, and your goal is to make it more convenient for a user to login by replacing email and password with a biometric scan.

Create a separate authentication mechanism for biometrics. Introduce a new authentication mechanism specifically for biometrics, resulting in two independent forms of server-side session authentication: email with password and biometrics. The implementation could look like generating a keypair or a shared secret to save and validate against the server whenever a user attempts to login with biometrics.

Biometrics is now tied to its own secure server-side authentication mechanism, which means it can be used independently of email/password (or even replace it, if you choose to).

Two layers of authentication adds security to the app. Not only does a user need a valid email/password session, they also need a valid biometric session.

It provides fine-grain control over a user's biometric session. You can invalidate a user's biometric session by invalidating the public key and can even invalidate a biometric session without impacting an email-and-password session if needed.

Requires building and maintaining a separate authentication mechanism

This approach is a good fit if your application contains sensitive data (e.g. PHI or financial information), and your goals are to make it both more convenient for a user to login by replacing email and password with a biometric scan while also strengthening the security of your account management system.

Because we are a healthcare company dealing with sensitive data, we chose this last path. It required greater engineering investment, but we agreed it was imperative that we maintain a secure system while introducing biometric login for users.

In part 2, we talk implementation details, including the library we used, code snippets, and questions to consider before you get started. Interested in learning more about engineering at Alto? Follow us on LinkedIn.

When engineering incidents happen, typical deployment pipelines are just too slow—especially if customers’ medications are on the line. Here’s the speedier rollback process we use at Alto Pharmacy to ship fixes in 3 minutes, flat.

How Alto Reduced Time to Resolution for Production Incidents

Production incidents caused by newly-merged code happen to us all. When they do, most engineering organizations discuss the root cause and how to prevent similar incidents in the future. At Alto, we evaluate two additional metrics:

Time to detection: How quickly did we know something was wrong?

Time to resolution: How quickly did we restore service?

Time to resolution is especially critical for us as a pharmacy, where a long-running incident could block a user from getting their medication on time.

Over 30 times a day, an engineer at Alto hits the merge button, deploying a new build to production. Our well-automated CI/CD pipeline, built by our Infrastructure team, handles the 3-step deployment process:

1. Build: install Ruby & JavaScript dependencies

The average runtime for our standard deployment pipeline is 30 minutes—reasonable for a CI/CD pipeline, but too long when shipping a fix for a production incident.

We introduced a “hotfix” workflow as a first pass at an expedited deployment pipeline for incident response. A hotfix is a commit that introduces new code to address the incident by either removing or reverting the buggy code that introduced the issue in the first place or by shipping new code that fixes the initial issue. 

The hotfix deployment pipeline reduces incident time to resolution by triggering a specific CI job that removes the test step from our standard pipeline, reducing the workflow to just the Build and Deploy steps.

Implementing a hotfix pipeline on top of our standard pipeline in CircleCI was relatively simple—in our `.circleci/config.yml`, any part of our CI workflow that should be skipped in case of a hotfix runs a job called “early_exit_if_hotfix” that will skip the current step if the last commit message of the code being built includes the keyword “[hotfix]”.

early_exit_if_hotfix:
    steps:
      - run:
          name: Early exit if hotfix
          command: |
            git_commit_message=$(git log --format=%B -n 1)
            if [[ $git_commit_message =~ "Merge pull request #" ]]; then
              echo "This is a merge commit. Checking if this is a hotfix deploy"
              git_commit_sha=$(git log --format=%H -n 1)
              git_commit_message=$(git log --format=%B $git_commit_sha^-)
            fi
            if [[ $git_commit_message =~ "[hotfix]" ]]; then
              echo "exiting early for hotfix deploy"
              circleci-agent step halt
            fi
            echo "not a hotfix deploy, continuing"

run_ruby_tests:
  steps:
early_exit_if_hotfix
run_tests

The hotfix workflow reduces time to ship a resolution, once we identify the fix, from 30 minutes to ~18 minutes. It’s faster than our standard pipeline but still requires considerable hands-on work from the engineer performing the hotfix.

To further speed up deployment and reduce manual work, we introduced a workflow that simply rolls back to a previously-built healthy deployment image. In this workflow, the entire pipeline is reduced to just the Deploy step.

To invoke a rollback, an engineer commits a message with the keyword “[rollback]”, followed by the SHA of the commit to rollback to. Similar to the hotfix approach, any build step that should be skipped during a rollback checks the commit message for the “[rollback]” keyword before running:

early_exit_if_rollback:
    steps:
      - run:
          name: Early exit if rollback
          command: |
            git_commit_message=$(git log --format=%B -n 1)
            if [[ $git_commit_message =~ "Merge pull request #" ]]; then
              echo "This is a merge commit. Checking for rollback sha..."
              git_commit_sha=$(git log --format=%H -n 1)
              git_commit_message=$(git log --format=%B $git_commit_sha^-)
            fi
            if [[ $git_commit_message =~ "[rollback]" ]]; then
              echo "exiting early for rollback deploy"
              circleci-agent step halt
            fi
            echo "not a rollback deploy, continuing"

run_ruby_tests:
  steps:
early_exit_if_hotfix
early_exit_if_rollback
run_tests

The rollback workflow looks for a build matching the specified SHA and posts a confirmation message for the engineer, then deploys that build to production. The rollback approach dropped our time to resolution even further, from 30 minutes to ~3 minutes.

There are three edge cases that we’ve also baked into our rollback workflow: potentially stale images, database migrations, and blocking new merges and deployments.

Our script has a special block warning the engineer if a target image is older than an hour. The older the image, the riskier the rollback, as the delta between the image and the latest commit on main is larger.

time_rollback=$(git show -s --format=%ct ${rollback_revision})
time_now=$(date '+%s')
if [ $(($time_now - $time_rollback)) -gt 3600 ]; then
    message="${message}\n\n:warning:The rollback commit is more than an hour old."
    message="${message}\nThe [hotfix workflow](https://www.notion.so/alto/Deploying-a-Hotfix-Rolling-Forward-bb8e9cea05b44c67a64e23ae652653b6) might be a better candidate for this deployment."
fi

We also want to warn engineers if any database migrations have occurred between the current image and the target by checking the diff of the db/migrate directory. Rolling back application code without applying changes to the database can result in the database and application code becoming out of sync, resulting in further problems. Our script will warn engineers if a migration has been detected between the current and target image and provide instructions on how to rollback migrations if required.

Because a rollback deploys an image that’s older than our latest build, we also need to block continuous deployment until we’ve restored the main branch to a safe state — typically by deploying a hotfix as soon as we can identify an appropriate fix. We accomplish this using a Github issue with a specific tag that, when open, triggers a job causing any active CI job to fail. After the incident is resolved, the incident manager closes the issue, which will retrigger the blocked jobs and resume the normal build and deploy workflow.

The expedited rollback process has reduced our overall time to ship a resolution for incidents down to a speedy 3 minutes—a valuable improvement for our internal operations users, as well as for our customers and healthcare providers who rely on Alto’s service to get prescriptions filled. Branching these incident response workflows off of our existing standard deploy pipeline keeps the maintenance cost low for our infrastructure team, and robust automation reduces the risk of manual error for our product engineers when they need to invoke these workflows.

We’re excited to welcome Ramiah Martin to Alto as Vice President, Operations & Supply Chain. Here’s more on what drew him to Alto and the opportunities he’s most excited about, in his own words. 

Meet Ramiah Martin, VP, Operations & Supply Chain

We’re excited to welcome Ramiah Martin to Alto as Vice President, Operations & Supply Chain. Prior to joining Alto, Ramiah was Senior Director of Operations at Amazon, where he developed the strategic vision for the company’s operations and led a cross-functional team in implementing new processes and technologies to streamline use of resources.

His dedication to continually improving the customer experience is matched by a passion for healthcare change, and we could not be more thrilled to have Ramiah on the team. Here’s more on what drew him to Alto and the opportunities he’s most excited about, in his own words. 

Blog

Introducing Alto’s New CEO - Alicia Boler Davis

Alto Pharmacy Announced as One of Forbes Best Startup Employers for the Second Consecutive Year!

Developing Robust Authentication Using Rails, Omniauth, and Okta

Tackling Technical Debt and Improving Security: How Alto Untangled an Overloaded User Model

Considerations and Approaches for Implementing Biometric Login: Part 2

Considerations and Approaches for Implementing Biometric Login: Part 1

How Alto Reduced Time to Resolution for Production Incidents

Meet Ramiah Martin, VP, Operations & Supply Chain

Celebrating American Pharmacist Month At Alto

Celebrating National Coming Out Day at Alto

Introducing Christopher Tidball, Director of Product Management - Supply Chain & Fulfillment

The Next Evolution of Our Company Values

Switch to a better pharmacy.