Forum Discussion

octavian_krody's avatar
octavian_krody
Guide
3 years ago

How to authenticate rest api calls using technical users for server to server use (SSO enabled)?

Hello,

Been reading the docs and for a community with SSO enabled we've seen 3 means of achieving rest api access.

  • OAuth 2.0 authorization grant flow
    To make a fully-automated server-to-server API call, do not use OAuth; authenticate with a session key or SSO token instead.
    So we cannot use `Api Apps` in our server to server needs
     
  • LithiumSSO token
    "Place the encryption key on the user system server".
    We cannot access that as the IDP we are using is shared across many other instances, getting hold of a private key like that doesn't sound right to me.
    We do not have access to the private key, maybe I read that wrong?

    As per About SSO 
    "Khoros issues the LithiumSSO libraries (Java, .NET, or PHP) and a unique encryption key for each deployment."
    Where can we find the encryption key, as Admin > System > SSO has no such thing?

    Does the client only work with your SSO provider or with any? I'm unsure if our community works directly with our IDP or goes through lithium in the first place as there is no information regarding this in the admin options.

    Where can we see the source code for provided jars?
  • Session key
    Works for users not having a SSO ID with basic auth.

From what I can tell it seems that we can only use the Session key approach, is this correct?

Rest API
  • MohammedSh's avatar
    MohammedSh
    3 years ago

    octavian_krody, In this case you can use the session key based approach as you want to write/permission based access.

     

    It is okay for two types to exist simultaneously, but that user can only use the API as the default auth pages are blocked when SSO is enabled.

  • MohammedSh's avatar
    MohammedSh
    Moderator
    3 years ago

    Hi octavian_krody

    We are working on an OAuth 2.0 Client Credentials Grant Flow and this is meant as a pure server-2-server communication. We can only do calls that do not require user interaction, effectively making these read-only calls.

     

    So: For now: Session Key is the way. In the future, you may want to use the Client Credentials workflow depending on your implementation needs, but this will take a while. Please check https://oauth.net/2/grant-types/client-credentials/ for what this would be and you would need to assess if this is right for you.

  • octavian_krody's avatar
    octavian_krody
    Guide
    3 years ago

    MohammedSh 

    I see, Well having an api integration with read only access for which I suppose it doesn't have "role / scope" restriction would imply being able to read only public data, no hidden groups etc. which is not helpful as we need write / permission based access (e.g. use case integrating, company wide, account deletion)

    One more quick question though.

    I see that assigning a password through the UI to a SSO enabled community is not a thing, but creating a user through the api with a password is allowed, does having a password based user on an SSO community impact any features? is it ok for the two types to exist simultaneously?

    • MohammedSh's avatar
      MohammedSh
      Moderator
      3 years ago

      octavian_krody, In this case you can use the session key based approach as you want to write/permission based access.

       

      It is okay for two types to exist simultaneously, but that user can only use the API as the default auth pages are blocked when SSO is enabled.