From 107ce51b48a25320f04e926188940dad8291c195 Mon Sep 17 00:00:00 2001 From: "Alexander \"PapaTutuWawa" Date: Thu, 22 Jun 2023 21:21:22 +0200 Subject: [PATCH] feat: Write down ideas for a SSO spec --- README.md | 1 + xep-xxxx-sso-login.md | 135 ++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 136 insertions(+) create mode 100644 xep-xxxx-sso-login.md diff --git a/README.md b/README.md index cfb2126..45852e2 100644 --- a/README.md +++ b/README.md @@ -4,3 +4,4 @@ | --- | --- | | Extensible File Thumbnails | A specification for different types of thumbnails in the context of file transfers | | File Upload Notifications | A specification for telling clients that a file will be sent as soon as it is uploaded | +| SSO Login | A specification for allowing SSO logins during XMPP authentication | \ No newline at end of file diff --git a/xep-xxxx-sso-login.md b/xep-xxxx-sso-login.md new file mode 100644 index 0000000..e685135 --- /dev/null +++ b/xep-xxxx-sso-login.md @@ -0,0 +1,135 @@ +# Single Sign-On (SSO) Login +## Introduction + +XMPP implementations can authenticate against a server with various different +methods. There exist password-based mechanisms, like *SCRAM* or *PLAIN*, and token-based +approaches like [FAST](https://xmpp.org/extensions/inbox/xep-fast.html). However, for certain deployments, where authentications is delagated +to a third-party, *SCRAM* and *PLAIN* cannot be used as they require some access to the user's +raw password (in the case of *SCRAM* the hashed password). [FAST](https://xmpp.org/extensions/inbox/xep-fast.html) can only be used for +reauthentication without access to the user's password. + +This specification provides a way for XMPP clients to authenticate with a server using +server-provided single sign-on (SSO) solutions. + +## Authentication + +When a client connects to the server and the server deems the connection ready for authentication, a +server providing login using SSO provides it as a [SASL2](https://xmpp.org/extensions/xep-0388.html) feature: + +```xml + + + + + SCRAM-SHA-1 + SCRAM-SHA-1-PLUS + + Login with Service 1 + Login with Service 2 + Login with Service 3 + + + +``` + +Each `` element identifies a SSO service that a client can authenticate against. Each `` element's id attribute +MUST be unique in its listing as it identifies what service the client wants to authenticate against in the next step. It MUST NOT contain +the `,` and `=` characters, An optional icon attribute points to a URL where an icon for the service can be found. Clients MUST ignore non-HTTP URLs. The text of the element +MUST provide a human-readable string identifying the service. It SHOULD idealy be short to pose minimal UI constraints. + +While the server in this example also provides authentication using *SCRAM*, a server does not have to. In a business deployment, the only authentication +mechanism MAY be just the company's SSO mechanism. + +In the next step, the client specifies that it wants to authenticate using (in this example) `sso-service-1`. + +```xml + + + LCxuPXVzZXIsaWQ9c3NvLXNlcnZpY2UtMQo= + + AwesomeXMPP + Kiva's Phone + + +``` + +In case the client sent an unknown SSO service identifier, it SHOULD respond with an error: + +```xml + + + + +``` + +If the chosen service identifier is known, the server MUST send an HTTPS URL at which the client can authenticate. In case of protocols like OpenID Connect, the sent URL MUST point +to a server-controlled callback URL, so that the server knows when the authentication succeeded. That callback URL SHOULD display a hint to the user that they may return to their +XMPP client. + +```xml + + + aHR0cHM6Ly9hdXRoLmV4YW1wbGUub3JnL2xvZ2luP3NlY3VyZS1wYXJhbWV0ZXI9YWJjJnNpZD0xMjMK + +``` + +Next, the client responds with an empty [SASL2](https://xmpp.org/extensions/xep-0388.html) response: + +```xml + +``` + +The user is should then be redirected to the server-provided authorization URL. + +## Success Case + +If the user's authentication succeeded and the server's callback URL has been called, the server MUST retrieve user information from the authentication server and use it for +the following session. In this example, the returned user information contained the username `user`. As such, the resulting authentication success may look like this (assuming +the server is responsible for the `example.org` domain): + +```xml + + user@example.org + +``` + +## Failure Case + +If the authentication somehow fails, the server MUST return a [SASL2](https://xmpp.org/extensions/xep-0388.html) authentication failure. One possible failure may be a timeout: + +```xml + + + + +``` + +## Business Rules + +This authentication mechanism SHOULD only be used on interactive authentication, i.e. when the user is physically able to perform actions, and not on +non-interactive logins, for example when reconnecting after losing the connection to the server. + +When authenticating, it is recommended to also request a token for a token-based authentication mechanism, like [FAST](https://xmpp.org/extensions/inbox/xep-fast.html), so that the user does not have +to reauthenticate to the third-party on every new connection. + +## Security Considerations + +This specification allows offloading the actual credential handling from the XMPP server to another third-party. Thus, security considerations of that chosen +third-party authentication solution apply. + +The server-provided authentication URLs MUST be using a secure protocol, like HTTPS. Clients MUST ignore insecure URLs. + +## Info + +| Key | Value | +| --- | --- | +| Author | PapaTutuWawa | +| Version | 0.0.1 | +| Short name | sso | \ No newline at end of file