1#pragma once
2
3/// @file
4/// @brief Login related responses.
5
6#include <optional>
7#include <string>
8
9#if __has_include(<nlohmann/json_fwd.hpp>)
10#include <nlohmann/json_fwd.hpp>
11#else
12#include <nlohmann/json.hpp>
13#endif
14
15#include "mtx/identifiers.hpp"
16#include "mtx/user_interactive.hpp"
17#include "well-known.hpp"
18
19namespace mtx {
20namespace responses {
21
22//! Response from the `POST /_matrix/client/r0/login` endpoint.
23struct Login
24{
25 //! The fully-qualified Matrix ID that has been registered.
26 mtx::identifiers::User user_id;
27 //! An access token for the account.
28 //! This access token can then be used to authorize other requests.
29 std::string access_token;
30 //! ID of the logged-in device.
31 //! Will be the same as the corresponding parameter in the request, if one was specified.
32 std::string device_id;
33
34 //! Optional client configuration provided by the server.
35 //! If present, clients SHOULD use the provided object to reconfigure themselves,
36 //! optionally validating the URLs within.
37 std::optional<WellKnown> well_known;
38
39 friend void from_json(const nlohmann::json &obj, Login &response);
40};
41
42//! Identity provider for SSO
43struct IdentityProvider
44{
45 //! Optional UI hint for what kind of common SSO provider is being described in this IdP. Matrix
46 //! maintains a registry of identifiers in the matrix-doc repo to ensure clients and servers are
47 //! aligned on major/common brands.
48 //!
49 //! Clients should prefer the brand over the icon, when both are provided. Clients are not
50 //! required to support any particular brand, including those in the registry, though are
51 //! expected to be able to present any IdP based off the name/icon to the user regardless.
52 //!
53 //! Unregistered brands are permitted using the Common Namespaced Identifier Grammar, though
54 //! excluding the namespace requirements. For example, examplesso is a valid brand which is not
55 //! in the registry but still permitted. Servers should be mindful that clients might not
56 //! support their unregistered brand usage as intended by the server.
57 std::string brand;
58 //! Optional MXC URI to provide an image/icon representing the IdP. Intended to be shown
59 //! alongside the name if provided.
60 std::string icon;
61 //! Required: Opaque string chosen by the homeserver, uniquely identifying the IdP from other
62 //! IdPs the homeserver might support. Should be between 1 and 255 characters in length,
63 //! containing unreserved characters under RFC 3986 (ALPHA DIGIT "-" / "." / "_" / "~"). Clients
64 //! are not intended to parse or infer meaning from opaque strings.
65 std::string id;
66 //! Required: Human readable description for the IdP, intended to be shown to the user.
67 std::string name;
68
69 friend void from_json(const nlohmann::json &obj, IdentityProvider &response);
70};
71
72//! One supported login flow.
73struct LoginFlow
74{
75 //! The authentication used for this flow.
76 mtx::user_interactive::AuthType type;
77
78 //! Optional identity providers (IdPs) to present to the user. These would appear (typically) as
79 //! distinct buttons for the user to interact with, and would map to the appropriate
80 //! IdP-dependent redirect endpoint for that IdP.
81 std::vector<IdentityProvider> identity_providers;
82
83 friend void from_json(const nlohmann::json &obj, LoginFlow &response);
84};
85
86//! Response from the `GET /_matrix/client/r0/login` endpoint.
87struct LoginFlows
88{
89 //! The list of supported flows.
90 std::vector<LoginFlow> flows;
91
92 friend void from_json(const nlohmann::json &obj, LoginFlows &response);
93};
94}
95}
96