Add OIDC SSO documentation and restructure SSO pages

docs/tagoio/tagorun/single-sign-on-sso/_category_.json

@@ -0,0 +1,5 @@
+{
+  "label": "Single Sign-On (SSO)",
+  "position": 3,
+  "collapsed": true
+}

docs/tagoio/tagorun/single-sign-on-sso/index.md

@@ -0,0 +1,52 @@
+---
+title: "Single Sign-On (SSO)"
+description: "Learn how Single Sign-On (SSO) works in TagoIO RUN, compare SAML and OIDC protocols, and find setup guides for your identity provider."
+tags: ["tagoio"]
+keywords: [tagoio, iot, tagorun, sso, single sign-on, authentication, saml, oidc]
+sidebar_position: 1
+---
+
+With Single Sign-On (SSO), your users can sign in to a RUN application using credentials from their existing identity provider (IdP) instead of separate RUN credentials. RUN supports two SSO protocols: **SAML** and **OIDC**. You can use providers such as Okta, Auth0, Microsoft Azure AD, AWS Cognito, Google Workspace, and others.
+
+![TagoIO SSO integrated with 3rd-party services](/docs_imagem/tagoio/single-sign-on-sso-2.png)
+
+## Overview
+
+SSO lets your RUN application delegate authentication to an external identity provider. Your users keep one set of credentials across multiple services, and you get centralized access control without managing passwords inside RUN.
+
+RUN offers two protocols for SSO. Choose the one that best fits your identity provider and your organization's setup.
+
+## SAML vs OIDC
+
+[**SAML**](./saml-sso.md) is an established enterprise standard supported by most identity providers. If your organization already uses SAML for other applications, this is likely the fastest path to get SSO working.
+
+[**OIDC**](./oidc-sso.md) (OpenID Connect) is a more recent protocol built on OAuth 2.0. RUN makes OIDC simpler to configure, with built-in claim mappings and auto-generated callback URLs that reduce the back-and-forth between RUN and your IdP.
+
+Both protocols achieve the same result: your users sign in through the IdP, and RUN receives the identity information it needs.
+
+:::note
+You cannot have both SAML and OIDC active at the same time. Enabling one will disable the other.
+:::
+
+## Plan requirements
+
+SSO is available on **Scale plans** only.
+
+## How it works
+
+Whichever protocol you choose, the setup follows a similar pattern:
+
+1. **Configure an application on your Identity Provider.** Create a SAML or OIDC application in your IdP and obtain the required credentials.
+2. **Manage users and permissions on the IdP side.** Set up which users and groups have access to your RUN application.
+3. **Import the IdP configuration into RUN.** Enter the provider details in the corresponding SSO settings page.
+4. **Complete the integration.** Register any required URLs (such as callback or metadata URLs) back in your IdP.
+
+Once enabled, only users registered in the IdP and granted permission to access the application can sign in to RUN with their IdP credentials.
+
+## RUN users and mappings
+
+When a user signs in through SSO for the first time, RUN automatically creates a new RUN user with the tag `source: sso`. This applies to both SAML and OIDC.
+
+You can use this tag to identify which RUN users were created through SSO, filter them in the user list, or set up automations. For example, you can create a [Trigger by Resource](/docs/tagoio/actions/trigger-by-resource) action that runs whenever a new RUN user is created with the `source: sso` tag.
+
+Mapping values are automatically updated every time a user signs in. If you change a claim or attribute value on the IdP side (for example, updating a user's name), the RUN user will reflect the new value on their next login.

docs/tagoio/tagorun/single-sign-on-sso/oidc-sso.md

@@ -0,0 +1,65 @@
+---
+title: "OIDC SSO"
+description: "Configure OpenID Connect (OIDC) Single Sign-On for your TagoIO RUN application, including issuer URL, client credentials, scopes, and claim mappings."
+tags: ["tagoio"]
+keywords: [tagoio, iot, tagorun, sso, oidc, openid connect, auth0, okta, azure ad, cognito]
+sidebar_position: 3
+---
+
+OIDC SSO lets your users sign in to a RUN application through any OpenID Connect-compatible identity provider. You can configure it in **RUN Settings > Integrations > SSO OIDC**.
+
+## Supported providers
+
+You can use any OpenID Connect-compatible provider, including Auth0, Okta, AWS Cognito, Microsoft Azure AD, and Google Workspace.
+
+## Setup process
+
+The configuration steps vary depending on your identity provider, but the overall process is similar. For a step-by-step walkthrough using Auth0, see the [Auth0 OIDC SSO setup guide on the TagoIO Community](https://community.tago.io/t/how-to-set-up-oidc-single-sign-on-on-tagoio-with-auth0). If you are using a different provider, the Auth0 guide is still a useful reference since the steps are often comparable.
+
+Setting up OIDC SSO involves four steps:
+
+1. **Configure an OIDC application on your Identity Provider.** Create an OAuth 2.0 / OpenID Connect application in your IdP and obtain the Issuer URL, Client ID, and Client Secret.
+2. **Manage users and permissions on the IdP side.** Set up which users and groups have access to your RUN application.
+3. **Import the IdP configuration into RUN.** Fill in the Provider Settings form and configure the Claim Mappings (see sections below).
+4. **Register the Callback and Logout Redirect URLs.** Copy the auto-generated URLs from RUN and add them to your IdP's allowed callback and redirect settings.
+
+## Configuration fields
+
+When you open the SSO OIDC settings in RUN, you will see the following fields:
+
+| Field                    | Description                                                                                                                                                                                                                   |
+| ------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| **Issuer URL**           | The OpenID Connect discovery URL from your IdP (e.g., `https://dev-xxx.us.auth0.com`). Where you find this varies by provider. In Auth0 it is under Application Settings; in Okta it is in the Authorization Server metadata. |
+| **Client ID**            | The application identifier from your IdP.                                                                                                                                                                                     |
+| **Client Secret**        | The secret key from your IdP. RUN stores this value encrypted.                                                                                                                                                                |
+| **Scopes**               | The OpenID Connect scopes to request. Default: `openid profile email`.                                                                                                                                                        |
+| **Callback URLs**        | Auto-generated by RUN. Copy these and register them in your IdP as allowed callback URLs.                                                                                                                                     |
+| **Logout Redirect URLs** | Auto-generated by RUN. Copy these and register them in your IdP as allowed logout redirect URLs.                                                                                                                              |
+
+## Claim mappings
+
+RUN maps attributes from your identity provider to RUN user fields. Two mappings are required:
+
+- **E-mail** (required)
+- **First Name** (required)
+- **Last Name**
+
+Most providers send these by default with the `openid profile email` scopes. If your IdP uses non-standard claim names, you can adjust the mapping for each field.
+
+To map additional IdP claims, click **Edit other claim mappings**. Custom claim values are stored as tags on the RUN user, which you can then use for access management and other features within your application.
+
+## Passing query parameters to your IdP
+
+Some identity providers support additional features through query parameters, such as invite links or custom login hints. RUN forwards any query parameters from your application URL to the IdP during the authentication flow.
+
+For example, if your provider supports invite codes, you can share a link like:
+
+```
+https://myapp.tago.run/login?invite=INVITECODE
+```
+
+RUN will pass the `invite` parameter along to the IdP. Check your provider's documentation for the specific query parameters it supports.
+
+## Enable or disable OIDC SSO
+
+Use the **Enabled** toggle at the top of the SSO OIDC settings page to activate or deactivate OIDC SSO. Click **Save** to apply your changes.

docs/tagoio/tagorun/single-sign-on-sso/saml-sso.md

@@ -0,0 +1,24 @@
+---
+title: "SAML SSO"
+description: "Configure SAML-based Single Sign-On for your TagoIO RUN application using Auth0, Okta, or another SAML-compatible identity provider."
+tags: ["tagoio"]
+keywords: [tagoio, iot, tagorun, sso, saml, auth0, okta, identity provider]
+sidebar_position: 2
+---
+
+SAML SSO lets your users authenticate with a RUN application through a SAML-compatible identity provider. You can configure it in **RUN Settings > Integrations > SSO SAML**.
+
+## Supported providers
+
+You can use any SAML 2.0-compatible identity provider, including Okta, Auth0, Microsoft Azure AD, OneLogin, PingIdentity, and Google Workspace.
+
+## Configuration guide
+
+The configuration steps vary depending on your identity provider, but the overall process is similar across providers:
+
+1. Create a SAML application in your IdP and configure the required settings (such as the Assertion Consumer Service URL and Entity ID provided by RUN).
+2. Add and manage users on the IdP side, including group membership and permissions.
+3. Import the IdP metadata or configuration details into RUN under **SSO SAML** settings.
+4. Enable SSO and verify that your users can sign in through the IdP.
+
+For a step-by-step walkthrough, see the [Auth0 SSO setup guide on the TagoIO Community](https://community.tago.io/t/how-to-set-up-single-sign-on-sso-on-tagorun-with-auth0/1727). If you are using a different provider, the Auth0 guide is still a useful reference since the steps are often comparable.