Forem: vincenzoiozzo

Passkeys Adoption Trends: Survey from Large Deployments

vincenzoiozzo — Thu, 15 Feb 2024 11:36:32 +0000

Introduction

Sign up for free on SlashID here to start implementing Passkeys in your application.

In our previous articles, we've extensively discussed the security benefits of passkeys—from enhancing protection against account takeovers and phishing to simplifying compliance with regulatory frameworks like PSD2. However, the user experience (UX) aspect has received less attention, raising concerns for businesses considering widespread adoption.

This post synthesizes available data on passkeys deployment, focusing on conversion rates and deployment strategies, along with insights from large-scale implementations.

Who is using passkeys?

Global adoption data for passkeys is still emerging, but an analysis of the top 50 websites by traffic offers a glimpse into their uptake. According to Semrush's December 2023 rankings, 19 of these websites now support passkeys, either as a primary authentication method or as a secondary option for multi-factor authentication (MFA).

Site	Passkeys Primary	Passkeys MFA
Google Search	✓	✓
YouTube	✓	✓
Facebook	✓	✓
Pornhub	✕	✕
XVideos	✕	✕
X (Twitter)	✓	✓
Wikipedia	✕	✕
Instagram	✓	✓
Reddit	✕	✕
Amazon	✓	✓
DuckDuckGo	✕	✕
Yahoo	✓	✓
XNXX	✕	✕
TikTok	✓	✓
Bing	✓	✓
Yahoo JP	✓	✓
The Weather Channel	✕	✕
WhatsApp	✓	✓
Yandex	✕	✕
xHamster	✕	✕
OpenAI	✕	✕
Live	✓	✓
Microsoft	✓	✓
Microsoft Online	✓	✓
LinkedIn	✓	✓
Quora	✕	✕
Twitch	✕	✕
Naver	✕	✕
Netflix	✕	✕
Office	✓	✓
VK	✕	✕
Globo	✕	✕
Aliexpress	✕	✕
CNN	✕	✕
Zoom	✕	✕
IMDb	✕	✕
x.com (Twitter)	✓	✓
New York Times	✕	✕
OnlyFans	✕	✕
ESPN	✕	✕
Amazon.co.jp	✓	✓
Pinterest	✕	✕
Universo Online	✕	✕
eBay	✓	✓
Marca	✕	✕
Canva	✕	✕
Spotify	✕	✕
BBC	✕	✕
PayPal	✕	✕
Apple Inc.	✓	✓

Case studies

Yahoo Japan

Yahoo Japan, a major player with 55 million monthly active users, has seen about 11% of its user base adopt passkeys.

For the cohort of users using passkeys, Yahoo Japan observed the following:

A statistically higher registration rate compared to every other authentication method. In particular the increase was 2.29% on iOS, 8.02% on Mac, 15.35% on Windows and 0.66% on Android
2.6x faster authentication time
25% decrease in customer support/authentication support requests

Mercari

Mercari, Inc. is a Japanese e-commerce company founded in 2013 with approximately 20m monthly active users. As of August 2023 approximately 900,000 users have registered passkeys credentials.

For the cohort of users using passkeys, Mercari observed the following:

82.5% success rate vs 67.7% for SMS OTP
4.4s vs 17s average time to login with passkeys compared to SMS OTP

Kayak

Implementing passkeys helped KAYAK, a leading travel search engine, cut the average login and registration time by 50%. Though specific customer support metrics are not disclosed, Kayak also saw a decrease in customer support/authentication support requests.

Dashlane

Dashlane is a password management tool that provides a secure way to manage user credentials, access control, and authentication across multiple systems and applications. Dashlane has over 18 million users and 20,000 businesses in 180 countries.

Dashlane, with its 18 million users, observed a remarkable 92% conversion rate for Passkey authentication—a 70% improvement over passwords.

UX considerations when implementing passkeys

Adopting passkeys offers significant security and usability benefits but requires thoughtful implementation:

Supported devices: The UX of authentication and registration of a passkey is OS and browser dependent, and on some devices can be confusing, it is important to allowlist devices and browsers that have a good onboarding experience
Fallback flow when a passkey is not available: Although some devices allow for syncable passkeys, this is definitely not the standard, so having a fallback authentication method for when a passkey is not available is key. However this poses both a security threat and potential friction for the user, so careful consideration needs to go into the flow
Flow to add a new passkey: Similar to (2), a flow to add a new passkey is key. Passkeys are still fickle today, a change in browser profile results in a lost passkey; a complete wipe of cookies on Chrome also results in a loss of the passkeys. A flow to add multiple passkeys is a must

Conclusion

Passkeys represent a pivotal shift in digital authentication, offering a secure and user-friendly alternative to traditional passwords. For organizations considering passkeys, understanding both the technological landscape and user experience considerations is critical. If you're ready to explore passkeys for your business, SlashID is here to assist. Don't hesitate to reach out to us or sign up for free here!

Remix authentication with SlashID

vincenzoiozzo — Thu, 04 Jan 2024 15:40:36 +0000

Meet `@slashid/remix`

@slashid/remix is our Remix-first identity SDK. We've borrowed the power of our React SDK and aligned it with Remix's unique design patterns.

We've built the SlashID Remix SDK with ease-of-use and developer experience as our core design pillar.

@slashid/remix is our easiest to use SDK - ever! Forget about navigating through complex API documentation. @slashid/remix provides the smallest API surface possible so that it stays out of your way, enabling you to get productive fast.

Key Features

Server side rendering (SSR)

Wave goodbye to loading spinners. Remix is all about parallelizing data fetching for optimized rendering. Our components and authentication logic run server-side so you can optimise your first render based on the users authentication state. Render once.

Protected Pages

Gate pages behind login, or protect pages from users without sufficient privilege to view them using Groups - on the server and/or in the client.

Pre-built log-in & sign-up form

Render your login form with just three lines of code. Magic links, passkeys, OTP, SAML, OIDC & passwords - we've got you covered.

Not to your taste? Our form appearance can be completely customised - and we mean *completely*. Check out Form: CSS custom properties, and Form: Layout Slots & Primitives.

Auth-aware conditional rendering

Use the <LoggedIn>, <LoggedOut> and <Groups> control components to conditionally render parts of a page depending on a users authentication state or group membership.

The SDK in Action

Prerequisites

You will need to sign up to SlashID and create an organization, once you've complete this you'll find your organization ID in Settings -> General.

Your environment should have the following dependencies installed:

node.js => >=20.x.x
react => >=18.x.x

1. Install `@slashid/remix`

Once you have a Remix application ready to go, you need to install the SlashID Remix SDK. This SDK provides a prebuilt log-in & sign-up form, control components and hooks - tailor made for Remix.

npm install @slashid/remix

2. Create SlashID app primitives

In your Remix application create a file app/slashid.ts.

In this file create the SlashID application primitives and re-export them, you'll use them later.

// app/slashid.ts

import { createSlashIDApp } from '@slashid/remix'

export const {
  SlashIDApp,
  slashIDRootLoader,
  slashIDLoader
} = createSlashIDApp({ oid: "YOUR_ORGANIZATION_ID" });

oid is your organization ID, you can find it in the SlashID console under Settings -> General.

3. Configure `slashIDRootLoader`

To configure SlashID in your Remix application you'll need to update your root loader. With a small change you'll have easy access to authentication in all of your Remix routes.

Import the slashIDRootLoader you created in the previous step, invoke it and export it as loader.

// root.ts

import { LoaderFunction } from "@remix-run/node";
import {
  Links,
  LiveReload,
  Meta,
  Outlet,
  Scripts,
  ScrollRestoration,
  useLoaderData,
} from "@remix-run/react";

import { slashIDRootLoader } from "~/slashid";

export const loader: LoaderFunction = slashIDRootLoader();

export default function App() {
  return (
    <html lang="en">
      <head>
        <meta charSet="utf-8" />
        <meta name="viewport" content="width=device-width, initial-scale=1" />
        <Meta />
        <Links />
      </head>
      <body>
        <Outlet />
        <ScrollRestoration />
        <Scripts />
        <LiveReload />
      </body>
    </html>
  );
}

If you need to load additional data via the root loader, you can simply pass a loader function to slashIDRootLoader. You can even check for authentication right here in the root loader.

// root.ts

import { slashIDRootLoader } from "~/slashid"
import { getUser } from '@slashid/remix'

export const loader: LoaderFunction = slashIDRootLoader((args) => {
  const user = getUser(args)

  if (user) {
    // the user is logged in
  }

  // fetch data

  return {
    hello: "world!" // your data
  }
});

4. Wrap your application body with `<SlashIDApp>`

In step 2 you created SlashIDApp, it provides authentication state to your React component tree. There is no configuration, just add it to your Remix application.

// root.tsx

import { SlashIDApp } from '~/slashid'

export default function App() {
  return (
    <html lang="en">
      <head>
        <meta charSet="utf-8" />
        <meta name="viewport" content="width=device-width, initial-scale=1" />
        <Meta />
        <Links />
      </head>
      <body>
        {/* Wrap the contents of your <body> with SlashIDApp */}
        <SlashIDApp>
          <Outlet />
          <ScrollRestoration />
          <Scripts />
          <LiveReload />
        </SlashIDApp>
      </body>
    </html>
  );
}

5. Create your log-in/sign-up page

SlashID offers a prebuilt form that works for both log-in and sign-up. Users with an account can log-in here and users without one need to simply complete the form to create their account.

// routes/login.tsx

import {
  ConfigurationProvider,
  Form,
  type Factor,
} from "@slashid/remix";

const factors: Factor[] = [
  { method: "email_link" }
];

export default function LogIn() {
  return (
    <div style={{ width: "500px" }}>
      <ConfigurationProvider factors={factors}>
        <Form />
      </ConfigurationProvider>
    </div>
  );
}

6. Protecting your pages

Server side

To protect your routes you can use the slashIDLoader you created in step 2. This utility is a wrapper for your loaders that provides authentication state to your loader code.

You'll check if the user exists, and if not redirect them to the login page.

The useSlashID() hook provides authentication state & helper functions to your React code, here you'll implement logOut too.

// routes/_index.tsx

import { slashIDLoader } from '~/slashid'
import { getUser, useSlashID } from '@slashid/remix'

export const loader = slashIDLoader((args) => {
  const user = getUser(args)

  if (!user) {
    return redirect("login")
  }

  return {}
})

export default function Index() {
  const { logOut } = useSlashID()

  return (
    <div>
      <h1>Index</h1>
      <p>You are logged in!</p>
      <button onClick={logOut}>
        Log out
      </button>
    </div>
  )
}

Client side

SlashID has several Control Components that allow you to conditionally show or hide content based on the users authentication state.

You'll implement <LoggedIn>, <LoggedOut>, and provide the option to log-out by implementing the logOut helper function from the useSlashID() hook.

// routes/_index.tsx

import { LoggedIn, LoggedOut, useSlashID } from '@slashid/remix'
import { useNavigate } from "@remix-run/react";

export default function Index() {
  const { logOut } = useSlashID()
  const navigate = useNavigate();

  return (
    <div>
      <LoggedIn>
        You are logged in!
        <button onClick={logOut}>
          Log out
        </button>
      </LoggedIn>
      <LoggedOut>
        {navigate("login")}
      </LoggedOut>
    </div>
  )
}

Learn more here!

GDPR Compliance: Consent Management with SlashID

vincenzoiozzo — Fri, 03 Nov 2023 18:30:11 +0000

Introduction

At SlashID we make it easy for you to collect, store and process user data in a way that complies with the European Unions' General Data Protection Regulation (GDPR) and ePrivacy Directive legislations. We deeply value your users' privacy.

In this blog post, we're excited to introduce the <GDPRConsentDialog> component from the SlashID React SDK. As a companion for our data residency features, the <GDPRConsentDialog> component makes GDPR compliance effortless and worry-free.

Collecting user consents

We store consents in our Data Vault, making them readily available anywhere you implement SlashID.

Consent is broken down into five high-level categories:

Analytics
Marketing
Retargeting
Tracking
Necessary cookies

By default the <GDPRConsentDialog> prompts the user to Accept all or Reject all; where reject all also includes rejecting "necessary cookies".

<GDPRConsentDialog />

The Customize button reveals a set of controls where a user can choose by category what consent they are comfortable to give.

Sometimes a subset of cookies are necessary to provide a service or comply with legal requirements, like data protection laws.

Enabling this is as simple as setting the necessaryCookiesRequired prop when implementing the <GDPRConsentDialog> component.

<GDPRConsentDialog necessaryCookiesRequired />

We've built the <GDPRConsentDialog> with maximum flexibility in mind.

If you have a more complex use case like custom consent levels when choosing Accept all and Reject all, or disabling interaction with your product until consent has been given - you're in luck! We have support for these edge-cases and more: check out the documentation.

Reading and writing consents programatically

Sometimes there are actions in your product which are gated behind a users consent, for example publishing events to your analytics platform.

With SlashID you can access a users consents with the useGDPRConsent() hook, and use it to decide whether or not the action can be performed.

import { useGDPRConsent, GDPRConsentLevel } from '@slashid/react'
import { useAnalytics } from '...'

function Component() {
  const { consents, isLoading } = useGDPRConsent()
  const { publish } = useAnalytics()

  if (isLoading) {
    return <div>Loading consent...</div>
  }

  const analyticsAllowed = consents.some(
    ({ consent_level }) => consent_level === GDPRConsentLevel.Analytics
  )

  const addToCart = () => {
    if (analyticsAllowed) {
      publish({
        name: 'add_to_cart',
        payload: {
          /* ... */
        },
      })
    }

    // ...
  }

  return <button onClick={addToCart}>Add to cart</button>
}

You might find yourself in a position where you would like to offer your users the option to "upgrade" their consent and opt-in to some functionality.

The useGDPRConsentHook() hook provides you a mechanism to do just that.

import { useGDPRConsent, GDPRConsentLevel } from '@slashid/react'
import { useAnalytics } from '...'

function Component() {
  const { consents, isLoading, updateGdprConsent } = useGDPRConsent()

  if (isLoading) {
    return <div>Loading consent...</div>
  }

  const analyticsAllowed = consents.some(
    ({ consent_level }) => consent_level === GDPRConsentLevel.Analytics
  )

  const enableAnalytics = () => {
    updateGdprConsent([
      ...consents,
      GDPRConsentLevel.Analytics
    ])
  }

  return (
    <div>
      {!analyticsAllowed && (
        <p>
          You have analytics disabled, your user dashboard has insufficient data to operate.
        </p>
        <button onClick={enableAnalytics}>
          Enable analytics
        </button>
      )}

      {/* ... */}
    </div>
  )
}

Conclusion

In this blogpost we explained how to collect user consent with the <GDPRConsentDialog> and use the data from useGDPRConsent() to make informed decisions within your product, GDPR compliance has never been easier.

Ready to try SlashID? Sign up here!

Is there a feature you’d like to see, or have you tried out SlashID and have some feedback? Let us know!

JWT Implementation Pitfalls, Security Threats, and Our Approach to Mitigate Them

vincenzoiozzo — Sat, 23 Sep 2023 14:47:41 +0000

JSON Web Tokens

There are many excellent introductions to JWTs, so for the purposes of this discussion we will focus on the structure.

JWTs are typically transmitted as base-64 encoded strings, and are composed of three parts separated by periods:

A header containing metadata about the token itself
The payload, a JSON-formatted set of claims
A signature that can be used to verify the contents of the payload

For example, this JWT

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvZSBTbGFzaElEIiwiaWF0IjoxNTE2MjM5MDIyfQ.4cL42NsNCXLPEvmvNGxHN3wLuarpp98wwezHnSt2fqg

comprises the following parts

Part	Encoded value	Decoded value	Description
Header	eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9	{ "alg": "HS256", "typ": "JWT"}	Indicates that this is a JWT and that it was hashed with the HS256 algorithm (HMAC using SHA-256)
Payload	eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvZSBTbGFzaElEIiwiaWF0IjoxNTE2MjM5MDIyfQ	{"sub": "1234567890", "name": "SlashID User", "iat": 1516239022}	Payload with claims about a user and the token
Signature	4cL42NsNCXLPEvmvNGxHN3wLuarpp98wwezHnSt2fqg	N/A	The signature generated using the HS256 algorithm that verifies the payload

The important aspect of this is that the JWT is signed, meaning that the claims in the payload can be verified, if one has access to the appropriate cryptographic key.

The algorithm used for the signature is stored in the Header (alg) and as we'll see later in the article, this becomes the source of a lot of issues with JWTs.

The signature of a JWT token is calculated as follows:

signAndhash(base64UrlEncode(header) + '.' + base64UrlEncode(payload))

Where signAndhash is the signing and hashing algorithms specified in the alg header field. The JOSE IANA page contains the list of supported algorithms.

In the example above HS256 stands for HMAC using SHA-256 and the secret is a 256-bit key.

Signing is not the same as encryption - even without the cryptographic key for verifying, anybody can decode the token payload and inspect the contents.

Naming convention

There are many standards associated with JWTs, it is useful to clarify a few different formats as we'll use them throughout the article.

JWT (JSON Web Token): JSON-based claims format using JOSE for protection

JOSE (Javascript Object Signing and Encryption): set of open standards, including:

JWS (JSON Web Signature): JOSE standard for cryptographic authentication
JWE (JSON Web Encryption): JOSE standard for encryption
JWA (JSON Web Algorithms): cryptographic algorithms for use in JWS/JWE
JWK (JSON Web Keys): JSON-based format to represent JOSE keys

The JWT specification is relatively limited as it only defines the format for representing information ("claims") as a JSON object that can be transferred between two parties.
In practice, the JWT spec is extended by both the JSON Web Signature (JWS) and JSON Web Encryption (JWE) specifications, which define concrete ways of actually implementing JWTs.

Anatomy of a JWT-related bug

A key aspect of JWTs, and one of the reasons why they have become so popular, is that they can be used in a stateless manner. In other words, the server doesn't store a copy of the JWTs it mints. As a result, to check the validity of the token both the client and the server need to verify their signature. The validity of the signature is how we prove the integrity of the token.

Generally vulnerabilities in JWT implementations rely on either a failure to validate a token signature, a signature bypass, or a weak/insecure secret used to encrypt or sign a token.

Fundamentally three design choices make JWT implementations prone to issues:

Deciding the decryption/validation algorithm based on untrusted ciphertext
Allowing broken algorithms (RSA PKCS#1 v1.5 encryption) and "none"
Allowing for very complex signing options. For instance, supporting X.509 Certificate Chain.

Let's see some of the most common issues with JWTs.

The "none" Algorithm

The none algorithm is intended to be used for situations where the integrity of the token has already been verified. Unfortunately, some libraries treat tokens signed with the none algorithm as a valid token with a verified signature. This would allow an attacker to bypass signature checks and mint valid JWT tokens.

Solution: Always sanitize the alg field and reject tokens signed with the none algorithm.

"Billion hashes attack"

Tervoort recently disclosed at Black Hat a new attack pattern.

JWT tokens support various families of PBES2 as signing/encryption algorithms. The p2c header parameter is required when using PBES2 and it is used to specify the PBKDF2 iteration count.

An unauthenticated attacker could use the parameter to DoS a server by specifing a very large p2c value resulting in billions of hashing function iterations per verification attempt.

Solution: Always sanitize the p2c parameter.

Brute-forcing or stealing secret keys

Some signing algorithms, such as HS256 (HMAC + SHA-256), use an arbitrary string as the secret key. It's crucial that this secret can't be easily guessed, brute-forced by an attacker or stolen.

An attacker with the secret key would be able to create JWTs with any header and payload values they like, then use the key to re-sign the token with a valid signature.

Solution: Avoid weak secret keys, implement frequent key rotation.

Algorithm confusion

As discussed, JWTs support a variety of different algorithms (including some broken ones) with significantly different verification processes. Many libraries provide a single, algorithm-agnostic method for verifying signatures. These methods rely on the alg parameter in the token's header to determine the type of verification they should perform.

Problems arise when developers use a generic signature method and assume that it will exclusively handle JWTs signed using an asymmetric algorithm like RS256. Due to this flawed assumption, they may end up in a "type confusion" type of scenario. Specifically, a scenario where the public key of a keypair is used as an HMAC secret for a symmetric cypher instead.

An attacker in this case can send a token signed using a symmetric algorithm like HS256 instead of an asymmetric one. This means that an attacker could sign the token using HS256 and the static public key used by the server to verify signatures, and the server will use the same public key to verify the symmetric signature thus completely bypassing the signature verification process.

Solution: Always verify the alg parameter and ensure that the key passed to the verification function matches the type of algorithm used for the signature.

Key injection/self-signed JWT

Although only the alg parameter is mandatory for a token, JWT headers often contain several other parameters. Some of the more common ones are:

jwk (JSON Web Key) - Provides an embedded JSON object representing the key.
jku (JSON Web Key Set URL) - Provides a URL from which servers can fetch a set of keys to verify signatures.
kid (Key ID) - Provides an ID that servers can use to identify the correct key in cases where there are multiple keys to choose from.

These user-controllable parameters each tell the recipient server which key to use when verifying the signature.

Injecting self-signed JWTs via the jwk parameter

The jwk header parameter allows an attacker to specify an arbitrary key to verify the signature of a token. Servers should only use a limited allow-list of public keys to verify JWT signatures. However, default implementations of JWT verification libraries allow for arbitrary signatures to be used hence the developer has to allow-list specific keys or otherwise an attacker could bypass the signature verification process.

Solution: Disallow the usage of jwk or have an allow-list of valid keys.

Injecting self-signed JWTs via the jku parameter

Similar to the example below it is crucial that the keys passed to the verification function via the jku parameters are part of an allow-list. Further the implementer should also
have an allow-list of domains and valid TLS certificates for those domains.

In fact, JWK Sets like this are often exposed publicly via a standard endpoint, such as /.well-known/jwks.json - if a domain is subject to a watering-hole attack or the verification function doesn't verify the domain an attacker is able to bypass signature verification.

Solution: Disallow the usage of jku` or have an allow-list of valid keys, trusted domains, and valid TLS certificates for those domains.

Injecting self-signed JWTs via the kid parameter

Verification keys are often stored as a JWK Set. In this case, the server may simply look for the JWK with the same kid as the token. However, the kid is an arbitrary string and it's up to the developer to decide how to use it to find the correct key in the JWK Set.

The kid parameter could be used for a command injection attack without proper sanitization. For example, an attacker might be able to use it to force a directory traversal attack pointing the verification function to a static, well-known file like /dev/null which would result in an empty string used for verification and often result in a signature bypass.

Another example is if the server stores its verification keys in a database, the kid parameter is also a potential vector for SQL injection attacks.

Solution: Always sanitize the kid parameter.

The SlashID approach

The issues above are just some of the common ones found in libraries, but many others keep coming up due to the design flaws described above. At SlashID, we strive to help customers secure their identities so we took a principled approach to the problem by abstracting it away for developers.

In a previous blogpost we've discussed some of the implementation details of our we mint and verify JWT tokens.

But we've gone further and added a JWT verification plugin to Gate.

The verification plugin works both with tokens issued by SlashID as well as tokens issued by a third-party.

To address the issues described above, we employ several countermeasures:

Only support pre-defined signing algorithms
Rotate signing keys frequently and adopt a vaulting solution to store the private key
Verify and pin TLS certificates for JWKS
Maintain an allow-list of valid domains
Disallow unsafe header parameters

By deploying Gate with the JWT verification plugin, developers can offload the complexity and risk of verifying JWT tokens to SlashID.

Let's see an example in action.

Conclusion

In this brief post we've shown how JWT tokens while ubiquitous and simple-looking at first, are fraught with risk. Gate is an effective and easy way to offload that
effort from application developers.

We’d love to hear any feedback you may have! Try out Gate with a free account.

Protecting Exposed APIs: Avoid Data Leaks with SlashID Gate and OPA

vincenzoiozzo — Wed, 13 Sep 2023 15:41:25 +0000

How did the Duolingo leak happen?

In March, Ivano Somaini wrote a tweet disclosing an unauthenticated Duolingo API as part of his Open Source Intelligence (OSINT) work.

The issue is pretty straightforward. A simple API call to the https://www.duolingo.com/2017-06-30/users?email endpoint reveals several private details about users and allows attackers to enumerate registered emails. Below an example output:

{
  "users": [
    {
      "joinedClassroomIds": [],
      "streak": 0,
      "motivation": "none",
      "acquisitionSurveyReason": "none",
      "shouldForceConnectPhoneNumber": false,
      "picture": "//simg-ssl.duolingo.com/avatar/default_2",
      "learningLanguage": "ru",
      "hasFacebookId": false,
      "shakeToReportEnabled": null,
      "liveOpsFeatures": [
        {
          "startTimestamp": 1693007940,
          "type": "TIMED_PRACTICE",
          "endTimestamp": 1693180740
        }
      ],
      "canUseModerationTools": false,
      "id": 184078602543312,
      "betaStatus": "INELIGIBLE",
      "hasGoogleId": false,
      "privacySettings": [],
      "fromLanguage": "en",
      "hasRecentActivity15": false,
      "_achievements": [],
      "observedClassroomIds": [],
      "username": "example",
      "bio": "",
      "profileCountry": "US",
      "chinaUserModerationRecords": [],
      "globalAmbassadorStatus": {},
      "currentCourseId": "DUOLINGO_RU_EN",
      "hasPhoneNumber": false,
      "creationDate": 146229322008,
      "achievements": [],
      "hasPlus": false,
      "name": "o",
      "roles": ["users"],
      "classroomLeaderboardsEnabled": false,
      "emailVerified": false,
      "courses": [
        {
          "preload": false,
          "placementTestAvailable": false,
          "authorId": "duolingo",
          "title": "Russian",
          "learningLanguage": "ru",
          "xp": 370,
          "healthEnabled": true,
          "fromLanguage": "en",
          "crowns": 7,
          "id": "DUOLINGO_RU_EN"
        }
      ],
      "totalXp": 370,
      "streakData": {
        "currentStreak": null
      }
    }
  ]
}

Armed with this API, an attacker published a dump of 2.6 million user records on VX-Underground.

This kind of incident is far from isolated, and Duolingo is just one of the many examples. In a similar incident in 2021, the "Add Friend" API allowed linking phone numbers to user accounts, costing Facebook over $275 million in fines from the Irish Data Protection Commission.

Introducing Gate

At SlashID, we believe that security begins with Identity. Gate is our edge access control service to protect APIs and workloads.

Gate can be used to monitor or enforce authentication, authorization and identity-based rate limiting on APIs and workloads, as well as to detect, anonymize, or block personally identifiable information (PII) exposed through your APIs or workloads.

Read on to learn how to deploy Gate to prevent data breaches like the ones mentioned above.

Deploying Gate

Gate can be deployed in multiple ways: as a sidecar for your service, as an external authorizer for Envoy, an ingress proxy or a plugin for your favorite API Gateway. See more in the Gate configuration docs.

For this toy example we chose a simple Docker Compose deployment, which looks like this:

version: '3.7'

services:
  backend:
    build: backend
    ports:
      - 8000:8000
    environment:
      - PORT=8000
    env_file:
      - envs/env.env
    restart: on-failure

  gate:
    image: slashid/gate:latest
    volumes:
      - ./gate.yaml:/gate/gate.yaml
    ports:
      - 8080:8080
    env_file:
      - envs/env.env
    command: --yaml /gate/gate.yaml
    restart: on-failure
    depends_on:
      - backend

The Docker Compose spawns two services: Gate and a toy backend.

Simulating the leaky API

Our toy backend contains a REST API that behaves similarly to the Duolingo one:

users = [
    {'email': 'test@example.com', 'name': 'Test User', 'id': 1},
    {'email': 'john@example.com', 'name': 'John Doe', 'id': 2},
    # ... add more users if needed
]

def get_user_by_email(email: str) -> Optional[dict]:
    for user in users:
        if user['email'] == email:
            return user
    return None

@app.get("/get_user/", tags=["business"])
async def read_user(email: str = Query(..., description="The email of the user to search for")):
    user = get_user_by_email(email)
    if user:
        return user
    else:
        raise HTTPException(status_code=404, detail="User not found")

Let's test it:

curl 'http://gate:8080/get_user/?email=test@example.com' | jq
{
  "email": "test@example.com",
  "name": "Test User",
  "id": 1
}

Detecting PII data through Gate

Gate has a plugin-based architecture and we expose several built-in plugins. In particular, the PII Anonymizer plugin allows the detection and anonymization of PII or other sensitive data.

The PII Anonymizer plugin can be configured to exclusively monitor PII (as opposed to editing the traffic) by setting the anonymizers rule to keep. We'll show an example in the next section.

Let's see a simple Gate configuration that detects email addresses and rewrites the HTTP response to anonymize the field with a hash of the email address:

gate:
  port: 8080
  log:
    format: text
    level: info

  plugins_http_cache:
    - pattern: '*'
      cache_control_override: private, max-age=600, stale-while-revalidate=300

  plugins:
    - id: pii_anonymizer
      type: anonymizer
      enabled: false
      intercept: request_response
      parameters:
        anonymizers: |
          EMAIL_ADDRESS:
            type: hash

  urls:
    - pattern: '*/get_user'
      target: http://backend:8000
      plugins:
        pii_anonymizer:
          enabled: true

Let's test it:

curl 'http://gate:8080/api/get_user/?email=test@example.com' | jq
{
  "email": "973dfe463ec85785f5f95af5ba3906eedb2d931c24e69824a89ea65dba4e813b",
  "id": 1,
  "name": "Test User"
}

Detecting PII and blocking the request with OPA

Note: similarly to the PII detection plugin, the OPA plugin can also be run in monitoring mode. See the end of the blogpost to find out more.

Sometimes hashing the request is not enough and you want to block it entirely, let's see how to combine the PII detection plugin with the OPA plugin to detect and block requests containing PII data.

Note: In the examples below we embed the OPA policies directly in the Gate config but they can also be served through a bundle, please check out our documentation to learn more about the plugin.

gate:
  port: 8080
  log:
    format: text
    level: info

  plugins_http_cache:
    - pattern: '*'
      cache_control_override: private, max-age=600, stale-while-revalidate=300

  plugins:
    - id: authz_deny_pii
      type: opa
      enabled: false
      intercept: response
      parameters:
        <<: *slashid_config
        policy_decision_path: /authz/allow
        policy: |
          package authz

          import future.keywords.if

          default allow := false

          no_key_found(obj, key) {
            not obj[key]
          }

          allow if no_key_found(input.response.http.headers,  "X-Gate-Anonymize-1")

    - id: pii_anonymizer
      type: anonymizer
      enabled: false
      intercept: request_response
      parameters:
        anonymizers: |
          DEFAULT:
            type: keep
  urls:
    - pattern: '*/get_user'
      target: http://backend:8000
      plugins:
        pii_anonymizer:
          enabled: true
        authz_deny_pii:
          enabled: true

The authz_deny_pii instance of the OPA plugin enforces an OPA policy that blocks a request if the response contains a X-Gate-Anonymize-1. This is a header added by the PII detection plugin to notify of the presence of PII.

Let's see it in action:

/usr/server/app $ curl --verbose 'http://gate:8080/api/get_user/?email=test@example.com' | jq
* processing: http://gate:8080/api/get_user/?email=test@example.com
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0*   Trying 172.27.0.5:8080...
* Connected to gate (172.27.0.5) port 8080
> GET /api/get_user/?email=test@example.com HTTP/1.1
> Host: gate:8080
> User-Agent: curl/8.2.1
> Accept: */*
>
< HTTP/1.1 403 Forbidden
< Cache-Control: private, max-age=600, stale-while-revalidate=300
< Content-Length: 0
< Content-Type: application/json
< Date: Sat, 02 Sep 2023 13:58:00 GMT
< Server: uvicorn
< Via: 1.0 gate
< X-Gate-Anonymize-1: $.body.email 0 64 EMAIL_ADDRESS
<
  0     0    0     0    0     0      0      0 --:--:--  0:00:01 --:--:--     0
* Connection #0 to host gate left intact

Note that in this example pii_anonymizer is set to monitoring mode: type: keep for all PII types (DEFAULT). The plugin allows PII to pass through unchanged, without replacing it with an anonymized version of the data or changing the traffic in any way.

- id: pii_anonymizer
  type: anonymizer
  enabled: false
  intercept: request_response
  parameters:
    anonymizers: |
      DEFAULT:
        type: keep

Differential policy enforcement for authenticated users

Let's now enforce a new OPA policy that blocks requests containing PII only if the user is not authenticated, while allowing PII in requests of authenticated users.

For simplicity, in this example we'll use SlashID Access to handle authentication, but any Identity Provider (IdP) would be suitable.

gate:
  port: 8080
  log:
    format: text
    level: info

  plugins_http_cache:
    - pattern: '*'
      cache_control_override: private, max-age=600, stale-while-revalidate=300

  plugins:
    - id: authz_allow_if_authed_pii
      type: opa
      enabled: false
      intercept: response
      parameters:
        <<: *slashid_config
        policy_decision_path: /authz/allow
        policy: |
          package authz

          import future.keywords.if

          default allow := false

          key_found(obj, key) if { obj[key] }

          jwks_request := http.send({
              "cache": true,
              "method": "GET",
              "url": "https://api.slashid.com/.well-known/jwks.json"
          })
          valid_signature if io.jwt.verify_rs256(input.request.token, jwks_request.raw_body)

          allow if not key_found(input.response.http.headers, "X-Gate-Anonymize-1")
          allow if valid_signature

    - id: pii_anonymizer
      type: anonymizer
      enabled: false
      intercept: request_response
      parameters:
        anonymizers: |

          DEFAULT:
            type: keep
  urls:
    - pattern: '*/get_user'
      target: http://backend:8000
      plugins:
        pii_anonymizer:
          enabled: true
        authz_deny_pii:
          enabled: true

This rule is a bit more complicated, let’s see what happens step by step.

First, we retrieve the JSON Web Key Set (JWKS) from https://api.slashid.com/.well-known/jwks.json.
Later, we check that either the incoming authorization token has a valid RS256 signature signed by SlashID or that X-Gate-Anonymize-1 is not present.
If either condition is true, the request is allowed. Let's see this in action:

curl --verbose -L 'http://gate:8080/api/get_user/?email=test@example.com' | jq
* processing: http://gate:8080/api/get_user/?email=test@example.com
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0*   Trying 172.27.0.5:8080...
* Connected to gate (172.27.0.5) port 8080
> GET /api/get_user/?email=test@example.com HTTP/1.1
> Host: gate:8080
> User-Agent: curl/8.2.1
> Accept: */*
>
< HTTP/1.1 403 Forbidden
< Cache-Control: private, max-age=600, stale-while-revalidate=300
< Content-Length: 0
< Content-Type: application/json
< Date: Sat, 02 Sep 2023 16:04:24 GMT
< Server: uvicorn
< Via: 1.0 gate
< X-Gate-Anonymize-1: $.body.email 0 64 EMAIL_ADDRESS
<
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
* Connection #0 to host gate left intact

The request above is blocked because there is PII in the response and no valid JWT has been provided.

Let's send a request with a valid token:

curl -H "Authorization: Bearer <TOKEN>" 'http://gate:8080/api/get_user/?email=test@example.com' | jq
{
  "email": "test@example.com",
  "id": 1,
  "name": "Test User"
}

Note in this case that we configured the PII plugin to alert of PII presence but not to replace or obfuscate it in any way, hence why we see the original clear-text response.

Depending on the IdP you are using, it is also possible to create more complex policies that not only check the validity of the identity token, but also examine specific properties of the token.
(Look out for our next Gate blogpost for a deeper dive into this topic!)

Blocking requests to unknown URLs

More often than not, companies don't really know which APIs are exposed to begin with. Gate can help in this scenario too.

Gate plugin instances can be applied to all routes, or you can select specific routes. In the example config below we enable the PII and OPA plugin instances on all routes and selectively disable them on specific routes:


gate:
  port: 8080
  log:
    format: text
    level: info

  plugins_http_cache:
    - pattern: "*"
      cache_control_override: private, max-age=600, stale-while-revalidate=300

  plugins:
    - id: authz_allow_if_authed_pii
      type: opa
      enabled: true
      intercept: response
      parameters:
        <<: *slashid_config
        policy_decision_path: /authz/allow
        policy: |
          package authz

          import future.keywords.if

          default allow := false

          key_found(obj, key) if { obj[key] }

          jwks_request := http.send({
              "cache": true,
              "method": "GET",
              "url": "https://api.slashid.com/.well-known/jwks.json"
          })
          valid_signature if io.jwt.verify_rs256(input.request.token, jwks_request.raw_body)

          allow if not key_found(input.response.http.headers, "X-Gate-Anonymize-1")
          allow if valid_signature
    - id: pii_anonymizer
      type: anonymizer
      enabled: true
      intercept: request_response
      parameters:
        anonymizers: |
          DEFAULT:
            type: keep

  urls:

    - pattern: "*/api/echo"
      target: http://backend:8000
      plugins:
        authz_allow_if_authed_pii:
          enabled: false
        pii_anonymizer:
          enabled: false

    - pattern: "*"
      target: http://backend:8000

Note how the plugins are defined as enabled by default and how in the URLs we explicitly disable the plugins on selected paths (e.g. "*/api/echo").

/usr/server/app $ curl --verbose -X POST 'http://gate:8080/api/echo' -d "email=abc@abc.com" | jq
Note: Unnecessary use of -X or --request, POST is already inferred.
* processing: http://gate:8080/api/echo
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0*   Trying 172.27.0.5:8080...
* Connected to gate (172.27.0.5) port 8080
> POST /api/echo HTTP/1.1
> Host: gate:8080
> User-Agent: curl/8.2.1
> Accept: */*
> Content-Length: 17
> Content-Type: application/x-www-form-urlencoded
>
} [17 bytes data]
< HTTP/1.1 200 OK
< Cache-Control: private, max-age=600, stale-while-revalidate=300
< Content-Length: 360
< Content-Type: application/json
< Date: Sun, 03 Sep 2023 09:30:38 GMT
< Server: uvicorn
< Via: 1.0 gate
<
{ [360 bytes data]
100   377  100   360  100    17  32933   1555 --:--:-- --:--:-- --:--:-- 37700
* Connection #0 to host gate left intact
{
  "method": "POST",
  "headers": {
    "host": "backend:8000",
    "user-agent": "curl/8.2.1",
    "content-length": "17",
    "accept": "*/*",
    "content-type": "application/x-www-form-urlencoded",
    "x-b3-sampled": "1",
    "x-b3-spanid": "39b9a26c103c6b5d",
    "x-b3-traceid": "ce0b56fc209ec47fbe0496606595c06b",
    "accept-encoding": "gzip"
  },
  "url": "http://backend:8000/api/echo",
  "body": {
    "email": "abc@abc.com"
  }
}
/usr/server/app $ curl --verbose 'http://gate:8080/api/get_user/?email=test@example.com' | jq
* processing: http://gate:8080/api/get_user/?email=test@example.com
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0*   Trying 172.27.0.5:8080...
* Connected to gate (172.27.0.5) port 8080
> GET /api/get_user/?email=test@example.com HTTP/1.1
> Host: gate:8080
> User-Agent: curl/8.2.1
> Accept: */*
>
< HTTP/1.1 403 Forbidden
< Cache-Control: private, max-age=600, stale-while-revalidate=300
< Content-Length: 0
< Content-Type: application/json
< Date: Sun, 03 Sep 2023 09:31:37 GMT
< Server: uvicorn
< Via: 1.0 gate
< X-Gate-Anonymize-1: $.body.email 0 16 EMAIL_ADDRESS
<
  0     0    0     0    0     0      0      0 --:--:--  0:00:01 --:--:--     0
* Connection #0 to host gate left intact
/usr/server/app $

Running in monitoring mode

Just like the PII detection plugin, the OPA plugin also supports monitoring mode by adding monitoring_mode: true in its parameters as shown below:

    - id: authz_allow_if_authed_pii
      type: opa
      enabled: true
      intercept: response
      parameters:
        <<: *slashid_config
        monitoring_mode: true
        policy_decision_path: /authz/allow
        policy: |
          package authz

          import future.keywords.if

          default allow := false

          key_found(obj, key) if { obj[key] }

          jwks_request := http.send({
              "cache": true,
              "method": "GET",
              "url": "https://api.slashid.com/.well-known/jwks.json"
          })
          valid_signature if io.jwt.verify_rs256(input.request.token, jwks_request.raw_body)

          allow if not key_found(input.response.http.headers, "X-Gate-Anonymize-1")
          allow if valid_signature

Let's send a request with an invalid token:

curl -H "Authorization: Bearer abc" 'http://gate:8080/api/get_user/?email=test@example.com' | jq
{
  "email": "test@example.com",
  "id": 1,
  "name": "Test User"
}

The request passes but Gate logs the policy violation:

gate-demo-gate-1        | time=2023-09-04T13:37:06Z level=info msg=OPA decision: false decision_id=d9b20a8d-da43-4786-ae15-1ec91199786d decision_provenance={0.55.0 19fc439d01c8d667b128606390ad2cb9ded04b16-dirty 2023-09-02T15:18:29Z   map[gate:{}]} plugin=opa req_path=/api/get_user/ request_host=gate:8080 request_url=/api/get_user/?email=test%40example.com

Performance

Performance is key when intercepting and modifying network traffic, our plugins were built for high performance in mind.
For instance we embed an optimized version a rego interpreter vs standing up a separate OPA server.

Let's look at a simple benchmark to see the impact of the two plugins on the network traffic.

Here's a simple benchmarking script:

#!/bin/sh
iterations=$1
url=$2

echo "Running $iterations iterations for curl $url"
totaltime=0.0

for run in $(seq 1 $iterations)
do
 time=$(curl $url \
    -s -o /dev/null -w "%{time_total}")
 totaltime=$(echo "$totaltime" + "$time" | bc)
done

avgtimeMs=$(echo "scale=4; 1000*$totaltime/$iterations" | bc)

echo "Averaged $avgtimeMs ms in $iterations iterations"

In our demo, a request without any interception results in the following:

/usr/server/app $ ./benchmark.sh 10000 'http://gate:8080/api/get_user/?email=test@example.com'
Running 10000 iterations for curl http://gate:8080/api/get_user/?email=test@example.com
Averaged 1.1820 ms in 10000 iterations
/usr/server/app $

When we enable PII detection and rewriting (hashing of the email address) coupled with our caching plugin:

/usr/server/app $ ./benchmark.sh 10000 'http://gate:8080/api/get_user/?email=test@example.com'
Running 10000 iterations for curl http://gate:8080/api/get_user/?email=test@example.com
Averaged 1.5955 ms in 10000 iterations
/usr/server/app $

Next, we test PII detection in monitoring mode:

/usr/server/app $ ./benchmark.sh 10000 'http://gate:8080/api/get_user/?email=test@example.com'
Running 10000 iterations for curl http://gate:8080/api/get_user/?email=test@example.com
Averaged 1.5176 ms in 10000 iterations
/usr/server/app $

Last, let's run PII detection in monitoring mode coupled with OPA like we did in the example in the previous section:

/usr/server/app $ ./benchmark.sh 10000 'http://gate:8080/api/get_user/?email=test@example.com'
Running 10000 iterations for curl http://gate:8080/api/get_user/?email=test@example.com
Averaged 1.8532 ms in 10000 iterations
/usr/server/app $

Thanks to a combination of our caching plugin and Gate’s own architecture, the average overhead in our toy application is 0.6712 ms when both OPA and PII detections are turned on.

Conclusion

In this blogpost we've shown how you can combine the Gate PII and OPA plugins to easily detect and prevent PII leakage.

We’d love to hear any feedback you may have! Try out Gate with a free account. If you'd like to use the PII detection plugin, please contact us at contact@slashid.dev!

Authenticate your Shopify customers with SlashID

vincenzoiozzo — Thu, 27 Jul 2023 10:33:59 +0000

Drive repeat business, reduce friction

Successfully identifying your customers is key to repeat business, personalizing shopping experiences, and effective multi-channel marketing.

However, complex checkouts and password requirements are two of the top reasons for increased cart abandonment rate.

Simplifying the checkout process and using passwordless login can retain customer data for personalization and reduce cart abandonment, improving the user experience and boosting account creation conversion rates by up to 54%.

By default, Shopify provides a login form where your customers can sign up or sign in using email and password. It is not possible to easily integrate users across multiple channels or platforms (e.g., your own marketing website).

By adding SlashID Login to your Shopify store, your customers will be able to login to your store without having to create and remember passwords for an effortless shopping experience. We support all passwordless authentication methods like passkeys, social login, SMS and email links.

Control UX and branding

The SlashID login form is entirely configurable so you can choose which authentication methods to enable for your customers.

Additionally, you can customize the look and feel of the SlashID login form directly from the Shopify admin panel. This includes setting the color palette, logo, font family and text content to match your brand.

Try out the SlashID Login app:

Get a free SlashID account from our website
Install the SlashID Login app from the official Shopify store and configure it using our step by step guide

One login and user base across all your channels and products

The SlashID Login app is built on top of SlashID user tokens, which are exchanged for Shopify Multipass tokens in the background. This allows you to use SlashID’s login across all your platforms, storefronts and webapps, so your customers can navigate between your own websites and your Shopify store without having to authenticate multiple times.

Without the hassle of repeated logins, your customers will benefit from the enhanced user experience with seamless transitions and continuity across different systems. It improves convenience, saves time, and reduces friction, ultimately resulting in higher customer satisfaction and engagement while maintaining a unified brand experience.

Add workflows and organizations to your Store

Through the SlashID Login App you can leverage modern features like Webhook and Organizations to customize the user journey, create complex users structures and orchestrate analytics and marketing workflows.

Try it out!

Give your customers the smoothest login experience with the SlashID Login app. Eliminate account recovery friction with passkeys and social logins, customize the SlashID login form with your branding and allow seamless transitions between your own platform and Shopify.

Ready to get started with SlashID? Get a free account here!

Is there a feature you’d like to see, or have you tried out the SlashID Login app and have some feedback? Let us know!

Passkeys deep-dive: security and implementations considerations

vincenzoiozzo — Fri, 02 Jun 2023 23:30:49 +0000

Since Google announced support for passkeys for all Gmail accounts – a clear first step in phasing out passwords – passkeys have been a hot topic.
But what are passkeys exactly, how do they work and how are they going to change the security landscape? In this blog post, we review the current state of the technology from a security standpoint and we’ll discuss some critical aspects of passkey implementation.

You can also jump straight to the code here: GitHub and live.

Table of content

This is a rather long blogpost, we split it in separate sections to make it easier to consume it:

Passkeys 101

Security and threat model

Implementation considerations

Passkeys 101

Feel free to skip this section if you are already familiar with passkeys!

In this section:

What are passkeys?

Why now?

How are credentials shared and stored?

What are passkeys?

The big promise of passkeys is to get rid of passwords, of most phishing attacks and, in some cases, of multi factor authentication (MFA).

A passkey is a commercial term for discoverable FIDO/WebAuthn credentials that can be used for passwordless authentication. From a technical point of view, a passkey is a public and private key pair that can be used to authenticate a user to a relying party (i.e., a website or an app) without using passwords.
Websites can create or verify credentials through a web API called WebAuthn, implemented in all major browsers.

The keys are stored in an authenticator (this is an approximation, we’ll discuss more below), which could be anything from a physical security key to a smartphone’s secure enclave or even a virtual, software-based system that implements the Client to Authenticator Protocol 2 (CTAP2). CTAP2 is how an authenticator talks to a web browser to complete a WebAuthn credential creation or verification process.

In other words, the browser talks to the authenticator through the CTAP2 protocol to perform the key creation and verification ceremonies initiated by a website through the WebAuthn APIs.

Why now?

The idea of using public-key cryptography for user authentication and the WebAuthn standard have been around for a number of years. However, until recently, there was no established infrastructure to share key pairs across devices, making account recovery and cross-device authentication hard. Due to these reasons, until now, the adoption of WebAuthn has been fairly modest, with it primarily implemented as a second authentication factor, not the primary one.

Furthermore, the UX in most browsers was very counterintuitive until recently.

Apple and Google's introduction of passkeys, coupled with their push to build ways to share credentials across devices, has significantly boosted interest in WebAuthn over the past 12 months.
For example, Apple reported that Kayak, Robinhood and Instacart are all experimenting with it, and the recent passkey support for Gmail is the first large-scale rollout of the technology and will undoubtedly lead to significant improvements of the user experience.

How are credentials shared and stored?

As mentioned above, passkeys are key pairs, and the private key is not supposed to be accessible to the relying party or the outside world.
According to the WebAuthn standards, there are two types of credentials:

Discoverable credentials: stored on the client device, meaning that the private key itself is stored in the persistent storage embedded in the authenticator
Server-side credentials: The private key is encrypted with a second private key stored in the authenticator. The resulting blob is used as the credential ID for the key pair. There are multiple ways to achieve this; the most common one is called key wrapping. Note that while the relying party does have access to the private key, the relying party won’t be able to access it without the access to the authenticator, providing security guarantees similar to discoverable credentials

Passkeys add a twist to this concept as they are discoverable credentials that can be exported from the authenticator.

It is critical to notice that while passkeys will reduce adoption friction for WebAuthn, the security guarantees of passkeys are lower than regular, non-exportable, WebAuthn credentials and they are not standardized. In fact, the WebAuthn standard says:

“This specification defines no protocol for backing up credential private keys, or for sharing them between authenticators. In general, it is expected that a credential private key never leaves the authenticator that created it. Losing an authenticator therefore, in general, means losing all credentials bound to the lost authenticator, which could lock the user out of an account if the user has only one credential registered with the Relying Party. Instead of backing up or sharing private keys, the Web Authentication API allows registering multiple credentials for the same user.”

Since there are no technical standards for passkeys, different providers synchronize credentials in various ways, and these details are often not disclosed publicly.
In a previous blog post, we analyzed how Apple synchronizes passkeys.

As for Google, they use the Google Password/Passkey Manager, the security of which is beyond the scope of this blogpost, but you can read more here.

A practical consequence of this arrangement is that the security of passkeys and account recovery heavily depends on the security of the account linked to the syncing service (often your Apple or Google account). While at first this may seem a scary proposition for many, most account recovery flows today offer no better security by simply resorting to a reset link sent to an email address.

Security and Threat-modeling

In this section:

Phishing

Stolen Credentials

The end of multi-factor authentication (MFA)?

Phishing

One of the key selling points of passkeys and WebAuthn is that they are safer than passwords, providing a strong protection against phishing. In fact, all WebAuthn compliant browsers enforce a number of security checks.

First of all, WebAuthn doesn’t work without TLS. Furthermore, browsers enforce origin checks for credentials and most will prevent access to the platform authenticator unless the window is in focus or, in the case of Safari, the user triggers an action.

Thanks to origin checks, credentials are bound to an origin and cannot be used on a different domain. For this reason, most of the recent attacks involving domain squatting and phishing would fall flat because the malicious site wouldn’t be able to initiate the WebAuthn authentication process.

In other words, an attacker trying to compromise user credentials will need to either find a cross-site scripting (XSS) bug in the target website or a vulnerability in the browser, both of which are very high barriers to overcome. These are the only way in which they can bypass the WebAuthn checks, and even then a successful attacker wouldn’t have access to the private key itself, but only to a session token/cookie, which will expire once the browsing session is over.

In this blog post, we show the technical details of how Chrome enforces such checks.

In comparison to all other authentication methods — where an attacker only has to register a seemingly related domain and have a similar looking webpage to fool the victim through phishing — it is clear that WebAuthn is a much safer authentication method.

Stolen Credentials

Server-side

Another benefit of passkeys is that even if the credential database of a relying party is compromised and credentials are leaked, an attacker won’t be able to exploit them because no clear-text private key is ever shared with the relying party.
This also reduces the risk of dictionary attacks against reused credentials.

Client-side

However, the private keys are now stored on the user device and their security and threat model is not always straightforward to assess. Note that even for server-side credentials, the key used to derive the private keys is stored on the authenticator, and so the threat model is roughly the same.

As mentioned in the introduction, an authentication ceremony involves a website using the WebAuthn APIs to talk to the client/browser, which will interact with an authenticator via the CTAP2 protocol.

However, no storage security guarantees are enforced on the authenticator. In particular, the location where keys are stored is highly dependent on the user device, operating system and whether hardware security keys are used.

We ranked the different solutions currently available from strongest to weakest security guarantees:

Hardware security keys (Yubikeys or similar): these are dedicated devices with hardware security modules that only hold keys
Modern iOS/Android devices: most modern high end mobile devices have a Secure Element chip that offers similar security guarantees to a hardware security key, in that even if the device is compromised the keys won’t be leaked
Modern desktop devices: most modern laptops have a security module. However, certain hardware vendors limit which browsers can make use of the secure element
Legacy mobile devices and desktops: private keys are normally stored in the user filesystems and while they might be encrypted, compromising the user device will most definitely also compromise the credentials.

As a result, applications that require high security guarantees should assess the risk of storing credentials on unsafe, legacy devices. That said, those devices are also vulnerable to keyloggers which would compromise any password, so even an authenticator with lower security guarantees is in most cases better than passwords.

Adding credentials

Since stealing credentials is not a feasible attack pattern with passkeys, attackers might be more interested in finding logic vulnerabilities that allow them to add their own credentials to a user account. By adding credentials to an account, the attacker achieves the same effect (i.e., they are able to login and impersonate the user) as stealing credentials.

The WebAuthn standard doesn’t specify how a relying party should account for multiple credentials, hence it is left as a task for the developer. It does nevertheless encourage the registration of multiple credentials.

Different websites could opt for different approaches here, one is to only allow one credential per account (similar to a password) and outsource the credential recovery process to Google/Apple/Passkey synchronization provider. Another one is to have a step-up authentication mechanism that allows a user to add another credential to their account after a further identity verification on their identity.

The end of multi-factor authentication (MFA)?

The principle behind MFA is to increase the confidence in the user identity by using more than a single authentication factor. Generally, authentication factors can be one of three types: something you know, something you are or something you have.

Some authenticators such as modern mobile phones and security keys can enforce two or more factors at the same time when accessing passkeys. For instance, on iOS you are required to use FaceID (something you are) or enter your pin (something you know) in order to login with a passkey (something you have).

In certain jurisdictions, passkeys on modern authenticators could alone satisfy the EU Secure Customer Authentication standards (more on this here).

In general, non-roaming WebAuthn credentials stored on dedicated hardware security keys with biometrics/pin support should be safe as a replacement for MFA.

Whether passkeys could be a replacement for MFA is dependent on the trust the application has in the recovery process of the vendor synchronizing the credentials (in most cases, Google or Apple), because ultimately passkeys will be synchronized across multiple devices and could be recovered through the account recovery process of the vendors.

We think that, for the time being, MFA will likely still remain a key defense against attackers for high-security applications. However, for lower security applications, MFA could be entirely replaced by passkeys on modern devices within a few years.

Implementation considerations

Now that we’ve reviewed the UX and security implications of passkeys, let’s discuss key implementation details that a relying party should bear in mind when adopting passkeys.

In this section:

Secure key generation

Secure login

Random nonces

Security flags

Discoverable credentials vs server-side credentials

Adding new credentials to an account

WebAuthn is a fairly complicated technology; we recommend not rolling out your own implementation.

Secure key generation

The process of creating a credential starts when the relying party sends a request with a number of parameters (full list here). At a minimum, the server must send a random challenge/nonce, like shows in this example:


user_cred = {
   'user_name': 'example@example.com',
   'display_name': 'Mr Example’,
   'user_id': os.urandom(12),
}
challenge = os.urandom(32)
…
return jsonify({
    'credential': None,
    'displayName': user_cred['display_name'],
    'userName': user_cred['user_name'],
    'userId': base64.b64encode(user_cred['user_id']).decode('ascii'),
    'challenge': base64.b64encode(challenge).decode('ascii'),
    'relyingPartyName': 'localhost'}

The web application will then call navigator.credentials.create to generate a key pair.
The parameters of the call will look something like this:

   credOptions = {
     publicKey: {
       // Relying party
       rp: {
         name: relyingPartyName // 'localhost'
       },


       // User parameters
       user: {
         id: userIdBuffer, // os.urandom(12)
         name: userName, //example@example.com
         displayName: params.displayName, //Mr Example
       },


       // This specifies the list of acceptable key types for the authenticator to generate.
       // For most implementations, it’s either ECC (-7) or RSA (-256).
       pubKeyCredParams: [{
         type: 'public-key',
         alg: -7, // ECC
       }],


       // Here we can decide whether to use the current device as the authenticator or whether
       // we should allow the user to select the authenticator (eg: an external hardware security key)
       // ‘platform’ forces the choice of the local device
       authenticatorSelection: {
         authenticatorAttachment: 'platform',
       },


       // This is to avoid replay attacks and needs to be random. It’s the nonce sent by the server
       challenge: challengeBuffer,


       // Ask the authenticator to generate an attestation statement to prove the device type used
       // to generate this key. This doesn’t always work, apple devices will refuse to generate an
       // attestation statement for instance.
       attestation: 'direct',
     }

Once the key pair has been generated, the public key is returned to the relying party together with a number of other fields. The relying party verifies the data and, if successful, stores the public key associated with that user. This is an example payload:

{
  "attestation": "o2NmbXRmcGFja2VkZ2F0dFN0bXSiY2FsZyZjc2lnWEgwRgIhAM19ZXaMJ703tCUuinx9Pqkh+hhKAh0N+nZYufV0SSX1AiEAxxOaRaVchuQDFn8FWnfrR9lbLPR7fHzTlJktbvra5x9oYXV0aERhdGFYpEmWDeWIDoxodDQXD2R2YFuP5K65ooYyx5lc87qDHZdjRQAAAACtzgACNbzGCmSLCyXx8FUDACCaZeUU5GyTWfAlwU+D8vq/UsVgjwH1RAt8G6ngG/pyF6UBAgMmIAEhWCBOVpnWqcLp0U6DyQe1roMkSBrTRcir+LcIP1Pa925OhSJYIE+275/X4cNt16Q4hOYj5HN/Qb0vKaEH4p7jtsHfxvJd",
  "clientData": "eyJ0eXBlIjoid2ViYXV0aG4uY3JlYXRlIiwiY2hhbGxlbmdlIjoiczBqMFVjTU4tVV8zcGdZLTFzeXNqVXhySEVxREJGWmQ2a3RVNnZoeVh0dyIsIm9yaWdpbiI6Imh0dHA6Ly9sb2NhbGhvc3Q6NTAwMCIsImNyb3NzT3JpZ2luIjpmYWxzZX0=",
  "id": "mmXlFORsk1nwJcFPg_L6v1LFYI8B9UQLfBup4Bv6chc", //this value needs to be persisted in the server and associated with the user
  "type": "public-key"
}

The clientData object is a Base64-encode JSON:

{
  "type": "webauthn.create",
  "challenge": "s0j0UcMN-U_3pgY-1sysjUxrHEqDBFZd6ktU6vhyXtw",
  "origin": "http://localhost:5000",
  "crossOrigin": false
}

The attestation object is a Base64-encode CBOR map. The shape of the attestation object is:

{
 "attStmt": {   'alg': -7,
                'sig': b"0E\x02R\xa4\xfa\xf0\xb9@\xed\xc3\xeb\xf8\x0f"
                          b"\xd2?*p\xdd\x9b\x11W\xeb\xdd\xf0\x08\xcb4\x16"
                          b"\xa0\x88\xce\x02!\x00\xb4S\x07\xc8pJ\xb9=="
                          b"\x08\xe1Qf\x08\x959O\x8a/H7\x13\xec\x00"
                          b"[\x9e\xcf\x89\xca\xca\xfb"
            },
"authData": b"I\x96\r\xe5\x88\x0e\x8cht4\x17\x0fdv`[\x8f\xe4\xae\xb9"
                b"\xa2\x862\xc7\x99\\\xf3\xba\x83\x1d\x97cE\x00\x00\x00"
                b"\x00\xad\xce\x00\x025\xbc\xc6\nd\x8b\x0b%\xf1\xf0U"
                b"\x03\x00 \xe2\x98\xb2\xd8\xa5QK\x84\x02\x87\x83/Z"
                b"\xaf\xa3\xf0E\xe1J\n\x99\xe7\xd9\x1cR\x9eE!\xeb\\{i\xa5"
                b"\x01\x02\x03& \x01!X \xbel>^%\x90\x81U\xb7\xe1&\xa9\xda\x19r"
                b"\x9c<4M\x9c\x1dkZ\xe8\x8d\xfb\xdd /\x02\x17\xe7X j&w\xc7"
                b"\xf4\x18C\x8ec\x1e<\x95\xa7\x02\x1e\x18\xf9D\xb0["
                b"\xde\x11\x912\xf4\xb8\xabX\xe0\xc4\x0eU",
    "fmt": 'packed'
}

The decoded authData (which is a variable-length byte array, full spec here) in the attestation field gives us information about the credential just created and certain security flags we’ll discuss later:


{
    "attestedCredData":
         {   "aaguid": b"\xad\xce\x00\x025\xbc\xc6\nd\x8b\x0b%"
                       b"\xf1\xf0U",
              "credentialId": b"\x19\x81\xe5\x989Dq]"
                             b"\x0b\xf5\xc6\xbc]Do\xbb\xd9-~\xac"
                             b"\x81\x8dgS\xea\x08S\x10?\x124\x95",
              "credentialIdLength": 32,
              "credentialPublicKey": {   "alg": "ecc",
                                       "eccurve": "P256",
                                       "key": <cryptography.hazmat.backends.openssl.ec._EllipticCurvePublicKey object at 0x103f65b10>,
                                       "kty": "ECP",
                                       "x": b":\xe2\x0f}"
                                            b"[\x8a\xd2$"
                                            b"\xa2\xcc{."
                                            b"l\xa4\xf7\xbf"
                                            b"\xe8:\\\x18"
                                            b"\x06\xcbC\x11"
                                            b"K\xbeG\xe5"
                                            b"\x0fL\nY",
                                       "y": b"c\xa1\x96@"
                                            b">e\xa1\xac"
                                            b"\xcfB\xa4\x99"
                                            b"\\\x01\x02\xc0"
                                            b"\xe8\xce\x9e^"
                                            b"#p\x07\xc3"
                                            b"\x86\x07\x04s"
                                            b"\x18P\x00\xa8"}},
    "flags": {
              "attestedCredDataIncluded": True,
              "extensionDataIncluded": False,
              "userPresent": True,
              "userVerified": True
         },
   "flagsRaw": 69,
   "rpIdHash": b"I\x96\r\xe5\x88\x0e\x8cht4\x17\x0fdv`[\x8f\xe4\xae\xb9"
               b"\xa2\x862\xc7\x99\\\xf3\xba\x83\x1d\x97",
   "signCount": 0
}

The relying party must carefully verify the following:

The challenge in clientData corresponds to the one the relying party sent at the beginning of the key creation ceremony.
The blob contains the sha256 of the relying party id (rpId), in this example “localhost”. The relying party should verify that the hash matches the expected rpId.
Verify that attStmt within the attestation object is correct. In particular, each type of attestation statement has a different format and way to verify its validity. The attestation statement is key to assess the properties of the authenticator and its trustworthiness. Here’s more information on how to verify the statement based on their type.

Starting from iOS 16, Safari won’t generate attestation statements (attStmt set to none) for platform keys so a relying party won’t be able to verify the provenance of webauthn keys generated on the device.

Secure login

The high-level process to verify a login attempt is for the relying party to generate a random challenge and for the client to sign that challenge with a key such that the server can verify the signature on the challenge by possessing the public key associated with the keypair - this is called an assertion.

In other words, the relying party verifies an assertion made by the client by verifying the signature on the random nonce against a public key that was registered for that account.

In practice there are several steps that a relying party needs to perform in order to verify the assertion correctly.

As with key creation, the relying party sends the client options for the navigator.credentials.get call. At a minimum these must contain a random nonce/challenge, the rpID and the list of allowed credentials:

    return jsonify({
        'challenge': base64.b64encode(last_challenge).decode('ascii'),
        'rpId': 'localhost',
        'userVerification': 'required',
        'extensions': None,
        'allowCredentials': [{
            type: "public-key",
            id: "AK-r2A2ophbN_fw_xsHxP3z-l-5SVcbZi5Ez9oLgWrY"
        }],
        'timeout': 60000})

The client passes the option to navigator.credentials.get and the user is asked to authenticate. If successful, the return value is a PublicKeyCredential object.

The object is sent to the server and looks as follows:

{
  "id": "AK-r2A2ophbN_fw_xsHxP3z-l-5SVcbZi5Ez9oLgWrY",
  "raw_id": "AK-r2A2ophbN_fw_xsHxP3z-l-5SVcbZi5Ez9oLgWrY",
  "response": {
    "client_data_json": "eyJ0eXBlIjoid2ViYXV0aG4uZ2V0IiwiY2hhbGxlbmdlIjoiWGE2RGdfRTB5TFVZelBja05URDBER2pEcHZtX2JKRDhmazZnbHZJUDc3YyIsIm9yaWdpbiI6Imh0dHA6Ly9sb2NhbGhvc3Q6NTAwMCIsImNyb3NzT3JpZ2luIjpmYWxzZX0",
    "authenticator_data": "SZYN5YgOjGh0NBcPZHZgW4_krrmihjLHmVzzuoMdl2MFAAAAAA",
    "signature": "MEUCID2sx44Y2iuVdeBZV8BXxeuRGPzsOrbmS0mTCQ6j25SzAiEAwYem5DpkU_oHjVJopmWCSYDUhJpxGtwb7fjZPgZmaKA",
    "user_handle": "1EUqUv7528w"
  },
  "authenticator_attachment": "platform",
  "type": "public-key"
}

The four key steps for the verification procedure are:

The challenge in clientData corresponds to the one the relying party sent
Verify that the credential id match one of the credentials stored for the user
The payload contains the sha256 of the relying party id (rpId). The relying party should verify that the hash matches the expected rpId
Verify that the signature on the blob is a valid signature of the concatenation of the authData and the sha256 of the clientDataJSON fields. This signature must be made with the keypair the user is authenticating with

The full verification procedure is rather long and specified here.

Random nonces

For both authentication and credential creation, it is absolutely critical to make sure that nonces/challenges are truly random. Failure to do so would result in vulnerability to replay attacks.

It is also key for the relying party not to trust the client and its data. The relying party should store the nonce and verify it matches the one returned by the client.

Security flags

We’ve seen earlier how, as part of the key creation process, navigator.credentials.create returns a set of flags.

The flags field is 1 byte in length and contains the following flags:

Bit 0: User Present (UP) result.
- 1 means the user is present.
- 0 means the user is not present.
Bit 1: Reserved for future use (RFU1).
Bit 2: User Verified (UV) result.
- 1 means the user is verified.
- 0 means the user is not verified.
Bits 3-5: Reserved for future use (RFU2).
Bit 6: Attested credential data included (AT). Indicates whether the authenticator added attested credential data.
Bit 7: Extension data included (ED). Indicates if the authenticator data has extensions.

In particular, Bit 0 indicates that the authenticator asked the user to perform a “user presence test”. The WebAuthn specification says:

A test of user presence is a simple form of authorization gesture and technical process where a user interacts with an authenticator by (typically) simply touching it (other modalities may also exist), yielding a Boolean result.

Note that this does not constitute user verification because a user presence test, by definition, is not capable of biometric recognition, nor does it involve the presentation of a shared secret such as a password or PIN.

Bit 2 means that the authenticator asked the user to perform a “user verification test”. The specification says:

User Verification
The technical process by which an authenticator locally authorizes the invocation of the authenticatorMakeCredential and authenticatorGetAssertion operations. User verification MAY be instigated through various authorization gesture modalities; for example, through a touch plus pin code, password entry, or biometric recognition (e.g., presenting a fingerprint) ISOBiometricVocabulary.
The intent is to distinguish individual users.

Note that user verification does not give the Relying Party a concrete identification of the user, but when 2 or more ceremonies with user verification have been done with that credential it expresses that it was the same user that performed all of them. The same user might not always be the same natural person, however, if multiple natural persons share access to the same authenticator.

These flags coupled with attestation data are key to establish the trustworthiness of a key. In fact a strong authenticator which has created a keypair with both user presence and user verification is a good candidate replacement for MFA, captchas and other forms of verification.

Unfortunately, as we have mentioned throughout the article Apple has disabled attestation data on their passkeys significantly reducing the value of these flags.

Discoverable credentials vs server-side credentials

You might have noticed in the code snippets above that our toy relying party sent credential IDs to the browser when the authentication ceremony started. Server-side credentials are not discoverable, in fact the specification specifies:

“This means that the Relying Party must manage the credential’s storage and discovery, as well as be able to first identify the user in order to discover the credential IDs to supply in the navigator.credentials.get() call”

Hence to work with server-side credentials, the relying party needs to send an array of allowed credentials IDs for the user to login with.

However discoverable credentials don’t require credential IDs to be sent by the relying party, simply sending the challenge and the rpId is sufficient.

    return jsonify({
        'challenge': base64.b64encode(last_challenge).decode('ascii'),
        'rpId': site_config['relying_party_name'],
        'userVerification': 'required',
        'extensions': None,
        'timeout': 60000})

Adding new credentials to an account

As discussed, adding new credentials to a user account is a non-standardized flow, which is ripe for abuse. Relying parties need to be careful as attackers are likely to target this flow to compromise user accounts.

Passkeys make client-side synchronization and backup of credentials easier, hence there would be fewer circumstances in which a user might need to add another passkey to their account or reset their passkey. However, relying parties should account for that scenario nonetheless and the WebAuthn standard specifically encourages the creation of multiple credentials per account.

There are generally three approaches to this:

Only allow a single passkey per account (in this sense, a passkey is a 1:1 replacement for a password). This turns the problem of a lost passkey into an account reset issue.
Allow multiple passkeys to an account after a Step-Up Authentication step of the same strength. In other words, the user needs to authenticate via another passkey before being able to add another credential.
Allow multiple passkeys to an account after a Step-Up Authentication step of any strength. The upside here is the user experience, but the downside is that you reduce the security of the account to the security of the authentication factors used to add a new passkey.

Ultimately which path you pick is dependent on the sensitivity of your application.

Conclusion

Passkeys are a very exciting innovation in the authentication space. We are strong believers that identity is the last major area of security that hasn't gone through a significant upgrade in the last 10 years and, as such, is one of the key weaknesses and sources of threats.

The weakened guarantees of passkeys, compared to standard WebAuthn credentials (in particular, the inability to perform attestation), reduces their usefulness when it comes to having stronger guarantees on the user verification process as well as the security of the private key. Ultimately we are still a long way from getting rid of account takeovers and passwords. However, passkeys are also the first step towards mass adoption of what we believe to be a safer identity posture for users, so we look forward to more websites adopting them.

We prepared a small playground to see passkeys in action through the SlashID SDK, check it out! GitHub and live.

Multi-tenancy authentication done right

vincenzoiozzo — Mon, 17 Apr 2023 14:28:56 +0000

The Problem

Implementing complex identity structures securely is an extremely challenging task and more often than not becomes a textbook example of sunk cost fallacy.

Let’s take a B2B SaaS application as an example. Imagine you are developing an issue tracker application like Jira, let's call it Trackalot. The development journey normally goes something like this:

You start with a simple tag, let’s call it organization, in your users table to group users belonging to different customers, and you embed logic in your app to look up the organization field for conditional rendering and similar.

This is looking great – a small database migration and a couple of PRs later and you are done (or so you think)!
Your company is doing great and you start onboarding your first enterprise customer who has a few hundred users. Your product manager comes in and explains that the deal is not going to close unless the customer can specify their own multi-factor authentication (MFA) policy. So now you rush to create an organizations table, refactor all your code to account for the new table, migrate the database again and then write some custom logic to handle the different MFA flows that each customer may have.

It’s a fair amount of work but you got this, you crunch a little and deliver!
At this point, you might or might have not gotten the customer from (2) depending on how many sleepless nights you spent writing code. But great news: you now have an organization table and you can extend it easily! Now your product manager comes to you and explains that one of the customers needs custom templates for the magic links sign-in emails. Now you are at a crossroad, do you:

Create a tenant per customer in your Identity and Account Management (IAM) product/solution. A crippling doubt settles in: How are you going to login users belonging to different tenants? You park the thought for now, thinking “hmm, maybe subdomains”.
Create a field in the organizations table which links to the custom email template. The problem is that your IAM product doesn’t really support multiple templates per user, so how are you going to send these emails? Firing up your own service to use AWS Simple Email Service (SES)?
Scrap the IAM product you are using and build all of your identity logic yourself

Eventually you settle on one of these, most likely the first one, and call it victory.

Now your product manager (who’s slowly becoming your work nemesis) comes back to you and says that, actually, what your app really needs is role-based access control (RBAC). So you find yourself wondering:
- Where do you store these roles?
- How do you enforce them?
- Are they per organization or global?
- Should they be configurable or are they fixed?
Your company launches a new feature where users can belong to multiple organizations or workspaces, just like Figma or GitHub. An impending sense of doom settles in:
- How are you going to share these users?
- Do you have to mask the user ID so that different organizations can’t correlate users?
- What about different RBAC roles per org?

This doesn’t even account for: the various vulnerabilities you accidentally introduced while trying to ship as quickly as possible (trust us, they are pretty tough to spot!); the not insignificant user entity reconciliation burden you have now placed on the data science team because you have multiple user tables; and the inability to comply with GDPR and data localization laws that large customers really care about and that will cost you a 7-figure contract.

While this is an overly dramatic narrative, it matches pretty consistently what most companies go through: implementing effective and scalable IAM takes several engineers, several lost deals, false starts and months of development effort. Not to mention long term maintenance as your product features (and your backend architecture) grow exponentially.

Our hope with suborgs is to remove all this undifferentiated complexity and security risk so you can focus on actually implementing the core logic of your app (i.e., the thing you were hired to develop).

Let’s see how this would look if step 0 had been registering with SlashID.

The Solution with SlashID

Now let’s see how this would have gone if you’d started off using SlashID and our suborganizations features.

You need to separate the users of your different customers → This is available out of the box with SlashID suborgs. As a SlashID customer, your company has a SlashID organization, which can have as many child suborgs as you need. Each suborg is independent and fully-featured with authentication and user management, but you still retain control. With just one API call you can spin up a new suborg for each new customer you onboard, each with their own user base.
Your customers have different MFA requirements -> Done! Each suborg has the full suite of SlashID authentication features, including customisable and step-up MFA. You are free to change your individual suborgs’ configuration to suit your customers’ specific needs. By using SlashID you didn’t even need to ship a new feature to close a new deal - it was already there, ready to go.
Your customers want customized templates for authentication emails -> Already done! As above, each suborg has independent configuration, including customizable email and SMS templates, so each one of your customers can have their own branded comms for their end users. Victory is assured.
Role-based access control no longer fills you with fear. Each suborg can have its own set of person groups. SlashID user JWTs have a claim with a user’s groups, and our React SDK has components for conditional rendering and access by group. Or you can use the token claims on your backend to make authorization decisions.
Users shared across multiple organizations? No sense of doom here. By default, each suborg has its own independent user base, with unique IDs per user. However, if you want to add seamless but secure switching between apps, you can do that too: suborgs can be configured to share some information so you get consistent user identity across them.

There you have it - minutes of development work instead of months; well-rested engineers; and you get to stay friends with your product manager.

Jokes aside, we created suborgs after countless conversations with our customers, to respond to the challenges dev teams face when trying to model complex organization structures with their IAM product.

A real world example in 10 minutes or less

Going back to the Trackalot example, how would you implement it with suborgs?

You can also find more examples in our documentation.

Step 1: Create a suborg for each customer

Creating a suborg is a simple API call:

curl -X POST --location 'https://api.slashid.com/organizations/suborganizations' \
--header 'SlashID-OrgID: <ORGANIZATION_ID>' \
--header 'SlashID-API-Key: <API_KEY>' \
--header 'Content-Type: application/json' \
--data '{
    "sub_org_name": "Parks & Rec Dept",
    "groups_org_id": "85637a0a-a574-326a-bac3-d1f46d62dbd9"
}'

In this example we are specifying that the suborg should have the same group pool (groups_org_id) as the parent org - this way
they can share the same RBAC roles.

This is the response, containing the ID and API key of the new suborg:

{
   "result": {
       "api_key": "wY7gDtUDjxGMdynd6BKaaLojHFE=", // API key of the new suborganization
       "id": "97724371-a0a1-4b93-bf51-6ba2feb1acdf", // ID of the new suborganization
       "org_name": "Parks & Rec Dept", // as in the request
       "tenant_name": “Trackalot" // same as for the parent organization
   }
}

Let’s create another one:

curl -X POST --location 'https://api.slashid.com/organizations/suborganizations' \
--header 'SlashID-OrgID: <ORGANIZATION_ID>' \
--header 'SlashID-API-Key: <API_KEY>' \
--header 'Content-Type: application/json' \
--data '{
    "sub_org_name": "Dunder Mifflin Paper Company",
    "groups_org_id": "85637a0a-a574-326a-bac3-d1f46d62dbd9"

}'


{
    "result": {
        "api_key": "FkImXyWgZhuqTGTh70fXzuI1PMo=",
        "id": "d89e29fc-2693-d3b7-764c-debc9561eea2",
        "Org_name": "Dunder Mifflin Paper Company",
        "tenant_name": "Trackalot" // same as for the parent organization
    }
}

We have built the following org structure:

Now that the Parks & Rec Dept and Dunder Mifflin Paper Company are ready, we are one step closer to helping them avoid those 94 meetings a day with Trackalot.

Step 2: Customize authentication policies

You can use the Organization APIs to customize the behavior of suborgs. So for example, you can change the email template used for magic links by the Parks & Rec Dept suborg with the following call:

curl -X POST --location 'https://api.slashid.com/organizations/suborganizations' \
--header 'SlashID-OrgID: 97724371-a0a1-4b93-bf51-6ba2feb1acdf' \
--header 'SlashID-API-Key: wY7gDtUDjxGMdynd6BKaaLojHFE=' \
--header 'Content-Type: application/json' \
--data '{
    "email_authn_challenge": <EMAIL_TEMPLATE>
}'

This won’t impact the template for Dunder Mifflin Paper Company or any other suborg.

Note how problems (2) and (3) from the scenario above are solved with a single API call vs endless coding, scoping and back and forth with your product manager.

Step 3: Create roles for RBAC and assign them to users

Now you have some customers, you can create groups to more easily manage users, starting with employee and admin, using the SlashID groups API:

curl -X POST --location 'https://api.slashid.com/groups' \
--header 'SlashID-OrgID: 85637a0a-a574-326a-bac3-d1f46d62dbd9' \ // "Trackalot" org ID
--header 'SlashID-API-Key: /cgMbOUYjFGMUv4hIvKoMxhVIJ0=' \ // "Trackalot" API key
--header 'Content-Type: application/json' \
--data '{
    "name": "employee"
}'

curl -X POST --location 'https://api.slashid.com/groups' \
--header 'SlashID-OrgID: 85637a0a-a574-326a-bac3-d1f46d62dbd9' \ // "Trackalot" org ID
--header 'SlashID-API-Key: /cgMbOUYjFGMUv4hIvKoMxhVIJ0=' \ // "Trackalot" API key
--header 'Content-Type: application/json' \
--data '{
    "name": "admin"
}'

We used the organization ID for Trackalot to create the groups, and we see that listing the groups for the suborgs returns the expected result:

curl -X GET --location 'https://api.slashid.com/groups' \
--header 'SlashID-OrgID: d89e29fc-2693-d3b7-764c-debc9561eea2' \ // Dunder Mifflin Paper Company org ID
--header 'SlashID-API-Key: FkImXyWgZhuqTGTh70fXzuI1PMo=' // Dunder Mifflin Paper Company API key

{
    "result": [
        "employee",
        "admin"
    ]
}

The same API call with the Parks & Rec organization ID returns the same results, as expected - they share a group pool, so the groups are shared.

curl -X GET --location 'https://api.slashid.com/groups' \
--header 'SlashID-OrgID: 97724371-a0a1-4b93-bf51-6ba2feb1acdf' \ // Parks & Rec Dept org ID
--header 'SlashID-API-Key: wY7gDtUDjxGMdynd6BKaaLojHFE=' // Parks & Rec Dept API key

{
    "result": [
        "employee",
        "admin"
    ]
}

It is outside the scope of this blogpost but with SlashID suborg you have the freedom to not share users or groups pools. See our documentation for a few examples of how to do that.

Step 4: Sharing users

Lastly, if Trackalot takes off and you want to allow end users to be part of multiple organizations, you can also do that easily through our person pools.

By default, suborgs have their own dedicated pool of users, but they can also share users through person pools. This means that if the same person works for both Parks & Recs and Dunder Mifflin, they will have a consistent unique identifier in all suborgs sharing that person pool as long as they use the same handles (email addresses or phone numbers) to register.

You can read more about person pools in our guide.

But it doesn't end there, thanks to our buckets you are also able to share attributes across users and organizations.

Conclusion

In this blogpost we’ve shown how you can use SlashID suborgs to implement complex user structures flexibly and securely, without wasting months of dev time on it and without risking a breach.

Look out for future guides and blog posts, where we will deep dive into more case studies to explore DataVault, attribute-based access control (ABAC), and role-based access control (RBAC).

Have questions or want to find out more? Check out our documentation or reach out to us.

Ready to get started with SlashID? Register here!

Using Google Tink to sign JWTs with ECDSA

vincenzoiozzo — Wed, 22 Feb 2023 11:19:44 +0000

Introduction

In this blog post, we will show how the Tink cryptography library can be used to create, sign, and verify JSON Web Tokens (JWTs), as well as to manage the cryptographic keys for doing so. This is intended as a more practical example to complement Tink’s own documentation on the underlying cryptographic theory and their approach.

At SlashID we are big fan of Tink and use it in a variety of roles, including signing tokens! Read more about it on our blog

Background

We chose Tink because of three core characteristics:

The Tink philosophy of an easy to use API that is difficult to mess up and with safe defaults - we’ll see below how picking the wrong library could make your token service entirely insecure
Key rotation and management out of the box
Tink encryption APIs and integration with KMS makes it easy to protect the signing key

Before we dive into the tutorial, let’s do a brief recap of JWTs.

JSON Web Tokens

JWTs are an industry standard and are widely used in the identity, authentication, and user management space. They are used to transfer information between two parties in a verifiable manner. There are many excellent introductions to JWTs, so for the purposes of this discussion we will focus on the structure.

JWTs are typically transmitted as base-64 encoded strings, and are composed of three parts separated by periods:

A header containing metadata about the token itself
The payload, a JSON-formatted set of claims
A signature that can be used to verify the contents of the payload

For example, this JWT

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvZSBTbGFzaElEIiwiaWF0IjoxNTE2MjM5MDIyfQ.4cL42NsNCXLPEvmvNGxHN3wLuarpp98wwezHnSt2fqg

has the following parts

Part	Encoded value	Decoded value	Description
Header	eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9	{ "alg": "HS256", "typ": "JWT"}	Indicates that this is a JWT and that it was hashed with the HS256 algorithm (HMAC using SHA-256)
Payload	eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvZSBTbGFzaElEIiwiaWF0IjoxNTE2MjM5MDIyfQ	{"sub": "1234567890", "name": "SlashID User", "iat": 1516239022}	Payload with claims about a user and the token
Signature	4cL42NsNCXLPEvmvNGxHN3wLuarpp98wwezHnSt2fqg	N/A	The signature generated using the HS256 algorithm that verifies the payload

The important aspect of this is that the JWT is signed, meaning that the claims in the payload can be verified, if one has access to the appropriate cryptographic key.

The signature of a JWT token is calculated as follows:

signAndhash(base64UrlEncode(header) + '.' + base64UrlEncode(payload))

Where signAndhash is the signing and hashing algorithms specified in the alg header. The JOSE IANA page contains the list of supported algorithms.

In the example above HS256 stands for HMAC using SHA-256 and the secret is a 256-bit key.

Signing is not the same as encryption - even without the cryptographic key for verifying, anybody can decode the token payload and inspect the contents.

The Task: Creating and Verifying Signed JWTs

Suppose we have been tasked with building a system to securely sign and verify JWTs for an authenticated user. We will focus on building a small HTTP server that exposes two endpoints: one for generating a signed JWT based on some user information, and one for verifying an existing JWT. We will use asymmetric keys for this - meaning the key has a private part (for signing) and a public part (for verifying). Examples of asymmetric key algorithms include RSA and ECDSA.

Picking the right algorithm

Before we begin, it’s crucial to understand which signing algorithm to use and what are the pros and cons. As discussed earlier the algorithm used to sign the JWT is specified in the header in the alg field, and there are several options for signing and hashing algorithms.

Let’s start with the hashing algorithm. The most common algorithm for hashing is SHA, and an intuitive way to think about hashing security is that the level of security each one gives you is 50% of their output size. So SHA-256 will provide you with 128-bits of security, and SHA-512 will provide you with 256-bits of security. This means that an attacker will have to generate 2^128 hashes before they start finding collisions. Generally anything above 256-bits is considered acceptable.

When it comes to signing, historically, RS256 (RSASSA-PKCS1-v1_5) RS256 has been the default for most JWT implementations. JWTs signed with RSASSA-PKCS1-v1_5 have a deterministic signature, meaning that the same JWT header & payload will always generate the same signature.

Even though there are no known attacks against RSASSA-PKCS1-v1_5 its usage is discouraged in favor of Elliptic Curves/ECDSA. And in certain cases, like for the UK Open Banking standard, RSASSA-PKCS1-v1_5 is forbidden.

When it comes to ECDSA, the most common choice is ES256 which stands for ECDSA using P-256 (an elliptic curve also known as secp256r1) and SHA-256. ECDSA requires much shorter keys than RSA in terms of strength (you need 3072 bits for an RSA key to have the same strength of P-256) and key generation is faster than RSA even though verification is generally slower.

ECDSA, by default, uses a random nonce that is generated per signature, hence ECDSA-generated signatures are non-deterministic.

The random nonce is key, as reusing the random nonce or having easily-guessable bits in the nonce can make the private key easily recoverable. Two high profile cases of such incidents were Sony's Playstation 3 and Bitcoin. In the Playstation 3 case, the private key was recovered due to a static nonce, and in Bitcoin’s case, Android users were affected due to a bug in Java’s SecureRandom class on Android.

Given the risk, it is key to pick a library that safely implements ECDSA either by using a deterministic scheme as described by RFC 6979 or by implementing the algorithm in a way that doesn’t depend on the quality of the random value - for example, see this thread.

For this blogpost we’ll use ES256. If you are implementing your own signing service, please refer to RFC 8725 for current best practices.

Creating, Signing, and Verifying a JWT

For this blogpost we will use Tink’s Go library, but there are published libraries for several other languages, and the principles are the same.

To begin with, let’s take a look at the Tink documentation on JWTs. There are five types that we are interested in to begin with:

jwt.RawJWT - an unverified JWT
jwt.VerifiedJWT - a JWT that has been verified
jwt.Signer - an interface for signing JWTs
jwt.Verifier - an interface for verifying signed and encoded JWTs
keyset.Handle - the type representing a cryptographic keyset, used to create instances implementing Signer and Verifier

The lifecycle of a JWT is

First, we want to build our RawJWT that will be signed. This includes both the registered claims as described in the JWT specification, and some custom claims:

   jwtID := uuid.New().String()

   now := time.Now()
   expiry := now.Add(tokenDuration)

   opts := &jwt.RawJWTOptions{
       Subject:      &userID,
       Issuer:       &tokenIssuer,
       JWTID:        &jwtID,
       IssuedAt:     &now,
       ExpiresAt:    &expiry,
       NotBefore:    &now,
       CustomClaims: claims,
   }

   rawJWT, err := jwt.NewRawJWT(opts)
   if err != nil {
       return "", fmt.Errorf("failed to create new RawJWT: %w", err)
   }

Now we have our RawJWT, we can sign and encode it. First, we need a Signer implementation.

Note that in the example jwt refers to the Tink jwt package.

   signingKeyset, err := tm.keysetsRepo.GetKeyset()
   if err != nil {
       return "", fmt.Errorf("failed to get token signing keyset: %w", err)
   }

   signer, err := jwt.NewSigner(signingKeyset)
   if err != nil {
       return "", fmt.Errorf("failed to create new Signer: %w", err)
   }

To do this, we have introduced an interface, KeysetsRepo:

type KeysetsRepo interface {
   GetKeyset() (*keyset.Handle, error)
}

Which is the interface to whatever we are using to store the keysets. We will come back to the details of this later - for now, we can simply define the interface, which is a single method for getting a keyset. Once we have that keyset, we can create a new JWT signer.

Not all keysets can be used to create a Signer - the keyset must have been created using one of the templates defined in the JWT library, as discussed below.

Finally, we can sign the token and return the signed token string:

   signedToken, err := signer.SignAndEncode(rawJWT)
   if err != nil {
       return "", fmt.Errorf("failed to sign RawJWT: %w", err)
   }

   return signedToken, nil

So now we have the whole method for signing JWTs with Tink.

Now let’s implement the second part of the lifecycle and verify the token. First, we create a Verifier instance:

   verificationKeyset, err := tm.keysetsRepo.GetPublicKeyset()
   if err != nil {
       return nil, fmt.Errorf("failed to get token verification keyset: %w", err)
   }

   verifier, err := jwt.NewVerifier(verificationKeyset)
   if err != nil {
       return nil, fmt.Errorf("failed to create new Verifier: %w", err)
   }

For this, we have added a new method to the KeysetsRepo interface, GetPublicKeyset:

type KeysetsRepo interface {
   GetKeyset() (*keyset.Handle, error)
   GetPublicKeyset() (*keyset.Handle, error)
}

As we are implementing signing with asymmetric keys, we deal with two keysets - the private one for signing tokens, and the public one for verifying. The former must be stored securely and kept secret, otherwise anyone can sign tokens as if they were you, making token verification meaningless. The latter can be published, for example as part of an OIDC discovery document. In this case we make the separation clear by having two methods in the repo, one for getting the full keyset, and one for getting just the public part.

We also need to define a Validator that the Verifier can use to check the token claims:

   opts := &jwt.ValidatorOpts{
       ExpectedIssuer:        &tokenIssuer,
       IgnoreTypeHeader:      true,
       IgnoreAudiences:       true,
       ExpectIssuedInThePast: true,
   }

   validator, err := jwt.NewValidator(opts)
   if err != nil {
       return nil, fmt.Errorf("failed to create new Validator: %w", err)
   }

We are ignoring some fields in this example to keep it shorter.

Finally, we can decode and verify the token:

   verifiedJWT, err := verifier.VerifyAndDecode(signedToken, validator)
   if err != nil {
       return nil, InvalidTokenError
   }

   return verifiedJWT, nil

Now we have the whole method for verifying JWTs as well.

Storing the Signing Keysets

The next step is to implement our KeysetsRepo, which is the interface between our service and however we are persisting our keysets. Safely persisting our token keysets is essential - if we were to lose them, all existing tokens would need to be invalidated, which could have a significant impact on the user experience for anybody using the service to create and verify tokens.

For this example, we will implement a very simple keysets repo that stores the keys in the local file system. While this would typically not be suitable for large-scale distributed systems, it serves to illustrate the essential points of persisting and retrieving keysets. The keyset will be stored in a single file in the working directory. Before we begin to implement the methods needed for our interface, we will write a method for initializing the keyset, InitTokenKeyset.

type FSKeysetsRepo struct {
   keysetsFilePath string
   masterKey       tink.AEAD
}

func NewFSKeysetsRepo(keysetsFilePath string, masterKey tink.AEAD) *FSKeysetsRepo {
   return &FSKeysetsRepo{
       keysetsFilePath: keysetsFilePath,
       masterKey:       masterKey,
   }
}


func (r *FSKeysetsRepo) InitTokenKeyset() error {
   handle, err := keyset.NewHandle(jwt.ES256Template())
   if err != nil {
       return fmt.Errorf("failed to create new keyset handle with ES256 template: %w", err)
   }

   return r.writeKeysetToFile(handle)
}


func (r *FSKeysetsRepo) writeKeysetToFile(handle *keyset.Handle) error {
   f, err := os.Create(r.keysetsFilePath)
   if err != nil {
       return fmt.Errorf("failed to create keysets file %s: %w", r.keysetsFilePath, err)
   }
   defer f.Close() // unhandled error

   jsonWriter := keyset.NewJSONWriter(f)

   err = handle.Write(jsonWriter, r.masterKey)
   if err != nil {
       return fmt.Errorf("failed to write keyset to file %s: %w", r.keysetsFilePath, err)
   }

   return nil
}

First, we create a new keyset using keyset.NewHandle and the ES256Template from the jwt package. This creates a keyset with the ES256 algorithm, which implements elliptic curve signing with the NIST P-256 curve. As mentioned above, this creates a keyset suitable for creating Signer and Verifier instances. Tink provides many other templates for keysets that cannot be used for signing/verifying, and trying to use one as such will result in a runtime error. The jwt subpackage in Tink lists the available templates.

Once we have the new keyset handle, we can serialize it to JSON and write it to a file.

   jsonWriter := keyset.NewJSONWriter(f)

   err = handle.Write(jsonWriter, r.masterKey)
   if err != nil {
       return fmt.Errorf("failed to write keyset to file %s: %w", r.keysetsFilePath, err)

We create a JSONWriter instance for the file, and then call the keyset handle’s Write method. Note that this takes two arguments - an instance of the Writer implementation, and a tink.AEAD instance, which we have called masterKey. This is the encryption key used to encrypt the keyset before writing it to the file.

Tink provides various other implementations of Writer; we have chosen JSON to be more human-readable, so the keyset files can be inspected.

Now we can create a keyset and securely store it in a local file. We can now return to implementing the methods for the KeysetsRepo interface. First, GetKeyset:

func (r *FSKeysetsRepo) GetKeyset() (*keyset.Handle, error) {
   return r.readKeysetFromFile()
}

func (r *FSKeysetsRepo) readKeysetFromFile() (*keyset.Handle, error) {
   f, err := os.Open(r.keysetsFilePath)
   if err != nil {
       return nil, fmt.Errorf("failed to open keysets file %s: %w", r.keysetsFilePath, err)
   }
   defer f.Close() // unhandled error

   jsonReader := keyset.NewJSONReader(f)

   handle, err := keyset.Read(jsonReader, r.masterKey)
   if err != nil {
       return nil, fmt.Errorf("failed to read keyset as JSON: %w", err)
   }

   return handle, err
}

We will need to re-use the readKeysetFromFile logic later, so we have extracted it to a separate method. Here, we open the file holding the keyset, and create a JSONReader (since we stored the keyset serialized as JSON). Then we use the keyset.Read method to read the keyset from the file and create a keyset.Handle. Note that again the master key is needed, this time to decrypt the keyset.

The GetPublicKeyset method is very similar, with one additional step:

func (r *FSKeysetsRepo) GetPublicKeyset() (*keyset.Handle, error) {
   handle, err := r.readKeysetFromFile()
   if err != nil {
       return nil, err
   }

   publicHandle, err := handle.Public()
   if err != nil {
       return nil, fmt.Errorf("failed to get public keyset: %w", err)
   }

   return publicHandle, nil
}

We get the public part of the keyset only using the handle.Public() method, which returns a new keyset containing only the public part, which we then return.

The API

The last remaining piece of our service is an API that can be used to create and verify tokens. For this example, we will implement a very basic HTTP server exposing two endpoints:

func StartServer(h *APIHandler) error {
   mux := http.NewServeMux()
   mux.HandleFunc("/tokens", h.PostToken)
   mux.HandleFunc("/tokens/verify", h.PostVerifyToken)

   return http.ListenAndServe(":8080", mux)
}

Both endpoints will accept only the POST method. POST /tokens will accept some user information and return a signed and encoded JWT; POST /tokens/verify will accept a signed token and return a boolean indicating whether it is valid.

PostToken can leverage GenerateTokenWithClaims to generate a signed token and PostVerifyToken can leverage VerifyToken to verify a token.

The Master Key

Our service is nearly complete - we have our API, a layer of business logic for managing our tokens, and persistence for our keysets. It’s time to put it all together:

func main() {
   conf := getConfigFromEnv()

   keysetsRepo := NewFSKeysetsRepo(
       conf.keysetsFilePath,
       masterKey,
   )

   tokenManager := NewTinkTokenManager(keysetsRepo)

   apiHandler := NewAPIHandler(tokenManager)

   err := keysetsRepo.InitTokenKeyset()
   if err != nil {
       log.Fatalf("Failed to initialize token keysets")
   }

   err = StartServer(apiHandler)
   if err != nil {
       log.Fatalf("Server encountered an error: %s", err.Error())
   }
}

We will not worry too much about getting the configuration from the environment variables for now - however, we are missing the master key, which we need to construct our keysets repo.

As discussed above, the master key is used to encrypt your signing keysets, and so it is essential that it is kept securely and safely. If you were to lose the master key, all of your signing keysets would become inaccessible and unusable. It is therefore recommended that you store the master key in a secure key management service (KMS). KMSs are offered as features by cloud providers (e.g., GCP, AWS) and so can be integrated as part of your cloud deployment.

For local testing, it is possible to create keysets and store them in plaintext in local files. The example repo contains code for doing this to help you try out the service locally. However, this is not safe for non-testing scenarios!

We will use the GCP KMS as an example:

func getMasterKey(conf *config) tink.AEAD {
   gcpClient, err := gcpkms.NewClientWithOptions(context.Background(), conf.keyURIPrefix)
   if err != nil {
       log.Fatal(err)
   }
   registry.RegisterKMSClient(gcpClient)

   masterKey, err := gcpClient.GetAEAD(conf.masterKeyURI)
   if err != nil {
       log.Fatalf("Failed to retrieve master key: %s", err.Error())
   }

   return masterKey
}

The masterKey we return here implements the tink.AEAD interface for encrypting and decrypting. However, we do not have the master key itself locally - that must be kept safely in the KMS. Instead, the data to be encrypted/decrypted is transmitted to and from the KMS behind the scenes.

Conclusion

In this blogpost, we have laid out the essential steps to get started using Tink with JWTs, including:

Creating Tink keysets for signing and verifying keys
Safely storing these keysets
Using the Signer and Verifier interfaces for JWTs
Using a KMS to store master keys

Our next blogpost in the series will build on this, looking at key management (in particular, key rotation), and taking a deeper dive into the structure of a Tink keyset.

SlashID sign-in/sign-up React components

vincenzoiozzo — Fri, 20 Jan 2023 09:22:04 +0000

Introduction

As mentioned in a previous blog post, we have been working on a set of UI components with the common goal of delivering a streamlined, low friction onboarding experience to our customers. Today we’re happy to announce the next step in that journey and release our sign-up/sign-in form component.

If you are a SlashID customer you can install our @slashid/react package to use the components immediately.

If you are not a customer, you can check out the code in our GitHub repo and we'd love to give you a test account to try it out - just send as an email at hello@slashid.dev or click here.

Features

The authentication form is a drop-in React component available to all our customers through the official SlashID’s React SDK. It supports all the authentication methods that our core SDK offers out of the box:

WebAuthn
Magic link via email or SMS
One-time passwords
Single sign-on

In order to use the component, customers only need to specify the authentication methods they want to use in the configuration object.

Configuration

Configuration is driven by a simple JavaScript object as illustrated below.

This example will result with the component rendering an email input for webauthn and two buttons for the login via SSO providers. The component instantly responds to any changes in the configuration and re-renders the UI, giving you a flexible and powerful platform for no-code experimentation.

The configuration object can be constructed dynamically or can also be fetched from a remote service. This facilitates a convenient way to experiment with the onboarding process and improve the related metrics without deploying any code changes.

Customization

The form is responsive and it will also adapt to dark and light display modes accordingly.

You can apply your own branding through standard CSS variables. This approach is both performant and flexible as it is not locked into a particular library or a build system.
Using documented CSS variables you can customize the following:

Logo
Font family
Color palette

If further customization is required, all the building blocks of this component expose public CSS class names that can be used to select and style the elements in place using CSS.

Text content and i18n

All the text content present in the form can be edited. In order to keep the component as light as possible there’s no built in i18n solution – you can simply pass in the translated strings using the configuration interface and the i18n library you already use.

What’s next

SlashID’s Authentication React components are just a piece of the puzzle as we aim to provide a full user onboarding solution.

More blog posts are coming up on how to improve your onboarding conversion using SlashID so stay tuned!

Fetching Google Groups with SlashID SSO

vincenzoiozzo — Wed, 18 Jan 2023 00:56:40 +0000

Introduction

Using IdP groups to make authorization decisions is very common among organizations. For example, Figma wrote a custom application gateway to protect internal web applications using the IdP groups to drive RBAC.

Whether you are using Gate to make authorization decisions and protect applications, or adopting a different approach, SlashID allows you to retrieve Google Groups for a given user when the user authenticates.

Google doesn’t provide a way to retrieve a user group when a user authenticates via SSO. To overcome this, we use the Google Admin SDK to retrieve the groups the user belongs to. When the user authenticates through SSO with SlashID, the user token will include a structure similar to the following where the oidc_groups are contained:


google: {
  "access_token": "xIh3qoOXAFTaiOma2ZS6eCgP7rJF6iNDzleux+t69h8XktpsbHDKpiuwH2SwDO5/pSfwwn1+GeYZjxYxGbcJHAfiTztUfz3XqiejND4NasfuCGs550d0YSruxuC5yeKN9GUBbap1t/El7db23GlzjdJodp85ZFJsYsF9NTvP7ws4LkaX64s4VvlVWVT4fxOctFjO3oE1iR/oOBD1QCawvPdrLomQYFcXzN0R1UY9mIlDtUvsXh9cT+gAT9vXdjZ+Q9hR/b2QVR/l241AzmZ4VeIbVPQ=",
  "client_id": "32189023109-4332109.apps.googleusercontent.com",
  "expires_at": 1673092551,
  "id_token": "lVddu2HJAGO/VEnyh30vEeYTH169x2r+/X2/kImNUNeyt6lpDJaJMF7TwSDwmTdAf4Sxs6Ul5eTCrIfHk73F8Ec7WUa/bjekZoj7Ee/xPYNmZpjGuTNpcQCwl+MfEbdd
zXPPFoCdZF+CcZxldSOwzLUDYcLgXZ8fpBMg2erIMtqaH5e682GwY7iJD4ySUeTj3JftxQYBYizUUPfueNkbgsh+bC1bUtzMHDjVU53kZFvygjYydThtw8gl7Kw5G3NW
6f9Ch/D/9WnFbyb/Q3eibJeIKnMNrow003l70DefZzRLM2/6mkEd/VEMuGo9ejW2An2zf/vVQSKyxXP6ySNSkU/nrTtkGFS0s/ENsCB6taj12i57JOtzgDiigJayXB8N
KKgWtJmT/ESgLxsH54Mg3AYK91wo53jmfo9ZLPn88muczG96GfAzUMAOM5Drl/MKyPP+WZ+zwJ1gnoRqnxIUrv+WDwkwbbvA2vjkW8Op+gXVkactQCQVQ26GBGDPh7MtbTUSsW6LKb8/3oEMBuSIZQ==",
  "oidc_groups": [
    "test-group@slashid.dev",
    "sso-guide@slashid.dev",
  ],
  "provider": "google",
  "refresh_token": ""
}

Configuring SlashID to retrieve Google groups is a simple four step process:

Configure the Google credentials
Register the credentials with SlashID
Add the credentials to your SlashID organization’s OIDC configuration
Pass requires_groups to the authentication calls

Configuring SlashID to retrieve groups

To retrieve Google groups, we need to create a service account with the https://www.googleapis.com/auth/admin.directory.group.readonly scope. Our developer guide has step by step instructions on how to configure your Google organization.

Once the account is created and you obtain the JSON credentials from GCP, we are ready to configure SlashID to use them. The first step is to add a super_user field to the end of the JSON object with the email address of a super-admin for the Google account. For example:

{
  "type": "service_account",
  "project_id": "your-project-id",
  "private_key_id": "8167c485286f057e06e4a9d17e99ab4913627dbd",
  "private_key": "-----BEGIN PRIVATE KEY-----\nMIIEvgIBADANBgkqhkiG9w0BAQEFAASCBKgwggSkAgEAAoIBAQCiaBGNydTgs0WV\numdNqzt5FlqigilYVk4J2oQqimg6Cnf8Q27ChShgDzUfwMbImm65MRFWD8UbiVGs\nZ9Q36bK53HKPgi07sZtdxuuwx2/CZ24l1q1N3Dpv5pfYzm2Z24pJbzWIF1pvDnmp\nZLA0iEXCnvOUIZ2tZ1sYmC7KH1MAbip7LNa6pJ/3fA1dRW7NWvporqFZCaGNsGwM\n0vNtS6dEwayhh8IFh2tCSARXOP62ji3BppTUItqBoh3mqP5L7iTv9iXTKTcTXb9E\nm5U1Espzc//UbElWashstYksTZYa6yrD7p2Zns2T4xRASL7j33dT5uHzIkvfeRdu\nyPj09W9TAgMBAAECggEASBj3IgDl1lL/oza7QYmwv1KjLd2mySaXQlyVq+UB3DJl\njcHJ2+UNRYe6x7vnA4s7eE9GKPSbRlwxu93kImZHB6fL29WoiwWPuZPjcfk3rhAI\noBernBMWhjLSWldZ5KHHxE3wb9geN4svi3m9l7Sfc4TpEWvS+fYWRNbafrRlPpz0\nQoFDSQy9FqxB7tGhs7insl+N16C8eQyjaysQt/xvk7pUQO6tYpVU1RVKIZlzjesU\nvOx2NfZSktILhB4teFYRQbGU0trPDfXOfj/NEQ1TUrL0gARHjYjalyrPgk2DNzXH\nCEx6ImQEKHLiJ9YeOGWvCkMBOb66kstlSwm6PxDf4QKBgQDXbvFKFmco970Yqg79\nuwJkOA29Wtqz+J9RnQd9WGL2wbFk/NCpqDnmbNM7UQm6nS9fhNkNG2BbBbW1gaYG\n+5sQ6X69ctxSVvfBqeFwwSdDqz6VReyGeQO7pNT51Ze4cW7O3BIKEoxicAgrw5uR\nAIUvHKs+UYtipAt0Y/I5GMdbSQKBgQDA/PGsnVdnPHuaPHbdJcDuXXmglOf9Nhj3\nK/eiMOE7UxeHy4vNDQyNPfhtGe7zyWqbshV2Gi2l9gyOfjt+sRDFpTG27i4Cc9Du\nNJ7EBnBIkoyswJOUmdt6YbmuAKEELZGQB9v94hIPzTpa51qbuyjNFQWVDaj2xPC5\nfmWVCW65uwKBgQDCb0ns0Q1oJzgOo6WGERuWchTMesx6tACuuygAVB51kNlXSOnW\nxZMESeHXXkuGlskjz5XKQ5QScrPOTmYXVUxd1i9iMuFwmzdfHcDvcBTM+Sgxt3tC\n3sOkvp7NoZ4ehJo6rtrFJnp3eZ+WSCQGmc6ad6iCRTyk2WPRN0dtitSaqQKBgENi\nTnQqABGw4auJ/yraetH/228BbztPf0oWlQGRtaMEMUwd+zNeogpTIAHgMzn2Ev5I\nIQw6ucOf9ORwGQ/0fVm1g3VPFsuOat4xi1oAsYX1fZ74Is+ZJTRHGREzcQVHb/Lt\ne5fbLtlLnFuPOmjz4ZwyAd/4hA2d2Du8cXWndHzvAoGBAJyuL43KBer234fD9Giu\nw+1/PR26rSO0rdKLihE2zRn4l/Kv+/UTZxGSLqpNZpGYnxJ0hAJ7J6N5yFFWZwBp\nvPB5yHmzkMVEYjWgNPzt4WjR3AroYJVzykNEPjdKcBCAM9GA+46W5KbBXbfWavE+\namtNmCJjuaiHJJjydyrTSUVB\n-----END PRIVATE KEY-----\n",
  "client_email": "groups-retrieval-guide@your-project-id.iam.gserviceaccount.com",
  "client_id": "104092906165806390865",
  "auth_uri": "https://accounts.google.com/o/oauth2/auth",
  "token_uri": "https://oauth2.googleapis.com/token",
  "auth_provider_x509_cert_url": "https://www.googleapis.com/oauth2/v1/certs",
  "client_x509_cert_url": "https://www.googleapis.com/robot/v1/metadata/x509/groups-retrieval-guide%40your-project-id.iam.gserviceaccount.com",
  "super_user": "user@slashid.dev"
}

With that done, we can add the credentials to SlashID through our external credentials API as shown below.

curl -L -X POST 'https://sandbox.slashid.dev/organizations/config/external-credentials' \
-H 'Content-Type: application/json' \
-H 'Accept: application/json' \
-H 'SlashID-OrgID: <YOUR ORG ID>' \
-H 'SlashID-API-Key: <YOUR API KEY>' \
--data-raw '{
  "extcred_provider": "google",
  "extcred_type": "json_credentials",
  "extcred_label": "group retrieval credential"
  "json_blob": {
    "type": "service_account",
    "project_id": "your-project-id",
    "private_key_id": "8167c485286f057e06e4a9d17e99ab4913627dbd",
    "private_key": "-----BEGIN PRIVATE KEY-----\nMIIEvgIBADANBgkqhkiG9w0BAQEFAASCBKgwggSkAgEAAoIBAQCiaBGNydTgs0WV\numdNqzt5FlqigilYVk4J2oQqimg6Cnf8Q27ChShgDzUfwMbImm65MRFWD8UbiVGs\nZ9Q36bK53HKPgi07sZtdxuuwx2/CZ24l1q1N3Dpv5pfYzm2Z24pJbzWIF1pvDnmp\nZLA0iEXCnvOUIZ2tZ1sYmC7KH1MAbip7LNa6pJ/3fA1dRW7NWvporqFZCaGNsGwM\n0vNtS6dEwayhh8IFh2tCSARXOP62ji3BppTUItqBoh3mqP5L7iTv9iXTKTcTXb9E\nm5U1Espzc//UbElWashstYksTZYa6yrD7p2Zns2T4xRASL7j33dT5uHzIkvfeRdu\nyPj09W9TAgMBAAECggEASBj3IgDl1lL/oza7QYmwv1KjLd2mySaXQlyVq+UB3DJl\njcHJ2+UNRYe6x7vnA4s7eE9GKPSbRlwxu93kImZHB6fL29WoiwWPuZPjcfk3rhAI\noBernBMWhjLSWldZ5KHHxE3wb9geN4svi3m9l7Sfc4TpEWvS+fYWRNbafrRlPpz0\nQoFDSQy9FqxB7tGhs7insl+N16C8eQyjaysQt/xvk7pUQO6tYpVU1RVKIZlzjesU\nvOx2NfZSktILhB4teFYRQbGU0trPDfXOfj/NEQ1TUrL0gARHjYjalyrPgk2DNzXH\nCEx6ImQEKHLiJ9YeOGWvCkMBOb66kstlSwm6PxDf4QKBgQDXbvFKFmco970Yqg79\nuwJkOA29Wtqz+J9RnQd9WGL2wbFk/NCpqDnmbNM7UQm6nS9fhNkNG2BbBbW1gaYG\n+5sQ6X69ctxSVvfBqeFwwSdDqz6VReyGeQO7pNT51Ze4cW7O3BIKEoxicAgrw5uR\nAIUvHKs+UYtipAt0Y/I5GMdbSQKBgQDA/PGsnVdnPHuaPHbdJcDuXXmglOf9Nhj3\nK/eiMOE7UxeHy4vNDQyNPfhtGe7zyWqbshV2Gi2l9gyOfjt+sRDFpTG27i4Cc9Du\nNJ7EBnBIkoyswJOUmdt6YbmuAKEELZGQB9v94hIPzTpa51qbuyjNFQWVDaj2xPC5\nfmWVCW65uwKBgQDCb0ns0Q1oJzgOo6WGERuWchTMesx6tACuuygAVB51kNlXSOnW\nxZMESeHXXkuGlskjz5XKQ5QScrPOTmYXVUxd1i9iMuFwmzdfHcDvcBTM+Sgxt3tC\n3sOkvp7NoZ4ehJo6rtrFJnp3eZ+WSCQGmc6ad6iCRTyk2WPRN0dtitSaqQKBgENi\nTnQqABGw4auJ/yraetH/228BbztPf0oWlQGRtaMEMUwd+zNeogpTIAHgMzn2Ev5I\nIQw6ucOf9ORwGQ/0fVm1g3VPFsuOat4xi1oAsYX1fZ74Is+ZJTRHGREzcQVHb/Lt\ne5fbLtlLnFuPOmjz4ZwyAd/4hA2d2Du8cXWndHzvAoGBAJyuL43KBer234fD9Giu\nw+1/PR26rSO0rdKLihE2zRn4l/Kv+/UTZxGSLqpNZpGYnxJ0hAJ7J6N5yFFWZwBp\nvPB5yHmzkMVEYjWgNPzt4WjR3AroYJVzykNEPjdKcBCAM9GA+46W5KbBXbfWavE+\namtNmCJjuaiHJJjydyrTSUVB\n-----END PRIVATE KEY-----\n",
    "client_email": "groups-retrieval-guide@your-project-id.iam.gserviceaccount.com",
    "client_id": "104092906165806390865",
    "auth_uri": "https://accounts.google.com/o/oauth2/auth",
    "token_uri": "https://oauth2.googleapis.com/token",
    "auth_provider_x509_cert_url": "https://www.googleapis.com/oauth2/v1/certs",
    "client_x509_cert_url": "https://www.googleapis.com/robot/v1/metadata/x509/groups-retrieval-guide%40your-project-id.iam.gserviceaccount.com",
    "super_user": "user@slashid.dev"
  }
}'

The credentials are encrypted using envelope encryption backed by an HSM to keep key material safe.

Configuring OAuth2 credentials

As described in our guide to setup SSO with SlashID, once you obtain a client_id and client_secret for Google you can pass an extra parameter to the API called external_cred which references the service account credentials we created in the previous step.

curl --location --request POST 'https://sandbox.slashid.dev/organizations/sso/oidc/provider-credentials' \
--header 'SlashID-OrgID: <YOUR ORG ID>' \
--header 'SlashID-API-Key: <YOUR API KEY>' \
--header 'Content-Type: application/json' \
--data-raw '{
    "client_id": "<CLIENT ID>",
    "client_secret": "<CLIENT SECRET>",
    "provider": "google",
    "label": "A label for this set of credentials"
    "external_cred": <EXTERNAL_CRED_ID>
}
'

Putting it all together

Now that we have the necessary pieces in place, you can use the requires_groups parameter in your authentication requests. For example:

let user = await sid.id(oid, null, {
  method: 'oidc',
  options: {
    client_id: clientId,
    provider: provider,
    ux_mode: uxMode,
    requires_groups: 'true',
  },
})

The call above will retrieve the Google groups for the user logging in and return them as part of the OIDC token in user.decodedTokenContainer.oidc_tokens.

You are now ready to start using /id to retrieve Google Groups as part of the SSO sign-in flow.

Forem: vincenzoiozzo

Passkeys Adoption Trends: Survey from Large Deployments

Introduction

Who is using passkeys?

Case studies

Yahoo Japan

Mercari

Kayak

Dashlane

UX considerations when implementing passkeys

Conclusion

Remix authentication with SlashID

Meet @slashid/remix

Key Features

Server side rendering (SSR)

Protected Pages

Pre-built log-in & sign-up form

Auth-aware conditional rendering

The SDK in Action

Prerequisites

1. Install @slashid/remix

2. Create SlashID app primitives

3. Configure slashIDRootLoader

4. Wrap your application body with <SlashIDApp>

5. Create your log-in/sign-up page

6. Protecting your pages

Server side

Client side

GDPR Compliance: Consent Management with SlashID

Introduction

Collecting user consents

Reading and writing consents programatically

Conclusion

JWT Implementation Pitfalls, Security Threats, and Our Approach to Mitigate Them

JSON Web Tokens

Naming convention

Anatomy of a JWT-related bug

The "none" Algorithm

"Billion hashes attack"

Brute-forcing or stealing secret keys

Algorithm confusion

Key injection/self-signed JWT

Injecting self-signed JWTs via the jwk parameter

Injecting self-signed JWTs via the jku parameter

Injecting self-signed JWTs via the kid parameter

The SlashID approach

Conclusion

Protecting Exposed APIs: Avoid Data Leaks with SlashID Gate and OPA

How did the Duolingo leak happen?

Introducing Gate

Deploying Gate

Simulating the leaky API

Detecting PII data through Gate

Detecting PII and blocking the request with OPA

Differential policy enforcement for authenticated users

Blocking requests to unknown URLs

Running in monitoring mode

Performance

Conclusion

Authenticate your Shopify customers with SlashID

Drive repeat business, reduce friction

Control UX and branding

One login and user base across all your channels and products

Add workflows and organizations to your Store

Try it out!

Passkeys deep-dive: security and implementations considerations

Table of content

Passkeys 101

What are passkeys?

Why now?

How are credentials shared and stored?

Security and Threat-modeling

Phishing

Stolen Credentials

Server-side

Client-side

Adding credentials

The end of multi-factor authentication (MFA)?

Implementation considerations

Secure key generation

Meet `@slashid/remix`

1. Install `@slashid/remix`

3. Configure `slashIDRootLoader`

4. Wrap your application body with `<SlashIDApp>`