Forum Discussion

dbeavon's avatar
dbeavon
Contributor
4 months ago

REST api and breaking changes for authentication in v8

We have been using the onestream REST api for a couple years now.


In the past we had been using Open-ID-connect (OIDC) to authenticate against an Azure AD ("Entra") directory, and then generate reports from cubeviews or data adapters.

During our current upgrade to v8, we started receiving lots of mixed messages from onestream employees about whether OpenID is still supported.  I'm assuming that the OS support team knows what they are talking about, but it seems to contradict the docs in substantial ways.  Moreover, it contradicts common sense.

What they are telling me is that in the "hosted" version of Onestream v8 on Azure, we are NO LONGER allowed to use OIDC to authenticate a service principal (app registration) and connect to the REST api.  Instead, they are saying that a new engineering team at onestream (called "OIS" team?) have rebuilt the authentication layers and they removed OIDC support in favor of PAT tokens.  Supposedly the PAT tokens are the only way to use the REST api in onestream going forward. 

 

This seems to be a massive step backwards - we lose our ability to connect with a normal service principal from  Entra ID, and we must start using a custom login that originates in onestream (one that will not have consistent governance as various other services that are managed by our security team.)

 

NOTE: The docs talk a lot about both OIDC *and* PAT tokens, so it seems like both are allowable....  Whenever the terms are contrasted or are used in close proximity to each other, the docs will say that customers "may use" PAT tokens.  They never say we "must use" PAT tokens.

Can anyone provide some more color to help customers understand this change?  It feels like a regression.  I suspect it may not have been intentional.  In my opinion, these PAT tokens aren't appropriate for the back-end service integrations, and we would rather continue using our old service principals originating in Entra ID.

Any additional information would be very much appreciated.

 

 

REST Api
  • JoakimK's avatar
    JoakimK
    Contributor
    4 months ago

    I cannot speak for the duality or not of using OIDC/PAT, but I just wanted to let you know the high level usage of PAT vs the old OIDC method.

    Using OIDC, you needed to make an authentication call using OAuth2 to generate a bearer token. This bearer token was then used in the subsequent calls to any of the OneStream Endpoints. So basically, a two step approach.

    Using PAT, you now already HAVE the bearer token (which is the PAT token), so only the second step of the above process is needed, call the OneStream endpoints directly and use the PAT token in place of where you previously used the bearer token. So if anything, using PAT is much more consistent as you always talk just to the OneStream endpoints themselves, no need for the extra Authentication call first.

    Hope this alleviates some of the painpoints you are referring to above?

    • dbeavon's avatar
      dbeavon
      Contributor
      4 months ago

      I understand the popularity of PAT tokens, given that they are quick-and-dirty.  They are suitable to most of the users of onestream, given the target audience is somewhat low-code/non-technical.

       

      However, having an *independent* identity provider adds a lot of value.  It allows security to be managed across an organization in a consistent way, not having to build customized authn/authz for every individual SaaS that may come around.   

      Another thing about an independent identity is that such an identity can be used for *multiple* purposes.  With a single secret, we can access more than one resource.  Onestream is just one of many resources that a given service may need to connect to.  It may be used for nothing more than retrieving the members of a dimension, and then using those members for some totally unrelated purposes that may have nothing to do with onestream.  As such, it is bothersome to maintain PAT tokens, and deal with the consequences when someone forgets to sign into this SaaS and  once a year, to do this busy-work.

  • JackLacava's avatar
    JackLacava
    Honored Contributor
    4 months ago

    I would encourage you to discuss this further with your Customer Success Manager, as they should be better placed to explain the roadmap and gather feedback.

    • dbeavon's avatar
      dbeavon
      Contributor
      4 months ago

      Hi JackLacava ,

      I'm a software developer and, truthfully, I'm a bit out of the loop from the discussions with the Success Manager.  My only role was to fix the REST api after it stopped supporting OIDC.

      It seemed to me that the OS tech support engineers were also caught off guard by the sudden changes in authentication, and I'd venture to say that a Customer Success Manager wouldn't be any closer to the technical answers that I'm looking for in this case.

      Based on the ambiguity in the docs , I'm hoping it was not the intention to break OIDC and hopefully they will bring it back.  I'm not sure *why* the product team would want to remove the support for this open authentication standard.  And  if they did want to do that in an intentional way, it seems like it would have been well-communicated. 

      I suspect the changes that are being done by this team (OIS) are work-in-progress.  One of the purposes of this post is to talk to other technical users, rather than sales teams.  And another purpose is to raise awareness so that other customers won't step blindly into v8 without setting aside time to start adopting these OS-specific PAT tokens on native OS user accounts.

       

       

       

      • JackLacava's avatar
        JackLacava
        Honored Contributor
        4 months ago

        Hey,

        I suggested CSMs because they can mobilize resources that are not necessarily available to Support, particularly when it comes to discussing the roadmap. Although we're obviously all pushing to do the best for our customers, Support will typically try to get your system running with what we have today, whereas CS can take a more collaborative approach and find ways to make everyone happy in the medium/long term, involving product teams if necessary.

        For the record, I've brought this to the attention of the relevant groups, so hopefully your CSM will soon get in touch to discuss the matter in a competent way.