No internet connection
  1. Home
  2. Documentation

Talkyard Single Sign-On API

By KajMagnus @KajMagnus2020-04-15 13:37:44.737Z2020-04-25 12:02:36.058Z

Talkyard has a Single Sign-On (SSO) API. To use it, you'll write some code, and edit Talkyard settings.

(Note: 1) Currently the SSO API is for Talkyard's forum only — not yet implemented, for blog comments. 2) Later there will be OpenID Connect (OIDC) support too. That's a standardized solution that doesn't require you to write any code. On the other hand you need a login server with OIDC support, for example Keycloak.)

Your server needs to include an Authorization: Basic ... header in its API requests — read more here.

The SSO API works as follows. When a user clicks Log In at your Talkyard forum, Talkyard redirects him/her to your website / your login server. The user then logs in over there. Then, your server sends a request to your Talkyard server (whilst the user and web browser do nothing — all this happens quite fast):

// Your server to Talkyard:
POST /-/v0/sso-upsert-user-generate-login-secret

... with JSON for the user who is going to login. Here's a Typescript interface for that JSON:

interface ExternalUser {
  ssoId: string;
  primaryEmailAddress: string;
  isEmailAddressVerified: boolean;  // must be true
  username?: string;
  fullName?: string;
  avatarUrl?: string;
}

ssoId is your unique ID for the user, in your user database or login system. It must never change.

isEmailAddressVerified must be true — you must have verified your users' email addresses. Otherwise maybe they could hijack each other's Talkyard accounts somehow.

Talkyard then inserts the user in its database, and returns JSON with a one-time login secret:

{  "loginSecret":  "....." }

Your server then redirects the user's browser to:

GET /-/v0/login-with-secret?oneTimeSecret=....&thenGoTo=/

Talkyard looks at the one-time secret, generates a session ID cookie — and thereafter, your user is Single Sign-On logged in, at Talkyard. Talkyard redirects him/her to the thenGoTo url path, / in the example above.

***

To configure SSO, go here: https:// your talkyard server /-/admin/settings/login

Scroll down to the Single Sign-On section. Follow the instructions. And if you accidentally lock yourself out — you, being the Talkyard site admin, can get a one time login link emailed to you, if you go here: https:// your talkyard site /-/admin-login

  • 45 replies

There are 45 replies. Estimated reading time: 35 minutes

  1. F
    @fas2021-05-05 10:03:29.300Z

    HI, I see from other forum posts that OIDC is implemented. What is the status of SSO for blog comments please?

    1. KajMagnus @KajMagnus2021-05-08 09:45:54.641Z

      HI @fas, what type of SSO for embedded comments, do you have in mind?

      • Embedded comments via Talkyard's custom Single Sign-On works but one needs to click "Log in" even if already logged in at your user management system.
      • Or do you use OIDC? I didn't try that yet with blog comments. I would think it'll just work — and if it doesn't, shouldn't take long to fix any issues — however one would still need to click "Log in" once extra, even if already logged in.
      • And / or did you have in mind to include some HMAC signed (or even encrypted somehow) user identity in the generated blog post page, so that Talkyard got to know who the user was, directly? — Then, no extra "Log in" click needed. (This is, I think, how Disqus and others work)
      1. F@fas2021-05-08 16:27:43.797Z

        Hello @KajMagnus

        Yes I was thinking along the lines of your HMAC user identify already embedded so no login is necessary. The extra login click and user selection wouldn't work well in my case.

        Is this sort of thing possible? I'm OK using the custom sso solution, although OIDC is also an option.

        1. KajMagnus @KajMagnus2021-05-11 08:21:36.663Z

          I've started making this work. I think there'll be something for you to try out in 1 – 3 weeks.

          I have in mind to use PASTEO tokens (if you happen to know what that is).

          If one of your members logs in once, and then again later, but then with a different email address, then, what would you want Talkyard to do? E.g. update the user's email address in Talkyard's database? Or only do that, if you've explicitly configured this via some admin setting?

          1. F@fas2021-05-11 09:07:02.246Z

            Hi Kaj,

            This would be great for us, thanks.

            Concerning an email change. How would you know if the same user logged in again with a different email address? Is the email address not the primary key for users?

            Franz

            1. KajMagnus @KajMagnus2021-05-14 17:44:35.025Z2021-05-14 17:52:11.364Z

              You decide what the primary key is. And it's better to not use the email as primary key, in case people want to change their email address.

              In the Talkyard database, each user has a ssoId field — "single sign-on ID". And your software, set this field to a per user unique identifier — could be the primary key in your own users database table, if any.

              The first time someone logs in via SSO, then, if there is already a user with the same email address, and you've verified that it's indeed the same person (by sending an email address verification email),
              then, Talkyard won't create a new account — instead, the person gets logged in as that already existing user account.
              Talkyard also remembers the ssoId you'll need to specify (as part of the PASETO token), and the next time that person logs in, Talkyard looks up the user account via that ID — and, if s/he has changed the email address, Talkyard could update the email in the database to the new email.

              ( If, when Talkyard tries to update the email addr, if there's then already an account with the new address, and it's the same person (address verified), then, it can make sense to 1) merge the accounts, if the user wants this, or 2) not change the email, or 3) do change the email, and then using it for notifications only, but not for logging in. Or 4) change the email, but not merge the accounts, and if, later on, you disable SSO, and the person wants to log in via that email address, s/he got to choose which account to log in to (since it'd now be connected to two accounts). I think this, alt 4, is how Reddit works b.t.w.: apparently one can have many accounts with the same email, and one gets to choose, when logging in.)

              Can I ask what blog platform do you use? What's the primary key in your users database table / user management system?

              1. F@fas2021-05-15 08:00:51.631Z

                Ah, I understand. My use case is for educational training courses where there will be many different courses (100's - 1000's) and each course will have its own forum and each page will have comments. This is why I would need an API to create and configure each forum programmatically.

                In my case it is the ticket that the participant has to the course that would identify them. This ticket id would not change and so should be my ssoid. Because the courses are also quite short lived, the email address will also not change, but I can see that it would be useful to have the option of updating the email address if needed.

                1. KajMagnus @KajMagnus2021-05-16 19:25:00.637Z

                  Ok. Nice use case, with education.

                  This is why I would need an API to create and configure each forum programmatically

                  And, for blog comments SSO, you'll need to encrypt and/or sign a JSON description of the blog visitor (if s/he is logged in, in your computer system).

                  This makes me wonder, what programming language / tech stack do you blog use? If I may ask.
                  (Is it the same for your blog, and for the educational software? Or maybe the blog uses different software?)

                  Here's the encryption/signature method I have in mind to use: https://paseto.io

                  1. F@fas2021-05-17 12:12:31.533Z

                    Hi Kaj,

                    We use Java/JEE/JBoss/Vaadin. Everything pretty much inhouse developed. Its one of the reasons we have settled on Talkyard because of Scala and Java being close cousins.

                    I see there is a Java library for Paseto called JPaseto, so this would work perfectly for us.

                    Thx,
                    Franz

                    1. KajMagnus @KajMagnus2021-05-20 11:25:10.813Z

                      Ok, I'm guessing that in the middle of not next week, but next-next week, there'll be a SSO implemention for you to try out.

                      Ok nice that you use the JVM :- )   (btw Scala 3 was just released, maybe you'd like to check it out :- ))

                      (JPasteo I use too)

                      1. F@fas2021-05-22 16:56:54.563Z

                        That would be awesome - thanks!

                        I have the basic embedded comments working now - without any SSO. I have another question - when a embedded comments with discussion id is added automatically, it appears in the main forum under the URL of the comments page. Is there a way to change this to a defined page name instead?

                        1. KajMagnus @KajMagnus2021-05-27 04:07:37.964Z

                          Starting (continuing) with this now.

                          Is there a way to change [the name of the generated embedded comments discussion page] to a defined page name instead?

                          Not yet. What if 1) Talkyard copied the <head><title> attribute and used that, by default? (This I could fix now when making SSO work)

                          And 2) this could be overridden, by a data-discussion-title=... attribute on the HTML tag? Like so:

                          <div class="talkyard-comments" data-discussion-id="123abc"  data-discussion-title="Some Title" />
                          

                          Other approaches: 3) Talkyard does an outbound network request to the blog URL to get the <title> tag ... But this seems unnecessary, when the embedded Javascript could just include it itself, directly. Or 4) include the title as a claim in the PASETO token but this seems weird to me.

                          1. F@fas2021-05-27 05:10:07.649Z

                            Hello Kaj,

                            Options 1) and 2) would work for me with 2) preferred. 3) and 4) don't make much sense to me.

                            Would the name in the main forum change if the data-discussion-title changes?

                            Thanks again for your efforts.

                            Franz

                            1. KajMagnus @KajMagnus2021-05-27 06:54:11.138Z

                              Would the name in the main forum change if the data-discussion-title changes?

                              I'm not sure. Probably not in the initial implementation. Would you want it to auto update?

                              B.t.w. changing the title dynamically, would make it possible for anyone to set a breakpoint in Dev Tools, edit the underlying HTML and set data-discussion-title="Crazy Title" and in that way, change the title to something crazy.
                              Setting it just once, at least would give a pranks minded person, only one opportunity to mess up the title to something crazy.

                              A way to defend against crazy titles, and other similar things, would be to sign the attributes. Maybe like so:

                              <div class="talkyard-comments" data-token="paseto:v2.public.ABC123...." />
                              

                              That is, all discussion attributes would be in a signed token. Then, Talkyard would know no one had tampered with the discussion title — and then it sems to me that Ty should auto update the title, to whatever the new value is, in a claim in the data-token.

                              1. F@fas2021-05-27 07:08:42.697Z

                                I didn't think of the tampering problem. You are right, if it is easy to put into a attributes token then that would prevent the problem. For my integration creating the data-token would be trivial, but for regular blog users probably not.

                                1. KajMagnus @KajMagnus2021-06-05 07:44:58.110Z

                                  I wonder, would you prefer 1) when you click Log In, a popup win opens, in which you get to log in over at your website. Then, the popup win closes, and you are logged in to the Talkyard comments, using an identity provided by your website. However, the embedding blog post, won't know that now you are logged in. (The blog post page won't get refreshed — only the comments section notices that you logged in.)

                                  Or 2) when clicking Log In, the whole browser window gets redirected to your website, and you login over there. Thereafter, the whole browser window (not just a login popup win) gets redirected back to the blog post — and now, both the blog post page, and the comments section, know that you're logged in.

                                  What'd work best, in your case?

                                  I imagine that if the blog post page, has any access restricted sections or maybe shows one's username & account info somewhere, approach 2 can be better.
                                  Otherwise, approach 1 can be better, in that any state one has "created" on the blog post page, (e.g. scroll position, maybe some collapsed comments one has expanded) won't be lost — since the login happens in a popup win, won't affect the blog post window itself (except that one gets logged in).

                                  1. F@fas2021-06-06 14:51:03.357Z

                                    For my use case, the user will always already be logged in and the forums are only visible when already authenticated and authorized, so this is not a use case I need at all.

                                    1. KajMagnus @KajMagnus2021-06-09 07:04:03.780Z

                                      What do you want to happen, if one clicks Log Out in Talkyard?

                                      Getting logged out from your software system? Then, there can be a Log Out URL you can specify, to where the user gets redirected, if clicking Log Out in Talkyard

                                      (Or maybe the logout button should even be hidden, in Ty, in your case? If people might find it confusing with logout buttons in the comment section, when apparently there're login/out buttons at the top of the embedding pages already? I mean, your software has its own user profile button and login/out buttons at the top of your pages, I'd guess?)

                                      1. KajMagnus @KajMagnus2021-06-11 14:08:57.882Z

                                        @fas Sorry b.t.w. that this is taking longer than what I thought (some other things came up in between, + I started thinking about different ways to do this SSO, and now it seems to me all those different ways make sense, for different communities & authentication systems).

                                        1. F@fas2021-06-12 11:00:59.351Z

                                          Hi Kaj. In which direction are your ideas going, and when do you think you may have something by - my project is currently on hold pending this feature? I have also been thinking that a Liferay portlet to replace the Liferay internal message board would be useful to me. Here again, as for my initial use case, the authentication is managed by Liferay and the portlet could send the data token to Ty. This would be a great addition to Liferay.

                                          1. KajMagnus @KajMagnus2021-06-13 04:17:37.032Z

                                            I started looking into blog comments SSO via OIDC, and wondering if maybe that could have been a better approach in your case, and finding out what would need to be done to make that working with Talkyard (not much it seems).

                                            Now, though, it seems to me that PASETO tokens work better in your case, since the user will always be logged in, and it'd be unnecessary to redirect him/her to an Identity Provider for authentication.

                                            when do you think you may have something

                                            I think at the middle? end? of next week. I've written the code already, however code review and some auto tests are missing. And this week (June 13-19) I'm code reviewing & merging some other things.

                                            the authentication is managed by Liferay and the portlet could send the data token to Ty

                                            Ok. I noticed that Liferay-Portal, https://github.com/liferay/liferay-portal, is written in Java, and here I "found" a Git repo with Liferay plugins: https://github.com/liferay/liferay-plugins.

                                            I wonder, would Ty comments be embedded on Liferay pages, or ... would you combine Liferay with a Ty forum? And, with "send the data token to Ty" — that means including it in the HTML source? (as we're doing with the embedded comments), or possibly via a HTTP request somehow

                                        2. In reply toKajMagnus:
                                          F@fas2021-06-12 10:55:18.397Z

                                          Hello Kai. In my case the logout button should ideally be hidden.

                                          1. KajMagnus @KajMagnus2021-06-13 03:55:31.644Z

                                            Ok, initially that can be quickly done using CSS.

      2. C
        In reply toKajMagnus:
        Christian Scheuer @chrscheuer2021-05-07 11:03:49.554Z

        Hi @KajMagnus

        Great timing you just added this. We're so happy with the SSO API obviously, making our integration extremely easy!

        I wondered, given than we're using the ssoId as the unique identifier for users, how would we go about if the user on our side requests to change their email address?

        The unique ID we're offering to you would remain the same, but would the SSO API automatically make sure to change the user's email on your side? Or would it throw an error if we suddenly provide a new email?

        Now that our community is growing quite rapidly, users changing emails is becoming more and more common, and currently, in part due to not knowing how the forum would handle this, we don't support users changing emails at all. That creates a HUGE amount of extra manual work every time a user wants to change their emails (we essentialy have them sign up again and transfer their data), so looking to eliminate that work by actually implementing the feature.

        Would we need a new API from TY to set the user's new email address? Or what are your thoughts?

        1. KajMagnus @KajMagnus2021-05-08 09:53:56.078Z

          how would we go about if the user on our side requests to change their email address?

          There could be configuration settings that tell Talkyard to update the email address, if it's different, when a user logs in.

          not knowing how the forum would handle this, we don't support users changing emails at all.

          I don't think Ty is able to update one's email yet (but it's going to do, if configured to do so).

          have them sign up again and transfer their data

          Oops that indeed sounds like lots of work

          Would we need a new API from TY to set the user's new email address?

          I'll have a closer look, but I think what's needed is a config value that tells Ty to update the email. And that I make Ty run an SQL statement to update the email if needed, + e2e tests.

          1. CChristian Scheuer @chrscheuer2021-05-08 23:36:10.350Z

            Thanks for looking into this.

            Let me know what you find out. This would indeed be very good for us to get automated sooner rather than later :)

            1. KajMagnus @KajMagnus2021-05-11 08:23:39.153Z

              Ok :- ) Seems I'm doing this now, together with making blog comments Single Sign-On work, it's the same part of the code base.

              I wonder if updating the email address, should maybe be the default behavior, hmm.

              1. CChristian Scheuer @chrscheuer2021-05-11 08:36:35.544Z

                Are email addresses used for anything unique in TY? We need to think about the possible failure cases and how to handle it if this is handled as part of the normal sso login api

                1. CChristian Scheuer @chrscheuer2021-05-11 08:37:04.917Z

                  Oops I was typing this on my phone but thanks for looking into it now :)

                  1. CChristian Scheuer @chrscheuer2021-05-11 11:34:33.427Z

                    I can't figure out if it's good or bad to handle auto-email changing as part of the SSO login.

                    Upsides:

                    • It happens automatically

                    Downsides:

                    • What if another user exists with the new email. Does the API report a failure (I think it should)?
                    • Any errors would happen out-of-flow, causing error handling in the distributed transaction to be very hard, if not impossible. This could easily lead to bad state.

                    Note that our flow when a user requests an email change will be to:

                    • Register a distributed flow in our system
                    • Change the login email so they can use the new email to log in.
                    • Tell Chargebee the user has a new email
                    • Tell Stripe the user has a new email
                    • Tell Intercom the user has a new email
                    • Tell Mixpanel/Amplitude/etc. the user has a new email
                    • (This is where it would make sense we just add an API call to TY to say the user has a new email)
                    • When all services have been updated, consider the change done
                    • If any of the services fail to update, report the change as faulty and handle manually (or, maybe even automatically revert it for all services that did the change already)

                    If the Talkyard email change happens automatically at a later stage (next time they log in to the forum), it's possible for the forum email change to fail, but since it wasn't part of our email change flow, it won't properly trigger the right mechanisms to consider it a faulted distributed transaction.
                    Also, if they don't happen to log in to the forum anytime soon, they'd still keep receiving forum emails (notifications for example) on their old email. This would lead to support cases.
                    If we used the SSO login api as a "fake" way of communicating the email change (faking that they're logging in) as part of our above flow, then we'd still need to handle failure cases which means we'd then have to start tracking which email is active for the forum user. That also becomes complex quickly.

                    For this reason, having user email change as a separate API call that doesn't happen automatically as part of SSO login would be preferable, I think.

                    1. KajMagnus @KajMagnus2021-05-14 18:25:23.654Z

                      Summary: A separate API request for changing a user's email = good idea it sounds to me.

                      Details:

                      What if another user exists with the new email. Does the API report a failure (I think it should)?

                      Currently the SSO endpoint does nothing, if the email is different (it won't update the email at all).

                      I suppose it's better with a separate API endpoint that replies Error,
                      and not changing the email, via SSO.

                      ( Theoretically it can be fine, with different accounts, with the same email address. As far as I remember, Reddit allows this — and then, if logging in via email, one gets to choose which account one logs in to.
                      For duplicated email addresses to make sense, the email address needs to have been verified, whenever it gets connected to a new account — so the different accounts with the same login-email, do belong to the same real life person.
                      Maybe some time there could be an admin setting, or API request parameter, that says if duplicated emails should be allowed or not. )

                      (This is where it would make sense we just add an API call to TY to say the user has a new email)

                      I was actually thinking about this API endpoint: POST /-/v0/upsert-user
                      which does the same thing as the SSO endpoint, /-/v0/sso-upsert-user-generate-login-secret,
                      except that it won't log the user in.

                      it's possible for the forum email change to fail,

                      With SSO, in a way it's even more okay to have duplicated emails, since they're just used for notifications — not for login.

                      But allowing dupl emails, might require some changes in Talkyard (good changes I'm thinking), so for now I suppose it's better to not allow this.

                      I'd guess if there's already an account with the same email, that "must" be because the person forgot that s/he had another SoundFlow account already with that email?
                      (SoundFlow verifies people's email addresses, so if it's the same email, it's the same human?)

                      If the Talkyard email change happens automatically at a later stage (next time they log in to the forum), it's possible for the forum email change to fail

                      That indeed sounds complicated, makes me think of split-brain problems in a distributed databases.

                      Also, if they don't happen to log in to the forum anytime soon, they'd still keep receiving forum emails (notifications for example) on their old email

                      Good point. This makes the POST /-/v0/upsert-user endpoint even more useful.

                      If we used the SSO login api as a "fake" way of communicating the email change ... still need to handle failure cases ...
                      ... having user email change as a separate API call that doesn't happen automatically as part of SSO login would be preferable

                      Agreed

                      distributed transaction

                      (I wonder if you use some specific distributed transaction software for doing this? Or if that wasn't needed?
                      Maybe you just undo any previous changes, by calling those API endpoints again, if one of the last steps fails)

                      1. CChristian Scheuer @chrscheuer2021-05-18 15:06:34.050Z

                        With SSO, in a way it's even more okay to have duplicated emails, since they're just used for notifications — not for login.
                        But allowing dupl emails, might require some changes in Talkyard (good changes I'm thinking), so for now I suppose it's better to not allow this.

                        Good points! Agreed on both.

                        (I wonder if you use some specific distributed transaction software for doing this? Or if that wasn't needed?
                        Maybe you just undo any previous changes, by calling those API endpoints again, if one of the last steps fails)

                        Yea, we'll be using some GCP features for this (Google Cloud Workflows, most likely). And yes, we'll probably do automated rollback like this eventually, if it ends up being a massive issue. But as a start, we'd block the transaction and mark it as half-done and send ourselves an email so we can investigate why it happened before fixing it manually for that individual user.

                        I was actually thinking about this API endpoint: POST /-/v0/upsert-user
                        which does the same thing as the SSO endpoint, /-/v0/sso-upsert-user-generate-login-secret,
                        except that it won't log the user in.

                        That would be amazing!

                        1. KajMagnus @KajMagnus2021-05-20 11:18:24.873Z

                          Ok, I've written the code for this new endpoint already — what's left, is e2e tests (& deploying new version).

                          1. CChristian Scheuer @chrscheuer2021-05-20 12:42:58.285Z

                            Wohoo!!! Awesome!

                            1. KajMagnus @KajMagnus2021-05-26 06:28:50.647Z

                              Now I've upgraded this server, Ty .io — will upgrade Prod tomorrow or later today. The API endpoint looks like:

                              POST /-/v0/upsert-user  {
                                ssoId:  ...
                              
                                primaryEmailAddress:  ...,   // optional
                                isEmailAddressVerified:  true,   // must be true, if primaryEmailAddress specified
                              
                                username: ....  // optional
                                fullName: ....  // optional
                              }
                              

                              If there's an email collision, Ty replies Error.
                              If there's a username collision, Ty generates a similar but available username. (Maybe could be a flag to reply Error instead)

                              E2e test: https://github.com/debiki/talkyard/blob/323eff454023ca710e763e44a3272e08a6735141/tests/e2e/specs/api-update-user-and-sso-user.2br.test.ts#L207
                              (In that e2e test, isEmailAddressVerified is set to true although not immediately obvious)

                              1. CChristian Scheuer @chrscheuer2021-05-26 09:12:53.786Z

                                Nice!

                                So we'd use this with ssoId and primaryEmailAddress set to the new email address as a way to change it?

                                1. KajMagnus @KajMagnus2021-05-26 09:29:08.643Z

                                  Yes

                                  The old email address gets deleted.

                                  B.t.w. some time later, I suppose there'll need to be a /-/v0/deactivate-user or /-/v0/delete endpoint, so you can deactivate users automatically too.

                                  Or maybe to deactivate, that could be /-/v0/upsert { ssoId: ..., isDeactivated: true } or ..., suspendedTil: YYMMDD } etc

                                  1. CChristian Scheuer @chrscheuer2021-05-26 10:38:12.848Z

                                    Awesome! Let me know when this is up in production and I'll get testing :) Thank you so much for the quick implementation!

                                    1. CChristian Scheuer @chrscheuer2021-05-26 17:35:56.910Z

                                      Have you by any chance updated the production server? We have a customer who can't use SSO to get his user created for some reason.
                                      He's seeing the "I don't think I've seen that secret before" or something like that...

                                      1. CChristian Scheuer @chrscheuer2021-05-26 17:41:23.922Z

                                        Oops, the error was on our end, apologies.

                                        1. KajMagnus @KajMagnus2021-05-27 04:29:00.363Z

                                          Now I just upgraded the server (10 min ago, to v0.2021.15 with /-/v0/upsert-user included).
                                          I suppose you'll start trying this out with a test user account :- )

                                          1. CChristian Scheuer @chrscheuer2021-05-27 09:18:28.531Z

                                            YAY!! Can't wait to test. And yea, haha, don't worry, we'll test with test accounts before releasing anything :)

                      2. In reply tochrscheuer:
                        KajMagnus @KajMagnus2021-05-14 18:37:01.085Z2021-05-14 18:49:33.529Z

                        There's a standard calles SCIM that seems related to this:

                        http://www.simplecloud.info/

                        It would let SoundFlow send API requests to Talkyard, using a standardized interface, to add / remove users to groups, or disable a user account in Talkyard, if the user deletes his/her SoundFlow account.

                        And for updating users' email addresses too I presume.

                        Many companies e.g. Microsoft, Okta, GitHub, SalesForce, VMWare support this. I'd like to add support for this to Ty too, but I wonder if it'd take annoyingly long to read all the docs about SCIM, so maybe now is not the time.

                        Anyway they have a Replace request: PUT https://example.com/{v}/{resource}/{id} — I suppose this could be used for changing a user's email.

                        1. CChristian Scheuer @chrscheuer2021-05-17 07:25:06.942Z

                          That definition sounds just like any REST endpoint to me.. From our perspective, this is something we badly need in the coming months due to us expecting wildly growing number of users soon, so if there was a chance to have support for it with a simple API first, we'd be very happy :)

                          1. KajMagnus @KajMagnus2021-05-20 11:22:50.422Z

                            coming months

                            Ok, I'll try to have something for you to test ... in the middle of next week (I hope sounds ok)

                            Simple API first — yes. It seems to me, it's good with a simpler & takes-less-time-to-read-the-docs Talkyard "native" API.

                            (At the same time, I think i like SCIM :- ) which makes me surprised, often these more enterprisey APIs are a bit boring? or so I thought)