> For the complete documentation index, see [llms.txt](https://docs.devarmor.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.devarmor.com/getting-started/single-sign-on-sso-authentication.md).

# Single Sign-On (SSO) Authentication

DevArmor supports **social authentication** and **Single Sign-On** through enterprise identity providers, allowing users to sign in securely using their existing accounts.

Currently supported providers:

* Google
* Microsoft
* Okta

This allows organizations to simplify user access while leveraging their existing identity and access management policies.

| Provider  | Authentication Method                   |
| --------- | --------------------------------------- |
| Google    | OAuth 2.0 (Google Sign-In)              |
| Microsoft | OAuth 2.0 / Microsoft Identity Platform |
| Okta      | OIDC                                    |

Users can authenticate using their **existing Google Workspace or Microsoft accounts** without needing to create a separate DevArmor password.

## How Users Sign In

1. Navigate to the **DevArmor login page:** [**https://app.devarmor.com/sign-in**](https://app.devarmor.com/sign-in)
2. Select one of the available sign-in options:
   * **Sign-in with Google**
   * **Sign-in with Microsoft**
3. Authenticate with your identity provider
4. After successful authentication, you will be redirected to DevArmor

If it is the user’s first time signing in, reach out to <support@devarmor.com> to request a new account to be created. Alternatively, contact your organization's admin and they will be able to create an account for you on DevArmor platform.

## Admin Guidance for Organizations

Organizations using **Google Workspace** or **Microsoft Entra ID (Azure AD)** can allow their users to sign in with their existing accounts.

Recommended best practices:

* Require employees to use their **corporate Google or Microsoft accounts**
* Enforce authentication policies through your identity provider (MFA, device policies, etc.)
* Disable personal email domains if your organization restricts them

Authentication policies (such as MFA requirements) are controlled **directly within your identity provider**.

## Troubleshooting Login Issues

#### User cannot log in

Verify the following:

* The user is signing in with the correct **Google or Microsoft account**. Specifically, make sure they are using the same email address (including domain) as registered in DevArmor.
* The browser allows authentication redirects
* The user has permission to access DevArmor within your organization.

#### Account created with the wrong provider

If a user accidentally signs up using a different authentication provider (for example Google instead of Microsoft):

1. Contact your DevArmor administrator
2. The admin can update the account or merge identities if needed

#### Authentication fails during login

Common causes include:

* Browser extensions blocking redirects
* Expired identity provider sessions
* Organization-level login restrictions

Recommended fixes:

* Try logging in again
* Use a private browser window
* Clear browser cookies for Google or Microsoft authentication

## Security Considerations

DevArmor does **not store user passwords** when using social authentication.

Authentication security is handled by the identity provider:

* **Google** authentication is managed by Google Identity Services
* **Microsoft** authentication is managed by Microsoft Identity Platform

Organizations should configure security policies (such as **multi-factor authentication**) directly within their identity provider.

## Support

If your team encounters authentication issues, contact:

**DevArmor Support:** <support@devarmor.com>

Include the following information when reporting issues:

* User email address
* Identity provider used (Google or Microsoft)
* Timestamp of the login attempt
* Screenshot of any error messages