Forem: gao-sun

Logto Cloud is officially launched!

gao-sun — Wed, 26 Jul 2023 11:31:42 +0000

👋 Today, we are more than happy to announce that Logto Cloud is officially launched!

Logto is an Auth0 alternative for building modern customer identity infrastructure with minimal effort, for both your customers and their organizations.

🎉 Join our launch on Product Hunt and support us! We'd love for you to leave us a review as well.

We'd like also invite you to take a look at our new website and explore the features of Logto Cloud.

The evolution of password hashing

gao-sun — Tue, 18 Jul 2023 10:10:17 +0000

Introduction

Password hashing, as the name suggests, is the process of calculating a hash value from a password. The hash value is typically stored in a database, and during the login (sign-in) process, the hash value of the password entered by the user is calculated and compared with the hash value stored in the database. If they match, the user is authenticated.

Before we dive into the evolution of password hashing algorithms, it's important to understand why it's necessary.

Plain text passwords: A major security risk

Imagine being a user of a website where you've registered an account. One day, the website gets hacked, and the database is leaked. If the website stores passwords in plaintext, the hacker can directly access your password. Since many people reuse passwords across multiple websites, the hacker can use this password to gain unauthorized access to your other accounts. The situation becomes even worse if you use the same or a similar password for your email account, as the hacker can reset your password and take over all your associated accounts.

Even without a data breach, in large teams, anyone with database access can see passwords. Compared to other information, passwords are highly sensitive, and you definitely don't want anyone to have access to them.

Storing passwords without hashing is an amateur mistake. Unfortunately, if you search for "password leak plaintext", you'll find that major corporations like Facebook, DailyQuiz, and GoDaddy have all experienced password leaks in plaintext. It's likely that many other companies have made the same error.

Encoding v.s. encryption v.s. hashing

These three terms are often confused, but they are distinct concepts.

Encoding

Encoding is the first thing to exclude for password storage. For example, Base64 is an encoding algorithm that converts binary data into a string of characters:

const data = 'Hello, world!';
const encoded = Buffer.from(data).toString('base64');
console.log(encoded); // SGVsbG8sIHdvcmxkIQ==

Knowing the encoding algorithm allows anyone to decode the encoded string and retrieve the original data:

const encoded = 'SGVsbG8sIHdvcmxkIQ==';
const data = Buffer.from(encoded, 'base64').toString();
console.log(data); // Hello, world!

To hackers, most encoding algorithms are equivalent to plaintext.

Encryption

Before hashing gained popularity, encryption was used to store passwords, such as with AES. Encryption involves using a key (or a pair of keys) to encrypt and decrypt data.

The problem with encryption is evident in the term "decrypt". Encryption is reversible, meaning that if a hacker obtains the key, they can decrypt the password and retrieve the plaintext password.

Hashing

The primary difference between hashing, encoding, and encryption is that hashing is irreversible. Once a password is hashed, it cannot be decrypted back to its original form.

As a website owner, you don't actually need to know the password itself, as long as the user can log in with the correct password. The registration process can be simplified as follows:

User enters the password.
The service uses a hashing algorithm to calculate the hash value of the password.
The service stores the hash value in the database.

When the user logs in, the process is:

User enters the password.
The service uses the same hashing algorithm to calculate the hash value of the password.
The service compares the hash value with the hash value stored in the database.
If the hash values match, the user is authenticated.

Both processes avoid storing passwords in plaintext, and since hashing is irreversible, even if the database is compromised, the hacker can only obtain hash values that appear as random strings.

Hashing algorithms starter pack

Hashing may seem like the perfect solution for password storage, but it's not that simple. To understand why, let's explore the evolution of password hashing algorithms.

MD5

In 1992, Ron Rivest designed the MD5 algorithm, a message-digest algorithm that can calculate a 128-bit hash value from any data. MD5 has been widely used in various fields, including password hashing. For example, the MD5 hash value of "123456" is:

e10adc3949ba59abbe56e057f20f883e

As mentioned earlier, the hash value appears as a random string and is irreversible. Moreover, MD5 is fast and easy to implement, making it the most popular password hashing algorithm.

However, MD5's advantages are also its weaknesses in password hashing. Its speed makes it vulnerable to brute-force attacks. If a hacker possesses a list of common passwords and your personal information, they can calculate the MD5 hash value of each combination and compare them with the hash values in the database. For example, they might combine your birthday with your name or your pet's name.

In the present day, computers are significantly more powerful than before, making it easy to brute force MD5 password hashes.

SHA family

So, why not use a different algorithm that generates longer hash values? The SHA family seems like a good choice. SHA-1 is a hashing algorithm that generates 160-bit hash values, and SHA-2 is a family of hashing algorithms that generate hash values of 224-bit, 256-bit, 384-bit, and 512-bit lengths. Let's see the SHA-256 hash value of "123456":

8d969eef6ecad3c29a3a629280e686cf0c3f5d5a86aff3ca12020c923adc6c92

The SHA-256 hash value is much longer than MD5, and it is also irreversible. However, there's another issue: if you already know the hash value, like the one above, and you see the exact hash value in the database, you know the password is "123456". A hacker can create a list of common passwords and their corresponding hash values, and compare them against the hash values in the database. This list is known as a rainbow table.

Salt

To mitigate rainbow table attacks, the concept of salt was introduced. Salt is a random string that is added to the password before hashing. For example, if the salt is "salt", and you want to use SHA-256 to hash the password "123456" with the salt, instead of simply doing:

sha256('123456');

You would do:

sha256('salt123456'); // 9898410d7f5045bc673db80c1a49b74f088fd7440037d8ce25c7d272a505bce5

As you can see, the result is completely different from hashing without salt. Typically, each user is assigned a random salt during registration, which is stored in the database alongside the hash value. During the login process, the salt is used to calculate the hash value of the entered password, which is then compared to the stored hash value.

Iteration

Despite the addition of salt, the hash value is still susceptible to brute-force attacks as hardware becomes more powerful. To make it harder, iteration (i.e., running the hashing algorithm multiple times) can be introduced. For example, instead of using:

sha256('salt123456');

You could use:

sha256('salt' + sha256('salt123456'));

Increasing the number of iterations makes brute-forcing more difficult. However, this also affects the login process, as it becomes slower. Therefore, a balance between security and performance needs to be struck.

Halftime break

Let's take a break and summarize the characteristics of a good password hashing algorithm:

Irreversible (preimage resistance)
Difficult to brute force
Resistant to rainbow table attacks

As you may have noticed, salt and iteration are necessary to satisfy all these requirements. The issue is that both MD5 and the SHA family were not specifically designed for password hashing; they are widely used for integrity checks (or "message-digest"). As a result, each website may have its own implementation of salt and iteration, making standardization and migration challenging.

Password hashing algorithms

To address this problem, several hashing algorithms have been specifically designed for password hashing. Let's take a look at some of them.

bcrypt

bcrypt is a password hashing algorithm designed by Niels Provos and David Mazières. It is widely used in many programming languages. Here's an example of bcrypt hash value:

$2y$12$wNt7lt/xf8wRJgPU7kK2juGrirhHK4gdb0NiCRdsSoAxqQoNbiluu

Although it appears as another random string, it contains additional information. Let's break it down:

[$2y][$12][$wNt7lt/xf8wRJgPU7kK2ju][GrirhHK4gdb0NiCRdsSoAxqQoNbiluu]

The first section $2y indicates the algorithm, which is 2y.
The second section $12 indicates the number of iterations, which is 12. This means the hashing algorithm will be run 2¹²=4096 times (iterations).
The third section wNt7lt/xf8wRJgPU7kK2ju is the salt.
The last section GrirhHK4gdb0NiCRdsSoAxqQoNbiluu is the hash value.

bcrypt has some limitations:

The maximum length of the password is 72 bytes.
The salt is limited to 16 bytes.
The hash value is limited to 184 bits.

Argon2

Given the debates and limitations of existing password hashing algorithms, a password hashing competition was held in 2015. Skipping the details, let's focus on the winner: Argon2.

Argon2 is a password hashing algorithm designed by Alex Biryukov, Daniel Dinu, and Dmitry Khovratovich. It introduces several new concepts:

Memory-hard: The algorithm is designed to be hard to parallelize, making brute-forcing with GPUs challenging.
Time-hard: The algorithm is designed to be hard to optimize, making brute-forcing with ASICs (Application-specific integrated circuits) difficult.
Side-channel resistant: The algorithm is designed to be resistant to side-channel attacks, such as timing attacks.

There are two main versions of Argon2, Argon2i and Argon2d. Argon2i is the safest against side-channel attacks, while Argon2d provides the highest resistance against GPU cracking attacks.

-- Argon2

Here's an example of an Argon2 hash value:

$argon2i$v=19$m=16,t=2,p=1$YTZ5ZnpXRWN5SlpjMHBDRQ$12oUmJ6xV5bIadzZHkuLTg

Let's break it down:

[$argon2i][$v=19][$m=16,t=2,p=1][$YTZ5ZnpXRWN5SlpjMHBDRQ][$12oUmJ6xV5bIadzZHkuLTg]

The first section $argon2i indicates the algorithm, which is argon2i.
The second section $v=19 indicates the version, which is 19.
The third section $m=16,t=2,p=1 indicates the memory cost, time cost, and parallelism degree, where are 16, 2, and 1.
The fourth section $YTZ5ZnpXRWN5SlpjMHBDRQ is the salt.
The last section $12oUmJ6xV5bIadzZHkuLTg is the hash value.

In Argon2, the maximum length of the password is 2³²-1 bytes, the salt is limited to 2³²-1 bytes, and the hash value is limited to 2³²-1 bytes. This should suffice for most scenarios.

Argon2 is now available in many programming languages, such as node-argon2 for Node.js and argon2-cffi for Python.

Conclusion

Over the years, password hashing algorithms have undergone significant evolution. We owe a debt of gratitude to the security community for their decades of effort in making the internet a safer place. Thanks to their contributions, developers can pay more attention to building better services without worrying about the security of password hashing. While achieving 100% security in a system may be unattainable, we can employ diverse strategies to minimize the associated risks.

If you'd like to avoid the hassle of implementing authentication and authorization, feel free to try Logto for free. We provide secure (we use Argon2!), reliable, and scalable solutions, enabling you to focus on building your product.

Try Logto Cloud today

Why it’s so hard: Things learned from a bad customer support experience

gao-sun — Tue, 04 Jul 2023 04:15:57 +0000

As a company that offers cloud services with a product-led growth (PLG) approach, we deeply understand the importance of providing a smooth self-serve experience to users, especially in a mature market or area. However, a recent experience with a company worth billions of dollars showed a negative example of how even a common and fundamental user requirement can be mishandled.

Background

The requirement was straightforward: we were using an email platform called S and needed to enable HTTPS for our email tracking links.

In 2023, I assumed that using HTTPS was a basic feature, considering that 83.2% of all websites default to the HTTPS protocol. Thanks to industry leaders like Let's Encrypt, obtaining and maintaining trusted SSL/TLS certificates is usually not a blocker, and many products can automatically manage them for you.

In the case of email platform S, before enabling HTTPS, the following prerequisites needed to be met:

Step 1. Enable Link Tracking.

Step 2. Set up a valid branded link in the platform, which involves using a custom domain for link tracking.

Step 3. Set up a valid SSL certificate for that domain.

If you're not familiar with these techniques and terms, don't worry. Just remember that there are three steps involved. According to their documentation, once these steps are completed, you need to contact the support team to enable HTTPS.

A frustrating start: Useless chats

In an effort to be a good customer, I came prepared and initiated an online chat session with the support team. Here's how the conversation began (G represents me, and S represents the support team for platform S; content may be edited for brevity):

🤔️ G: I've set up the proxies and DNS records for SSL link tracking in Cloudflare. Can you help me enable the SSL feature? My branded links are foo.io and bar.io.

🧑‍💻 S: Thank you for reaching S support.

🧑‍💻 S: Please refer to the steps to enable Link Tracking:
…

🤔️ G: I've already done that. I can confirm it works.

🧑‍💻 S: Please refer to the steps to set up the branded link via Cloudflare:
…

🤔️ G: I've already done that, too. I can confirm it works. The only issue is that the links are not using HTTPS. The documentation instructs me to contact support.

🤔️ G: Here's the link I referred to. There's another documentation suggesting the same thing.

🧑‍💻 S: Please refer to the steps to enable Link Tracking and HTTP

🧑‍💻 S: …

🤔️ G: I couldn't find the settings you provided. Here's a screenshot.

🧑‍💻 S: To make sure that it is not a browser issue, can you please use Google Chrome, clear the cache and cookies on Chrome and also try incognito?

🤔️ G: I'm using the latest version of Chrome. Let me try clearing the cache and cookies.

🤔️ G: (After trying) Still no luck.

🧑‍💻 S: Will it be okay with you if I transform this chat session into a ticket?

🤔️ G: Sure.

Several things immediately struck me:

During the live chat, the support engineer didn't understand the real context. The process felt more like "keyword extraction”.
The online support engineer didn't seem trained to handle this particular case.
The online support engineer was referring to an outdated manual that applied to a non-existing (or removed) user interface.
They didn't know which browser I was using (which should be easy to determine from the User-Agent, although not 100% accurate, it would still save time).
Resources were wasted.

“They are not communicating”

The next day, the conversation continued via emails:

🧑‍💻 S: I apologize for the confusion created in our chat session. The UI may have been updated, here’s the steps for enabling HTTPS link tracking:

🧑‍💻 S: (Steps about enabling click tracking only)

🧑‍💻 S: (Three different documentation links to the same topic, which I had already read and followed)

🤔️ G: I've followed all the steps above, and I'm now at the step that says, "Once you have followed the configuration guide for either of these services, please contact S Support to enable SSL click and open tracking for you.”

And after another day:

🧑‍💻 S: I could not confirm your CNAME has been configured as it’s a requirement to complete Step 2.

🤔️ G: The CNAME records were working; otherwise, the Link Branding wouldn't have been verified. The issue is that I followed your documentation, completed both Step 2 and Step 3, but Step 3 removes the CNAME record added in Step 2.

🧑‍💻 S: Please refer to this blog post, I think it might help.

Thankfully, this time a new link appeared. However, to my surprise, the blog post described almost the same steps, and once again, I was stuck at "Contact S Support.”

At this point, despite my intention to be a good customer, I started considering switching to another modern service that valued HTTPS.

So, in an almost desperate mood, I sent an email:

🤔️ G: I’m pretty sure I’ve completed all the steps. In every link you sent me, I got stuck at the last step.

Within an hour, I received a response:

🧑‍💻 S: Thank you for your request to enable HTTPS link branding.

🧑‍💻 S: Please be reminded that you need to…

🧑‍💻 S: This case is being given to senior support agents…

And within another hour:

🧑‍💻 S (senior engineer): I confirm that SSL has been enabled for the requested account as it passed our testing as well. All the links moving further send trough that account will be overwritten in https instead of http.

As I received the response, the ticket has been directly closed. Fin. From this exchange, I learned a few things:

The documentation was chaotic, with several guidelines discussing the same topic in different ways. This chaos also extended to the customer support training, causing confusion and inconsistencies.
The support engineer from the S platform treated the customer as if they were unprepared and didn't bother reading the documentation at the start of the session.
While the senior engineer had the ability to quickly enable HTTPS link branding, the junior engineer did not. There was also a significant gap in how to handle this specific situation between them.
More resources were wasted.

Closing notes

This case alerted us to how a bad user experience can waste resources and lead to customer churn. To summarize:

Enable self-service options as much as possible. This is crucial for freeing up resources to build a better product.
Human customer support is inevitable, but relying solely on "keyword extraction" for support engineers is not an efficient approach. Language models like LLMs are proving to be more effective in this regard.
Maintain a single source of truth for documentation. Don't mix things up, as it will confuse both your customers and teams.
Keep all staff members updated on product changes. Treat it as a necessary step in product development.
Identify users who submit support tickets because they didn't read the documentation or have exhausted all other options.

While it took nearly three days to enable HTTPS link tracking on the S platform, I would like to express my gratitude to our team at Logto. The team made it possible that users can set up their custom domains with Logto-managed TLS certificates within just five minutes.

I hope this article has provided some valuable insights. Subscribe to us if you're interested in more topics about product, security, or identity!

The essential security checklist for user identity

gao-sun — Mon, 03 Jul 2023 13:43:14 +0000

Introduction

Building user identity is a critical component of any application. It enables you to provide personalized experiences, enhance data quality, and improve user retention.

Validating usernames and passwords may seem like the simplest approach, but there are many other aspects to consider. Let's get started!

Infrastructure

Enforce HTTPS

Let's start with the basics. Always enforce the use of HTTPS (Hypertext Transfer Protocol Secure) to encrypt data transmission over the internet. HTTPS ensures that the data exchanged between the user's device and your server remains confidential and tamper-proof.

Setting up HTTPS may seem challenging, but there are many tools and services available to help you:

If you are self-hosting, Let's Encrypt provides free SSL/TLS certificates that can be used to enable HTTPS on your website.
If you are using a cloud provider, such as AWS, Azure, or Google Cloud, you can use their managed services to set up HTTPS.

Don't allow public database access, limited to trusted sources only

Although it may seem basic as well, there have been numerous security breaches due to allowing public access to databases. So it's worth mentioning here.

Always remember to never allow public access to your database. Put your database in a private network and only allow access from trusted sources.

Securely manage private tokens

Private tokens, such as access tokens or API keys, are often used for programmatic authentication and authorization purposes. To manage these tokens securely:

Use short-lived tokens and refresh tokens to minimize the risk of unauthorized access.
Use a secure token storage mechanism, such as a key vault, to protect tokens from unauthorized access.
Regularly rotate tokens to prevent them from being compromised. Some protocols, such as OAuth 2.0, provide a mechanism for token rotation.
Retain control over token revocation in case of a security breach.

Choose a password hash algorithm wisely

If you have experience with password hashing, you may be aware that there are many algorithms available, some of which are no longer considered secure, such as MD5, SHA-1, and SHA-2.

Some common reasons for their insecurity are:

They were not specifically designed for password hashing, and their computational speed is too fast, making brute force attacks easier.
They lack the use of salt, which makes it easier to create rainbow tables for them.
They are susceptible to collision attacks, allowing attackers to generate different passwords with the same hash value.

Industry-standard password hashing algorithms, such as bcrypt and Argon2, have been designed to address these issues. Due to the limited scope of this article, we won't go into detail about them. You can choose a mature library for one of these algorithms in your programming language.

Learn and strictly adhere to open standards

Open standards like OAuth 2.0 and OpenID Connect (OIDC) provide secure and standardized approaches for user authentication and authorization. They have been battle-tested and widely adopted by the industry.

However, implementing them incorrectly can lead to security vulnerabilities, even for large teams with experienced developers. A recent example is the OAuth vulnerability discovered in Expo, a popular framework for building mobile apps. It serves as a good example of how a small mistake can result in a security breach.

Encrypt data at rest

Data at rest, such as stored user information or database backups, should be encrypted using a strong encryption algorithm. This ensures that even if the data is compromised, it cannot be read without the decryption key. Double-check if your cloud provider supports this feature, as it is commonly required for compliance purposes.

Set up firewalls

DDoS (Distributed Denial of Service) attacks, though ancient, remain a significant threat. According to the Cloudflare DDoS threat report for 2022 Q4, the amount of HTTP DDoS attack traffic increased by 79% YoY. Instead of building your own solution, it's a good idea to set up managed firewalls and utilize notifiers to mitigate this risk.

Apps and clients

Improve security level for public clients

Public clients, such as mobile apps or single-page applications, are more susceptible to security vulnerabilities. Even if you provide them, you should treat them as untrusted sources in your security model. For example:

If you are using OAuth 2.0, use Proof Key for Code Exchange (PKCE) to protect against authorization code interception attacks.
Enforce Content Security Policy (CSP) to mitigate certain types of attacks, including Cross-Site Scripting (XSS) and data injection attacks.

Never trust public input data

User input can be a significant source of security vulnerabilities, often overlooked. Some common types of overlooked vulnerabilities are Cross-Site Scripting (XSS) and SQL Injection. Make sure to validate and sanitize all user input data before using it.

Keep track of activities

Maintaining an audit trail of user activities helps in detecting and investigating security incidents. Log and monitor user actions, such as login attempts, password changes, or sensitive operations. Analyzing these logs can provide valuable insights into potential security breaches or suspicious activities.

Implement solid authentication

Implement a strong authentication mechanism to verify the identity of users. As mentioned earlier, consider using secure protocols like OAuth 2.0 or OpenID Connect for authentication. For more information, you can refer to CIAM 101: Authentication, Identity, SSO.

Build solid authorization (e.g., Implement Role-Based Access Control)

In addition to authentication, proper authorization mechanisms should be in place. Implement Role-Based Access Control (RBAC) to ensure that users only have access to the resources and actions they are authorized to perform. For more information, you can refer to CIAM 102: Authorization & Role-based Access Control.

Implement Multi-Factor Authentication (MFA)

Multi-Factor Authentication (MFA) adds an extra layer of security by requiring users to provide one or multiple forms of identification, such as a password and a one-time code sent to their mobile device. Another good example of MFA is when GitHub asks users to enter a one-time code from their mobile app, which is displayed on the webpage, for performing sensitive operations like deleting a repository.

Culture

The advice provided above mostly covers "passive" security measures, which are known before a security incident occurs. However, there are also "active" security measures you can take to improve your overall security posture, which are more effective in the long run.

Educate your team and users about phishing and social engineering

Phishing attacks and social engineering are critical because they can render many of the security measures mentioned above useless. For example, if a user is tricked into giving away their password or clicking on a seemingly innocent cat picture that contains malware, the strength of your password hashing algorithm or firewall rules becomes irrelevant.

Most people find security training boring, and it often is. So, change the way you educate your team and users. For example, you can simulate a phishing email before an actual attacker does and demonstrate how to identify it. You can even offer rewards for reporting the email to the security team.

Set up DevSecOps

In addition to manual security reviews, you can also implement DevSecOps practices to automate security checks. For example, you can set up a CI/CD pipeline to run static code analysis tools like CodeQL and automatically run penetration tests using tools like OWASP ZAP.

Embrace the most strict configuration without impacting user experience

When it comes to security, always opt for the most secure configuration that doesn't negatively impact the user experience. Avoid taking shortcuts or compromising security for convenience. Security should always be a top priority.

As a startup or indie developer, you may feel that you lack the necessary resources to implement these measures. Nevertheless, there are professional security services available that offer free or startup-friendly options. Take the time to review and consider utilizing them.

Conclusion

Security is a complex topic, and it is impossible to cover everything in a single article. We hope that this article has helped you build a stronger sense of security for yourself or your team. If you are building a new app, you may also want to check out Logto, a platform that helps you develop, manage, and secure your product's user identities with minimal effort.

Tackle social login experience: Unlocking the power of convenience

gao-sun — Tue, 27 Jun 2023 12:02:53 +0000

Author: Ran, Product & Design

Most users are big fans of social login (social sign-in) due to its simplicity, convenience, enhanced security, and elimination of password headaches. If you're one of them, you'll be interested to know that there are several factors to consider when implementing social login to ensure an optimal user experience.

In this blog post, we will explore why product authentication chooses social login and discuss ways to enhance its advantages through thoughtful design choices. Additionally, you can experience the seamless social login flow firsthand within Logto's web console.

Unlock Social Login with Logto

Increase conversion: Make 'em say yes

Research shows that social login can significantly boost conversion rates, with an average improvement of 20%-40%.

Less is more, but choose wisely

Facebook, Google, Apple, Twitter, LinkedIn, Microsoft, GitHub... they're the cool kids in town. Adding too many login options can overwhelm users during registration; or make it difficult for them to recall which provider they used during login. It's best to offer a minimum but relevant selection of providers. Typically, two providers are sufficient for most products.

Branding is key, for trust and usability

Adhere to the branding guidelines of social providers to build trust and maintain a polished UI. For instance, Apple Store strictly reviews the usage of the Apple sign-in button. Facebook or Google sign-in buttons should display the user's avatar, username, or email. Google leverages its browser platform to offer a one-tap sign-in pop-up. You can quickly refer to the platform guidelines for Facebook, Google, Apple, Slack.

Get quality data: Personalize like a pro

Social login provides valuable user profile and social relationship data, allowing products to personalize user experiences quickly.

Ask nicely for the info you need

While social providers offer access to users' public profiles (email, username, avatar), be cautious when requesting additional user information during registration for personalizing product experience. Requesting excessive or non-essential private details without a clear purpose may trigger user skepticism. Instead, prioritize a seamless registration process, gradually seeking additional information as users become engaged with your product.

Sync once or forever, you decide

Typically, user information is synced from social platforms during the first login, allowing users to make changes within the app's profile afterward. But if you prefer the product to always utilize the latest profile information from the social provider, you can choose to sync user information during each login.

Retain users: Don't let them slip away

Did you know that 92% of users will ditch a website if they forget their username or password? Social login comes to the rescue, but it might not be enough on its own.

Email and phone options: a backup plan

Not all users prefer social login, as they may have concerns about privacy or desire anonymity. Therefore, it's essential to offer email or phone number-based login methods alongside social login. Even for users who choose social login, acquiring their email or phone number is necessary. This helps prevent any disruptions caused by social providers discontinuing services or being affected by regional policies. It also enables your marketing team to maintain communication with users through emails or SMS for promotions or re-engagement campaigns.

One account, no more confusion

Recently, while attempting to sign in to ChatGPT, I occasionally found myself unsure whether I had used email sign-in or Google sign-in. This confusion resulted in encountering the following interface and necessitated logging out and back in. I have also experienced a similar issue with Pinterest.

Many users prefer to have a single account, except for those seeking multiple free trial periods. However, after accessing the product, users generally don't navigate to the account management page to link accounts since it's too cumbersome.

Therefore, during registration, an automated and seamless account linking process, with the user's consent, can yield the best results. Here's an optimized design approach when requesting a user's email:

If the social provider gives us a trustworthy email that isn't already registered, we automatically link it during registration. Easy peasy!
If the social provider gives us a trustworthy email, but it's already associated with an account, we ask the user if they want to link their existing account or link another one.
If the social provider doesn't provide a reliable email, we kindly request the user to provide one during registration.

Efficiently configure social login

If you're loving this seamless experience and don't want the hassle of developing it yourself, give Logto a try! It's a quick and easy way to integrate social connectors and level up your social login game. We offer preconfigured options for popular social connectors, and you can also create your own social connectors using standard protocols like OAuth 2.0, OIDC, and SAML.

The figure below shows the Logto console for configuring end users' sign-in experience social login. You can easily add or remove social connectors, customize the branding, and set up different sign-in methods.

Configure your social login in minutes

We value your insights and welcome open communication if you have any better suggestions.

Password isn't dying

gao-sun — Fri, 16 Jun 2023 02:43:15 +0000

Introduction

Last year, there were news articles circulating on the internet claiming that big tech companies like Apple, Google, and Microsoft were joining forces to eliminate passwords. Some startups even declared that passwords were obsolete and outdated. After delving into the realm of identity management for months, I began to question the validity and practicality of these claims.

What does a password do?

At first glance, the answer seems obvious: passwords are used for signing in and verifying identities. However, I hold a different viewpoint if you consider the fact that passwords cannot truly verify who you are:

When a user signs in to a website with an email and password, the website has no way of confirming the actual person behind those credentials. It could be a human or even a cat.
Anyone can unlock an iPhone with the correct PIN.

In reality, the purpose of a password is to anonymously prove ownership of something: a user account, a device, or access to a door.

The current “password killers”

The companies mentioned earlier have proposed various "password killers." Many claim to be safer alternatives that eliminate the need for users to remember complex, static passwords during authentication. However, most of these alternatives are not entirely practical for completely removing passwords.

FIDO authentication

FIDO (Fast Identity Online) authentication, as explained in the official documentation, utilizes public key cryptography techniques for registration and sign-in (it's worth noting that WebAuthn is a core component of FIDO2 specifications). On the surface, the process appears appealing:

Simple, right? Unfortunately, there's a significant hurdle in the way: compatibility. When compared to the traditional combination of "identifier and password," FIDO authentication requires:

Websites or apps to support FIDO.
Browsers and/or operating systems to support FIDO.
User devices to have a user-friendly verification mechanism.

Failure to meet any of these requirements renders FIDO authentication unavailable, forcing a fallback to other methods.

Moreover, even if all the conditions are met, what qualifies as a "user-friendly verification mechanism" on a device? Currently, it may involve biometric methods like fingerprint or face recognition, accompanied by a fallback option such as a PIN code, a.k.a. password. In the end, we're brought back to square one.

Technically, it's not a "password killer" but rather a more secure and user-friendly authentication or verification process protected by passwords.

One-time password

Even though the name includes the term “password”, one-time passwords (OTPs) are not traditional passwords because they are dynamic. There are two popular types of OTPs:

Time-based One-Time Password (TOTP): Generated algorithmically using the current time as a source of uniqueness. It's commonly used in Multi-factor Authentication (MFA) or 2FA.
SMS/Email One-Time Password: Generated on the server using random algorithms. In some countries, it has been widely adopted as a primary sign-in method.

TOTPs may not be as widely recognized by name. For example, when a website prompts you to set up MFA and use an app like Google Authenticator or Duo to scan a QR code, you're most likely using TOTP. You may have also noticed that the website often displays a long "recovery code" and advises you to save it as it will only be shown once. Some websites even encourage users to print it on paper. In essence, this recovery code functions like a long password.

As for SMS/Email OTPs, they can be expensive and unreliable:

Building an SMS or email sender from scratch requires setup.
Email senders need to establish a positive "reputation" to improve deliverability, otherwise, the sender may be flagged as spam.
Each country has its own mobile network operators, leading to unpredictable delivery times and notable costs for sending SMS, especially for startups.

Biometrics

The term "biometric" refers to using only biometric methods for online authentication. In fact, there's a fundamental difference when compared to other methods: biometric authentication shifts the original task of "proving ownership of something" to "proving who you are." Due to privacy concerns, biometric methods are primarily employed for local authentication.

Password isn’t perfect, though

As we can see, "password killers" are essentially hiding passwords or using passwords as fallback options. Here's a summary of the advantages of passwords based on our discussion:

Accessibility and compatibility: Passwords can be used in various systems and are accessible to a wide range of users.
Cost-effectiveness and versatility: Password-based authentication are generally cost-effective than other methods and adaptable to different scenarios.
Anonymity and privacy: Passwords allow for anonymous usage and protect user privacy.

But every coin has two sides. While passwords have their advantages, relying solely on them for authentication poses significant vulnerabilities. They can be challenging for end-users to manage, and if website owners fail to follow proper security practices, passwords become easy to compromise. Dangerous security practices include, but are not limited to:

Allowing for weak or leaked passwords.
Lack of enforcing HTTPS for connections.
Use of insecure hashing algorithms.
Failure to adhere strictly to battle-tested standards like OAuth or OpenID Connect (OIDC).
Exposing the database to the public.

Conclusion

I do not intend to undermine any of the authentication methods mentioned above. On the contrary, as I work on building Logto, I have developed a deep respect for these remarkable authentication methods and the individuals behind them.

Nevertheless, achieving 100% security is an unattainable goal. What we can strive for is to reduce the possibility of attacks. One effective approach is to combine password-based authentication with one-time passwords based on the current device or environment, which adds an extra layer of verification and has been widely adopted. By leveraging the strengths of different authentication techniques, we can create a layered approach that provides stronger protection.

In closing, rather than focusing on buzzwords like "password killer" when passwords are not truly being eliminated, it would be more valuable to concentrate on striking a balance between security and user experience. This entails understanding the strengths and limitations of various authentication methods and implementing them in a way that ensures both the security of user data and a seamless user experience.

Simplify Outline authentication with Logto

gao-sun — Wed, 24 May 2023 19:27:51 +0000

Introduction

Logto is an effortless identity solution with all the features you need. It supports various sign-in methods, including username, email, phone number, and popular social sign-ins like Google and GitHub.
Outline serves as a knowledge base for growing teams.

The best part is that both Logto and Outline are open-source. In this article, we will demonstrate how to use Logto as an OpenID Connect (OIDC) identity provider for Outline.

Prerequisites

To get started, make sure you have the following:

A running Logto instance or access to a Logto Cloud account.
An Outline hosting environment with access to environment variables.

Configure Logto

If you are self-hosting Logto, refer to the Logto "Get started" documentation to set up your Logto instance.

Open Logto Console by entering the URL https://cloud.logto.io/ if you are using Logto Cloud, or the endpoint you have set up for self-hosting.

Open Logto Cloud and effortlessly complete the configuration

Next, navigate to the "Applications" tab and click on "Create Application".

In the modal that appears, choose "Traditional Web" and provide an application name, such as "Outline". Then click on "Create Application”.

You will be directed to a tutorial page in Logto. Click on "Skip" at the top-right corner to proceed to the Application details page.

In the "Redirect URIs" section, enter the following value:

[your-outline-origin]/auth/oidc.callback

For example, if you are hosting Outline on http://localhost:3000, the value should be:

http://localhost:3000/auth/oidc.callback

Click on the "Save Changes" button at the bottom. Once successful, keep this page open as it will be useful for the Outline configuration.

Configure Outline

Follow the steps outlined in the Outline hosting guide until you reach the authentication configuration step. Since Outline supports OIDC-compatible authentication providers by default, you can easily find most of the required configuration values on the Logto application details page.

Refer to the following table for the necessary configuration details:

Outline Environment Variable	Logto Display Name
OIDC_CLIENT_ID	App ID
OIDC_CLIENT_SECRET	App Secret
OIDC_AUTH_URI	Authorization Endpoint
OIDC_TOKEN_URI	Token Endpoint
OIDC_USERINFO_URI	Userinfo Endpoint

Here's another table containing additional variables:

Outline Environment Variable	Description
OIDC_USERNAME_CLAIM	Set to username
OIDC_DISPLAY_NAME	Optional - customize as needed
OIDC_SCOPES	Keep default; no need to set

Self-hosted only: Configure email sign-in in Logto

Since Outline requires user email to be provided, you need to configure email sign-in or a social sign-in that provides trustworthy email address, such as Google sign-in.

See Passwordless sign-in by adding connectors to learn more about configuring passwordless sign-in in Logto.

Checkpoint: Test Logto and Outline integration

Start the Outline instance and access its endpoint. You should see a button in the center labeled "Continue with OpenID Connect"; it can be customized by setting the OIDC_DISPLAY_NAME environment variable.

Click on the button, and you will be directed to the Logto sign-in experience.

If everything has been configured correctly, once you complete the sign-in or registration process in Logto, you will be redirected back to Outline. You can then see your personal information displayed in the bottom left corner of the page.

If you encounter any issues during the integration, please don't hesitate to contact us via email at contact@logto.io or join our Discord server!

Try Logto today

Implement ChatGPT plugins user authentication with Logto

gao-sun — Wed, 24 May 2023 19:18:07 +0000

Introduction

Logto is an effortless identity solution with all the features you need. It supports various sign-in methods, including username, email, phone number, and popular social sign-ins like Google and GitHub.
ChatGPT plugins are tools designed specifically for language models, and help ChatGPT access up-to-date information, run computations, or use third-party services.

In this article, we will demonstrate how to use Logto as an OAuth identity provider for ChatGPT plugins. If you're curious about the importance of authentication for your plugins, check out this post: Authentication: The differentiator for ChatGPT plugins.

We want to give a big shoutout to our community member, kAd, for their invaluable help in validating this integration. We are extremely grateful for their efforts, as this tutorial wouldn't have been possible without their assistance. Tc001 also provided meaningful input during the process.

Prerequisites

To get started, make sure you have the following:

A running Logto instance or access to a Logto Cloud account.
A ChatGPT account with developer access for plugins. While ChatGPT plugins are available to all Plus members, you'll still need to join the waitlist to get developer access.

Configure Logto

If you are self-hosting Logto, refer to the Logto "Get started" documentation to set up your Logto instance.

Open Logto Console by entering the URL https://cloud.logto.io/ if you are using Logto Cloud, or the endpoint you have set up for self-hosting.

Open Logto Cloud and effortlessly complete the configuration

Next, navigate to the "Applications" tab and click on "Create Application".

In the modal that appears, choose "Traditional Web" and provide an application name, such as "My ChatGPT plugin." Click on "Create Application.”

You will be directed to a tutorial page in Logto. Click on "Skip" at the top-right corner to proceed to the Application details page.

In the "Redirect URIs" section, enter the following value:

https://chat.openai.com/aip/[your-plugin-id]/oauth/callback

For example, if your plugin ID is foo123, the value should be:

https://chat.openai.com/aip/foo123/oauth/callback

Scroll down to the "Advanced settings" section and enable "Always issue Refresh Token" (this helps ChatGPT maintain the authentication state).

Click on the "Save Changes" button at the bottom. Keep this page open as it will be useful for configuring plugin later.

Configure ChatGPT plugin

Follow the steps outlined in the ChatGPT Plugins documentation until you reach the authentication configuration step. Since ChatGPT plugin supports OAuth authentication providers, you can easily find most of the required configuration values on the Logto application details page.

When setting up your plugin with ChatGPT, you will need to provide your OAuth Client ID and Client Secret. These correspond to the “App ID” and “App Secret” on the Logto page.

For the auth section in the ai-plugin.json, use the following template:

"auth": {
  "type": "oauth",
  "client_url": "[Authorization Endpoint in Logto]",
  "scope": "openid profile email",
  "authorization_url": "[Token Endpoint in Logto]",
  "authorization_content_type": "application/json",
  "verification_tokens": {
    "openai": "Replace_this_string_with_the_verification_token_generated_in_the_ChatGPT_UI"
  }
}

Remember to replace the client_url and authorization_url values with the respective values from Logto. You can find and copy them from the "Advanced settings" section on the Logto application details page.

Checkpoint: Test Logto and ChatGPT plugin integration

The ChatGPT UI will automatically prompt you to install the plugin. Once successful, you will see a dialog with a button that says "Log in with [your plugin name]."

Click on the button, and you will be directed to the Logto sign-in experience.

If everything is configured correctly, once you complete the sign-in or registration process in Logto, you will be redirected back to ChatGPT. From now on, every request sent by ChatGPT to your plugin server will carry the Authorization header, allowing you to decode and verify the token in your API.

And that wraps up our guide on implementing ChatGPT plugins user authentication with Logto. If you encounter any issues during the integration, please don't hesitate to contact us via email at contact@logto.io or join our Discord server!

Try Logto today

Announcing Logto Cloud (Preview) and OSS General Availability

gao-sun — Mon, 20 Mar 2023 10:05:02 +0000

🚀 Logto Cloud (Preview) has launched on Product Hunt. Come and support us!

Hi there,

I’m Gao, one of the creators of Logto. I remember feeling nervous last July - that’s the date we launched the first beta version of Logto OSS.

To our surprise, we had some deep conversations with the community from the outset. We talked about the terrible developer experience of building authentication, even with existing products, and the dramatic costs of current industry leaders. As developers ourselves, we feel you and that's why we started building Logto.

These conversations drove us towards a brighter future. I want to say a big thank you to everyone we connected with during our beta! Only with your help, we can shape the future of identity development together.

Today, we're excited to announce that we've made a significant step forward with Logto: we're officially launching Logto Cloud (Preview) to the public!

I know that most of you got started with Logto through the online demo (huge credit to GitPod) or the docker-compose file. With Logto Cloud (Preview), you can even forget all the operational overheads when developing with Logto. Simply sign in and a new Logto instance will be ready for you. If you're developing locally, the only thing you need to change in your code is the Logto endpoint.

Assuming you are familiar with cloud products, here are some quick answers to frequently asked questions:

What is the pricing model?

We are still finalizing our pricing model, but rest assured that we are working hard to make our product much more affordable than similar offerings currently on the market. We believe it should be more usage-based, rather than charging per seat for a customer-facing scenario.

Logto Cloud will remain free while in preview. We would love to explore the appropriate and sustainable pricing model with you. Feel free to send us an email or schedule a meeting with us.

How will you process data?

We have a strong belief in building trust and maintaining transparency. During the preview period, all Logto data will stay in the Azure West Europe region. See our Privacy Policy for more details if you are interested.

Will you keep data when the preview ends?

Yes. Your tenant will seamlessly transition to Logto Cloud once the preview period ends. You can also request to have your data physically removed at any time if needed. See our Terms of Use for more details.

Will you stop open-source?

No! Open-source is the core of our product and we believe it always will be. We will try our best to align between OSS and Cloud, and make sure you have full confidence that Logto OSS is backing you up.

Invitation
With gratitude, we invite you to enter Logto Cloud via this link. You can find more details about Logto Cloud (Preview) here.

The other role today is the General Availability version of Logto OSS. After multiple rounds of beta versions and release candidates, we are happy to announce the first release version of Logto OSS. Let’s quickly go through the major updates since last July:

A brand new end-user Sign-In Experience with superior customizability on sign-in and sign-up flows.
10+ new connectors, including multiple open-standard connectors, such as OAuth 2.0 and SAML.
Role-Based Access Control that conforms to the NIST model.
Fully customizable translations with 8 languages built-in.
Machine-to-Machine apps and Web Hooks for building programmatic connections between Logto and your services.

We received valuable feedback from our community and have incorporated it into our recent priorities:

Add Single Sign-On (SSO) support to solidly bridge your product with your customers' identities.
Implement Multi-Factor Authentication (MFA) for enhanced security requirements.
Introduce Dynamic Organizations, which unlocks much more business potential for your product while keeping all your customers' identities in a single source of truth.

If you notice anything missing, please do not hesitate to reach out to us by sending an email or joining our Discord server.

We could not have made it this far without the support of our community. Although this is a meaningful milestone for Logto, we believe our journey is just beginning.

Building an identity product is a serious task, so leave the headache to us. We hope you enjoy using Logto, and let's meet on the cloud!

Gao

How to build GitHub sign-in with React and Logto

gao-sun — Wed, 08 Mar 2023 11:53:44 +0000

For our new friends

Logto is a cost-effective open-source alternative to Auth0. It offers OpenId Connect (OIDC) based authentication and authorization, with modern features like passwordless sign-in and role-based access control.

In this article, we will go through the steps to quickly build the GitHub sign-in experience (user authentication) with React and Logto .

Create an application in Logto

In you browser, open a new tab and enter the link of Logto Admin Console.

Once the page is loaded, in the "Get Started" tab, click the "Create" button on the right, and the browser will redirect to the Application tab.

Choose your application type

In the opening modal, select the "Single Page App" option as the application type.

Enter application name

Enter the application name, e.g., "Bookstore," and click "Create Application."

🎉 Ta-da! You just created your first application in Logto. You'll see a congrats page which includes a detailed integration guide. Follow the guide to see what the experience will be in your application.

Integrate Logto SDK

Add Logto SDK as a dependency

npm i @logto/react # or yarn add / pnpm add

Init LogtoClient

Import and use LogtoProvider to provide a Logto context:

import { LogtoProvider, LogtoConfig } from '@logto/react';

const config: LogtoConfig = {
  endpoint: '<your-logto-endpoint>', // E.g. http://localhost:3001
  appId: '<your-application-id>',
};

const App = () => (
  <LogtoProvider config={config}>
    <YourAppContent />
  </LogtoProvider>
);

Note

In the following code snippets, we assume your app is running on http://localhost:3000.

Sign-in flow

The sign-in flow can be simplified as:

Configure Redirect URI

Let's switch to the Application details page of Admin Console in this section. Add a Redirect URI http://localhost:3000/callback and click "Save Changes".

Redirect URI is an OAuth 2.0 concept which implies the location should redirect after authentication.

Implement a sign-in button

We provide two hooks useHandleSignInCallback() and useLogto() which can help you easily manage the authentication flow.

Note

Before calling .signIn(), make sure you have correctly configured Redirect URI in Admin Console.

Go back to your IDE/editor, use the following code to implement the sign-in button:

import { useLogto } from '@logto/react';

const SignIn = () => {
  const { signIn, isAuthenticated } = useLogto();

  if (isAuthenticated) {
    return <div>Signed in</div>;
  }

  return <button onClick={() => signIn('http://localhost:3000/callback')}>Sign In</button>;
};

Handle redirect

We're almost there! In the last step, we use http://localhost:3000/callback as the Redirect URI, and now we need to handle it properly.

First let's create a callback component:

import { useHandleSignInCallback } from '@logto/react';

const Callback = () => {
  const { isLoading } = useHandleSignInCallback(() => {
    // Navigate to root path when finished
  });

  // When it's working in progress
  if (isLoading) {
    return <div>Redirecting...</div>;
  }
};

Finally insert the code below to create a /callback route which does NOT require authentication:

// Assuming react-router
<Route path="/callback" element={<Callback />} />

Test your integration

Open your React app to test if the integration works. When you click the "Sign In" button, the page should be redirected to a Logto sign-in page, and you should be able to create a new account by entering username and password and complete the sign-in process.

Add GitHub connector

To add a social connector, go to the "Connector" tab in the Admin Console, then click on "Social Connectors". From there, click "Add Social Connector".

In the openning modal, select "GitHub" and click "Next".

On the next page, you will see a two-column layout with the README content on the left and configuration on the right.

Feel free to follow the README file in place or read the following section to complete the configuration process. If you follow the in-place guide, you can skip the next section.

Set up GitHub OAuth app

Sign in with GitHub account

Go to the GitHub website and sign in with your GitHub account. You may register a new account if you don't have one.

Create and configure OAuth app

Follow the creating an OAuth App guide, and register a new application.

Name your new OAuth application in Application name and fill up Homepage URL of the app.
You can leave Application description field blank and customize Authorization callback URL as ${your_logto_origin}/callback/${connector_id}. The connector_id can be found on the top bar of the Logto Admin Console connector details page.

Note

If you encounter the error message "The redirect_uri MUST match the registered callback URL for this application." when logging in, try aligning the Authorization Callback URL of your GitHub OAuth App and your Logto App's redirect URL (of course, including the protocol) to resolve the issue.

We suggest not to check the box before Enable Device Flow, or users who sign in with GitHub on mobile devices must confirm the initial sign-in action in the GitHub app. Many GitHub users do not install the GitHub mobile app on their phones, which could block the sign-in flow. Please ignore our suggestion if you are expecting end-users to confirm their sign-in flow. See details of device flow.

Managing OAuth apps

Go to the OAuth Apps page and you can add, edit or delete existing OAuth apps.
You can also find Client ID and generate Client secrets in OAuth app detail pages.

Compose the connector JSON

Let's go back to Logto. Fill out the clientId and clientSecret field with Client ID and Client Secret you've got from OAuth app detail pages mentioned in the previous section.

Here is an example of GitHub connector config JSON.

{
  "clientID": "<your-client-id>",
  "clientSecret": "<your-client-secret>"
}

Config types

Name	Type
clientId	string
clientSecret	string

Save your configuration

Double check you have filled out necessary values in the Logto connector configuration area. Click "Save and Done" (or "Save Changes") and the GitHub connector should be available now.

Enable GitHub connector in Sign-in Experience

Switch to the "Sign-in Experience" tab, then click the "Sign-up and Sign-in" tab.

Note

If it's the first time you enter the tab, you will see a quick introduction about Sign-in Experience and its basic configuration.

Select "None" for the "Sign-up identifier" to provide minimum sign-up effort for GitHub sign-in, which may increase your conversion rate.

In the "Social sign-in" section, add "Add Social Connector" and choose "GitHub". Then you should be able to see a button with text "Continue with GitHub" in the preview section.

Finally, click "Save Changes" on the bottom right corner.

Testing and Validation

Return to your React app. You should now be able to sign in with GitHub. Enjoy!

CIAM 101: Authentication, Identity, SSO

gao-sun — Tue, 07 Feb 2023 07:51:55 +0000

Background

I began the build Logto because I noticed that Identity and Access Management (IAM) had become increasingly complex and expansive over time. The concept of IAM is even large enough to give rise to new concepts, such as WIAM (Workforce IAM) and CIAM (Customer IAM).

While WIAM and CIAM share the same foundation, they have distinct use cases: WIAM is typically used for internal users, while CIAM is used for external customers. Some examples:

WIAM Your company has a unified identity system for employees, thus every one can use the same account to access company resources, such as software subscriptions, cloud computing services, etc.
CIAM Your online bookstore requires a user identity system for customers and sellers. The sign-in experience is a critical part of onboarding, as it is located at the top of the conversion funnel.

Logto started with the CIAM for various reasons (we’ll have another article talking about this). During development, we realized that building a unified understanding across the team would be beneficial before taking our product to the next level. We hope this will also help you gain a better grasp of the IAM landscape.

The original post is on Logto blog.

Let’s get started!

The basics of CIAM

ℹ️ Regardless of their differences, WIAM and CIAM both have the same foundation: authentication and authorization. These two concepts are at the core of their features.

In this article, we'll focus on the fundamental concepts of CIAM and problems we may meet during or after the authentication flow. We’ll also discuss Single Sign-On (SSO) and its related scenarios.

Authentication and authorization

Definition

Authentication (AuthN) answers the question “Who are you?”

Authorization (AuthZ) answers the question “What can you do?”

If you discover something that does not fit into either of these two categories, it is likely not essential to the identity business.

Examples for authentication
- Password sign-in, passwordless sign-in, social sign-in, etc.
- Machine-to-Machine authentication
Examples for authorization
- Role-based Access Control
- Attribute-based Access Control
Examples for exceptions
- Non-identity data
- Web hooks

Identity and Tenant

Identity typically represents either a user or a machine. Upon successful authentication, an ID Token is issued as an Identity.

In other words, the main purpose of authentication is to obtain an Identity.

A Tenant is a group of identities:

When we discuss "Multi-tenant", we are referring to multiple Logto instances that are identity-isolated from one another. In other words, multiple Logto instances.

Note it has two isolated identity systems, i.e. you cannot use the Identity of Tenant 1 in Tenant 2, even for the same identifier (email, phone, etc.). It's like your Costco membership not being valid at Whole Foods.

🧱 In short, there are “physical walls” between Tenants.

ℹ️ The definition of "Tenant" varies across CIAM products. Some refer to the term "Organization" in Logto, which will be introduced later.

App and Tenant

Just like Identity, an App also belongs to a Tenant. Several things to remember:

There is typically no direct relationship between an App and an Identity.
- An Identity can represent an App, but there is no direct connection between them.
Like users, apps are also Tenant-level.
Apps are code, while users are human.
The sole purpose of Apps are to complete authentication, i.e. to obtain an Identity.

Identity Provider (IdP) and Service Provider (SP)

The difference between these two providers is tricky but important.

Identity Provider is a service that provides authentication (AuthN) and issues identities.

You can find various explanations about Service Provider from Google, though they may not be satisfactory. In my mind, Service Provider is a relative concept:

Service Provider (or Relying Party in OIDC) is a service or client that initiates authentication (AuthN) and requests the result from Identity Providers.

Quiz

Consider a typical social sign-in scenario:

❓ How many Service Providers and Identity Providers in this graph?

Answer

Both have two.

iOS App is a service provider to Logto, while Logto is an identity provider.

Logto is also a service provider to GitHub, while GitHub is an identity provider.

Thus, Logto is a Service Provider also a Identity Provider.

Case study: A tech solution company

You are a CTO of a tech solution company, you have over 100 business partners and you have delivered over 300 projects.

Each project is either a web app or a mobile app with a backend service.
For each business partner, you want to refactor the user system to provide SSO across its projects.

❓ How can Logto (or a CIAM product) help?

Answer

Create a Logto instance for each business partner. Each partner holds a Tenant. Projects are mapped to "Apps" in Logto.

Logto offers a universal sign-in experience (i.e. SSO) within a Tenant, so users don’t need to sign in again when accessing another app in the same Tenant if they already signed in.

What we talk about when we talk about SSO

We found the term “SSO” often causes confusion. We consider Single Sign-On(In) to be a behavior, not a business concept. Therefore, SSO does not equate to “SSO in WIAM”.

When we say “it needs SSO”, it can refer to one of the following cases:

SSO Case 1

👉🏽 In a big corp, employees use the same credentials to sign in to all company-licensed resources (e.g. email, IM, cloud services).

It is the typical WIAM scenario. In this case, only one Identity Provider is involved. We don’t care for now.

SSO Case 2

👉🏽 End-users use the same credentials to sign in to all services developed by the same company (e.g. GSuite).

Logto is currently focusing on the approach outlined above. Multiple external identity providers, such as a third-party social sign-in provider, may exist independently and without connection.

Despite this, Logto remains the single source of truth for Identities, simply "borrowing" them from other providers. In this case, Logto acts as both an Identity Provider (to GSuite apps) and a Service Provider (to external Identity Providers).

SSO Case 3

👉🏽 End-users can only use the specific Identity Provider within the corresponding email domain to complete authentication. For example, signing in to Figma with Google Workspace.

This is the most common use case for SSO in CIAM. Let’s take a closer look.

If we want to sign in to Figma using our @silverhand.io email, we can use either Social sign-in or SSO. The figures below illustrate the difference between the two:

![Image](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/k1iyu55jaxzp9a7ljsen.png)

In words:

After social sign-in, users are free to set a password or change the email address in Figma
After SSO, users cannot set password or change any personal info including email address, since their Identities are managed by Google Workspace

In this case, Logto is both an Identity Provider and a Service Provider. It appears that SSO is more complex than a normal sign-in process. What are the benefits for the identity owner?

Centralized control: Keep identity information and authentication processes in one place, and ensure user information is always up-to-date. There is no need to add and remove licenses across different applications for changes.
Improved user experience: Identity owners who require SSO are usually corporations. Their employees can use the same credentials and shared session for cross-company applications, such as Figma, Zoom, Slack, etc.
Enhanced security: You may have noticed that some corporations require specific sign-in methods, such as dynamic verification codes. Using SSO can ensure that every employee uses the same sign-in method combination for accessing all resources.

🤔 Smart like you must have noticed that this is actually SSO Case 1 from the SaaS perspective.

It’s time to discuss the "X" in the SSO graph. This represents the process of Figma connecting the email domain to a specific Identity Provider. But, how does it work?

SSO mapping

Since the request often comes from enterprise clients, we refer to the process of "SSO Case 3" from the previous section as "Enterprise SSO" for clarity.

We can easily devise a naive solution: create a mapping between email domains and SSO methods, then manually update it.

The action of process “X” is now clear:

🔍 Find the mapped Enterprise SSO method of the given email domain

Thus, if you configure silverhand.io as a valid email domain that connects with a Google Workspace SSO URL, users who try to sign in with an @silverhand.io email will be redirected to the corresponding Google Workspace sign-in page, instead of being processed in-place.

When you only have a few dozen clients that need Enterprise SSO, manually managing the mapping is okay. However, there are more considerations to take into account:

What if there are hundreds or thousands Enterprise SSO clients?
What’s the relationship between “normal users” and “Enterprise SSO users”?
Should data be isolated between different Enterprise SSO clients?
Is there a need to provide a dashboard for the Enterprise SSO admins to view active users, audit logs, etc.?
How can accounts be automatically deactivated when a user is removed from the Enterprise SSO Identity Provider?

And a lot more. Since almost all Enterprise SSO are email-domain-based, we can quickly figure out a better solution:

If the user can prove ownership of that domain, they can set up the enterprise SSO of that domain in a self-serve manner.

This solution addresses the first two questions:

1. What if there are hundreds or thousands Enterprise SSO clients?

They can configure Enterprise SSO in a self-serve way.

2. What’s the relationship between “normal users” and “Enterprise SSO users”?

We open all possible sign-in methods to normal users except Enterprise SSO; While we limit the sign-in method to Enterprise SSO only to the users who are trying to sign in with the configured domains.

As for the third question:

3. Should I isolate data between different Enterprise SSO clients?

Yes and no. It‘s time to introduce organization.

Organization

We mentioned using email domains to recognize the specific Enterprise SSO method to use; in other words, applying a specific treatment for a specific batch of users.

However, the client requirements are often more than just Enterprise SSO; for example, questions 4 and 5 in the previous section. Over the years, a mature model have been developed by outstanding SaaS companies to address these kinds of problems: Organizations.

Organizations rules

An organization is a group of identities, typically smaller than a Tenant.
All organizations are associated with a Tenant.

You may see other terms, such as "Workspace", “Team”, or even "Tenant" in the software. To identify if it is the concept we are discussing, just check if it represents “a group of Identities”.

In this article, we will use the term "Organization" for consistency.

🤹🏽‍♀️ In most cases, "a group of Identities" is equivalent to "a group of users". However, the same Identity can exist in multiple Organizations.

In Notion, you can create and join multiple workspaces (i.e. Organizations) with the same email address and switch between them easily.

For Slack, it appears to be the same, but we suspect it uses different Identities behind the scenes since we need to create a new account for each workspace.

![Image](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/tl8dpac8pwnim6muwcor.png)

Notion has a “Personal Plan” available, which is normally an Organization under the hood, with the sole user (you) inside. We don't know the exact implementation of Notion, but this explanation is reasonable and archivable for our model.

Each Organization also has an identifier, usually referred to as the “Organization domain”.

ℹ️ An "Organization domain" is an internal identifier used to distinguish Organizations. It may differ from the "email domain", as the former is managed by the Service Provider, while the latter is usually provided by an external Identity Provider.

For example, you can use foo as the Organization domain in Slack, but use @bar.io as the email domain for this Organization.

Quiz

❓ Can an app be associated with an Organization?

Answer

Yes yes. As we discussed in the beginning, an app can have an Identity. Can you elaborate a business scenario of this?

Questions remain

3. Should data be isolated between different Enterprise SSO clients?

Yes: Isolate business data, such as messages and documents, at the Organization level.
No: Keep Identities independent, since they do not need to be associated with an Organization.
Note there are three distinct entities involved here: Identities, Organizations, and Enterprise SSO configurations; which notably increased the complexity. The question itself is not specific enough.

4. Is there a need to provide a dashboard for the Enterprise SSO admins to view active users, audit logs, etc.?

5. How to automatically deactivate account when user is removed for the Enterprise SSO Identity Provider?

These demands are more business-oriented and can be implemented at Organization level. We'll leave them open here.

Closing notes

We've introduced several concepts: Authentication (AuthN), Authorization (AuthZ), Identity, Tenant, Application, Identity Provider (IdP), Service Provider (SP), Single Sign-On (SSO), and Enterprise SSO (Organization). It may take some time to understand them all.

As I wrote this article, I noticed that interestingly, the most expensive plans of online services often include exclusive features related to authorization, which is totally unmentioned in this article. You may already have some questions about authorization, such as:

How can we assign permissions to a user and verify them?
What authorization model should I use?
What is the best practice for applying an authorization model?

🔥 Take a break, and see you in CIAM 102!

Logto v1.0.0-rc.0: User auth with RBAC

gao-sun — Fri, 03 Feb 2023 10:08:26 +0000

Logto is an open-source auth solution with comprehensive features and modern dev experience.

Please welcome our first release candidate! Logto is just a few steps away from general availability.

🔒 Role-Based Access Control

We are excited to introduce our latest addition to our product, Role-Based Access Control (RBAC). This powerful feature gives administrators the ability to assign specific roles and permissions to users, ensuring they only have access to the resources and functions they need to do their job.

With RBAC, administrators can:

Define permissions across APIs
Create custom roles with specific permissions
Assign roles to users and manage their roles
Easily manage and update permissions
Securely validate permissions to protect APIs

Logto takes a major step forward in security and control with easy access management and authorization of sensitive info, ensuring only authorized users have the right to access. This aligns with our vision to provide an open-source identity solution with features for authentication and authorization, and packed with all the features you need.

Note
If you are using Logto SDKs, please upgrade to the latest version to take advantage of RBAC.

Check out our RBAC recipe for a step-by-step guide. Give it a try and let us know what you think!

🏄 Streamlined social sign-in flow

💡 Logto now detects a trusted email (or phone number) from the social account during social sign-in.

If the email (or phone number) has been registered: Automatically connect the social identity to the existing user account with a single click.
If the email (or phone number) is not registered: Automatically sync the user profile with the social-provided email (or phone number) if and only if it is marked as a required user profile.

🔢 Send and verify verification codes via Management API

The new Management APIs allow you to reuse connectors to dynamically send and verify verification codes for various purposes, such as validating identity before a user updates their profile or performs a dangerous action.

Call /api/verification-code to send verification code to a given email or phone
Call /api/verification-code/verify to verify the code against a given email or phone

↩️ Rollback database alteration state

In case of any issues with the database, you can now use the logto db alteration rollback [target] command to roll back all database schemas to a previous version, for example logto db alteration rollback v1.0.0-beta.19.